agent-charge: seller-side CLI for agent-native payments

[thisnick]

Problem

Sellers (starting with solo devs and indie hackers) need a simple way to accept payment from both AI agents and humans without building a payment page. Existing solutions (AP2, x402, Skyfire) require bilateral adoption. agent-charge uses Stripe — which sellers likely already have — and adds agent-native + human-friendly payment in one tool.

What it does

agent-charge is a seller-side CLI that:

• Exposes a machine-readable payment descriptor at GET /.well-known/agent-pay.json (for agent buyers)
• Serves a human-friendly checkout page at the same URL (content-negotiated: Accept: text/html → Stripe Checkout redirect, Accept: application/json → descriptor)
• Generates ad-hoc payment links for sending in conversations (text, email, WeChat, etc.)
• Verifies a receipt posted by the buyer (agent or human)
• Runs a provision webhook to deliver the purchased resource (API key, access token, etc.)

Two buyer types, one endpoint

Buyer	Flow
Agent	Fetch descriptor → pay with virtual card → POST receipt → get provisioned
Human	Click payment link → Stripe Checkout → webhook confirms → provisioned

CLI interface

Setup (human, interactive, once)

agent-charge setup
# ? Stripe secret key: ••••••••
# ? Stripe publishable key: ••••••••
# ? Default currency: usd
# ✓ Config written to ~/.agent-charge/config.json

agent-charge product add
# ? Product name: agent-wechat - monthly
# ? Amount (USD): 29.00
# ? Provision webhook URL (optional): https://myserver.com/provision
# ? Or provision command: ./provision.sh {receipt}
# ✓ Product added — id: wechat-monthly

Serve (runs endpoints)

agent-charge serve --port 4242
# Listening on :4242
# GET  /.well-known/agent-pay.json → payment descriptor (agent) or checkout redirect (human)
# POST /verify                     → verify receipt + trigger provision

Generate payment links (for conversations)

agent-charge link wechat-monthly
# https://myserver.com/pay/wechat-monthly?s=abc123
# (Works for both humans and agents — content-negotiated)

agent-charge link wechat-monthly --amount 15 --note "first month discount"
# Ad-hoc link with custom amount

Verify

agent-charge verify pi_abc123
# {"status":"provisioned","resource":{"type":"api_key","value":"sk_live_xyz"}}

Status

agent-charge status
# Products: 2
# Transactions today: 14 ($42.00)
# Pending: 0  Failed: 1

The payment descriptor (micro-spec)

GET /.well-known/agent-pay.json returns:

{
  "version": "1",
  "processor": "stripe",
  "client_secret": "pi_abc123_secret_...",
  "amount": 2900,
  "currency": "usd",
  "description": "agent-wechat - monthly",
  "receipt_endpoint": "https://myservice.com/verify"
}

When the same URL is hit with Accept: text/html (browser/human), it redirects to a Stripe Checkout session for the same product.

This is the only coordination point with the buyer. The format is intentionally simple so it can later map onto ACP/AP2 as those mature.

End-to-end flows

Agent buyer

1. Buyer agent → GET /.well-known/agent-pay.json
   ← {client_secret, amount, receipt_endpoint}
2. Buyer agent → pays via virtual card (Privacy.com, Stripe Issuing, Extend)
   ← receipt: "pi_abc123"
3. Buyer agent → POST /verify {receipt: "pi_abc123"}
4. agent-charge → verifies with Stripe → triggers provision webhook
   ← {status: "provisioned", resource: {type: "api_key", value: "sk_..."}}

Human buyer

1. Seller sends payment link in conversation: https://myserver.com/pay/wechat-monthly?s=abc123
2. Human clicks → Stripe Checkout
3. Human pays → Stripe webhook fires
4. agent-charge → triggers provision webhook → done

Conversational (agent sends link mid-chat)

1. Seller's agent: "That'll be $29/month. Here's the payment link: https://..."
2. Buyer (human or agent) pays via the link
3. Provision happens automatically

Config

{
  "processor": "stripe",
  "secret_key": "sk_live_...",
  "publishable_key": "pk_live_...",
  "currency": "usd",
  "products": [
    {
      "id": "wechat-monthly",
      "amount": 2900,
      "description": "agent-wechat - monthly",
      "provision_webhook": "https://myserver.com/provision",
      "provision_hook": "./scripts/provision.sh {receipt}"
    }
  ]
}

Processor support

Starting with Stripe. Architecture supports adding more over time:

Processor	Status	Notes
Stripe	✅ v1	Payment links, checkout, PaymentIntent
Plaid	🔮 future	ACH/bank transfers
Others	🔮 future	Pluggable processor interface

Why not AP2 / x402 / Skyfire?

Tool	Seller setup	Buyer setup	Fiat?	Human buyers?
AP2	Complex	Complex	Yes (eventually)	No
x402	Medium	Medium	No (USDC only)	No
Skyfire	Register on platform	Register on platform	Yes	No
agent-charge	Stripe + 1 command	Any virtual card or browser	Yes	Yes

Implementation scope

• ~500 lines TypeScript
• Dependencies: stripe, express, commander
• Ships as: npm i -g agent-charge
• Integrates with agent-pay (buyer CLI) on the agent side; works with any virtual card on the human side

Open questions

• Express middleware mode for sellers with existing Node servers?
• Multi-product descriptors (let agent choose from a menu)?
• Idempotency for duplicate receipt submissions?
• Webhook vs polling for Stripe payment confirmation?
• How to handle partial failures (payment succeeded but provision failed)?
• Should provision support async (long-running provisioning with status polling)?