Agents can browse docs and call APIs, but they can't do checkout. No credit card form, no OAuth dance, no "verify your email". So when I shipped an AI generation API, the interesting question was: how does an agent pay?
What I built
An MCP server (https://livepairai.com/mcp, streamable HTTP) exposing ~70 image/video models behind one interface. An agent connects, lists models with prices, calls generate, and gets back either a result or an HTTP 402 with payment requirements.
The payment rail is x402 — USDC on Base. The flow:
POST /v1/agent/generate {model, prompt}
← 402 Payment Required
x-payment-requirements: {amount: "400000", currency: USDC, chain: base, payTo} → agent signs USDC transfer, retries with X-PAYMENT header ← 200 + result URL (hosted 48h, auto-deleted)
One HTTP round-trip pattern. No API key, no account, no session — the payment signature is the credential.
What actually happens inside
- Model catalog with live per-call pricing:
GET /v1/agent/models(5s 720p video ≈ $0.40, images ≈ $0.02–0.05) - Quote freshness was the annoying part — prices are per-result, so the 402 response carries a short-lived quote the agent must settle before expiry
- For humans/API keys there's a chat-completions-compatible surface instead, so integrators who want accounting get
Authorization: Bearer lp_…and skip the wallet dance entirely
Failure modes I hit
- Agents that retry the original request without attaching payment — had to make the 402 body self-describing (amount, recipient, expiry, example header) so a generic agent could act on it without me hardcoding the client
- Wallet-funded agents settling twice on timeout — made fulfillment idempotent on the payment reference
- The privacy constraint shaped the storage layer: renders live 48h max, never indexed, share links are a separate opt-in path gated by model
Try it
- MCP endpoint:
https://livepairai.com/mcp - Agent docs:
https://livepairai.com/SKILL.md - Manifest:
https://livepairai.com/v1/agent/manifest.json
If your agent has a USDC wallet, it can already use this. Curious how others are handling
Top comments (4)
The double settle on timeout one is real, we hit the same thing. Making fulfillment idempotent on the payment reference fixed the serving side, but the other half was teaching the client to reconcile before it pays again: on timeout, check whether the first authorization already landed on chain before signing a second one. Most of the time it has, and the retry just needs the receipt, not a new payment.
yeah thank you for pointing out important view
No problem!
Đúng điểm đau của agent economy hiện tại. Mình từng gặp case tương tự khi build pipeline cho autonomous research agents — chúng đọc docs, gọi API ngon lành, nhưng đến bước cần thuê GPU spot instance hoặc trả phí API premium thì deadlock vì không có ví, không có KYC.
USDC on-chain giải quyết được phần settlement, nhưng mình lo ngại về:
Mình thấy hướng prepaid credit + off-chain accounting + periodic on-chain settle (như các CDN/payment processor làm) có thể pragmatic hơn cho high-frequency micro-billing. Bạn có benchmark overhead latency khi inject payment check vào MCP request loop không? (site: labagent .tech)