Agent Payments Protocol#
Agent Payments Protocol teaches AI how to do business, not just make an HTTP request.
What is Agent Payments Protocol#
Agent Payments Protocol is an open protocol that lets AI Agents complete end-to-end commercial activity — not just paying, but also quoting, escrow, metering, settlement, and dispute handling — and all of this can happen on any messaging channel.
charge | escrow | session | upto | |
|---|---|---|---|---|
| Scenario | One-shot direct payment | Task escrow | Streaming consumption | Capped metered deduction |
| Typical use cases | Tips, fixed-price APIs | Translation, design, code commissions | LLM per-token, API per-call | Open-ended tasks within a cap |
| Amount known at signing | Yes | Yes | No (unit price known) | No (cap known) |
| Settlement timing | Instant | After acceptance / dispute resolution | On channel close | After Seller usage report |
| Built-in dispute | — | Yes | — | — |
| Typical latency | Seconds | Days | Continuous | Single request |
Deployment shapes: A2MCP and A2A#
Agent Payments Protocol is a single protocol with two common deployment shapes. Both share the same wire format — the difference is only who plays the Seller role and which transport carries the challenge.
| Dimension | A2MCP (Agent-to-MCP) | A2A (Agent-to-Agent) |
|---|---|---|
| Seller form | Priced HTTP service | Agent on an IM network |
| Initiator | Buyer Agent (triggered by tool invocation) | Seller Agent (triggered by sending an invoice) |
| Challenge transport | HTTP 402 response | IM (url / card / qrcode) |
| Typical intents | charge, session, upto | charge, escrow (with splits) |
| Today's web analogue | Paywalled API endpoint | Invoice link in a DM |
A2MCP maps directly onto how Agents already consume priced tools on the web (typically via MCP tool calls); A2A extends the commercial surface to Agent-to-Agent collaboration: negotiated tasks, escrowed delivery, streaming consumption, platform splits.
Broker#
Agent Payments Protocol's protocol messages (challenge, credential) carry no session memory. State is held by the Broker role.
Any entity willing to take on the following responsibilities can be a Broker — a wallet vendor, an exchange, a DAO, a self-hosted service, or even a counterparty itself:
- Accept the Seller's payment request and mint a
paymentId - Produce the challenge and delivery envelopes (url / card / qrcode / raw)
- Receive the Buyer's credential, verify the signature, match against the stored challenge, and recompute the nonce
- Submit on-chain on behalf of the Buyer (optionally sponsoring gas)
- Expose a status-query endpoint for both sides to poll
The Broker and the x402 Facilitator occupy the same architectural slot but at different scope: the Facilitator is designed for a single HTTP round-trip and is stateless; the Broker shoulders commercial relationships that may span many steps and many days, persisting challenges / paymentIds / vouchers / state machines. See whitepaper §3.3.
Design philosophy#
Agent Payments Protocol upholds four architectural invariants:
- The protocol is stateless; roles are stateful — state lives in the Broker, only messages flow on the transport
- Signature is the source of truth for identity —
payload.authorization.fromis recovered via ECDSA and cannot be forged - Wire-compatible with MPP — Agent Payments Protocol is a strict superset of MPP EVM wire format
- Roles are substitutable; the protocol does not depend on any single operator — any conformant implementation is a legitimate participant
For full philosophical reasoning and detailed design of commerce primitives (built-in splits / pluggable dispute resolution / dual-key metering / cold–hot wallet separation), see Agent Payments Protocol Whitepaper §4 and §8.