Agent Payments Protocol#
An open protocol for Agent commerce
Agent Payments Protocol teaches Agents to do business — a commercial relationship, not just an HTTP response.
This page is an overview of Agent Payments Protocol. For the full content, see:
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.
Earlier Agent payment work compressed the problem into "a single HTTP response"; Agent Payments Protocol generalizes the unit of interaction from "a single HTTP 402" to a complete commercial relationship.
Agent Payments Protocol can be summarized in one equation:
Agent Payments Protocol = MPP EVM + four intent envelopes + Broker orchestration + cross-IM/HTTP transport
- MPP EVM: Agent Payments Protocol is wire-compatible with MPP, directly consuming the MPP EVM challenge / credential structure
- Four intent envelopes:
charge/escrow/session/upto— each capturing a distinct shape of commercial interaction - Broker orchestration: a protocol-defined role that absorbs the orchestration burden (not a specific operator)
- Cross-channel transport: HTTP, XMTP, Telegram, Discord, Slack, Email, SMS, deep links, QR, offline — anything that can carry text
The four intents#
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 |
The four intents cover the commercial surface: one-shot, escrowed, streaming, capped — each is an independent composition.
The four payment methods Onchain OS Payment currently provides (One-time / Batch / Pay-as-you-go / Escrow) are product-level realizations of the protocol intents above. See Core Concepts for detailed mappings and the underlying protocol.
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 — a protocol-defined role#
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.
Relation to x402 / MPP#
Agent Payments Protocol is not a competitor to x402 / MPP — it adopts MPP's wire format, layers four intent shapes on top, is orchestrated by a Broker, and ultimately becomes a productized protocol layer for IM-based multi-channel delivery.
| Protocol | Layer | How Agent Payments Protocol composes with it |
|---|---|---|
| x402 | HTTP 402 middleware | Agent Payments Protocol is wire-aligned with x402 at the request layer (charge can emit an x402-shaped 402) and extends the same idea into IM / QR / offline |
| MPP | EVM payment method + session spec | Agent Payments Protocol is a strict superset of the MPP EVM challenge / credential wire format. Integrating MPP EVM means already integrating Agent Payments Protocol's charge |
Where x402 already fits, Agent Payments Protocol defers to it; when the conversation moves off HTTP or beyond a single round-trip, Agent Payments Protocol extends with the same vocabulary.
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 / signing-custody separation), see Agent Payments Protocol Whitepaper §4 and §8.