How the payment standards compare
Five ways an AI agent can pay, what each one standardizes, and whether Agent GDP counts it.
The comparison
The first columns are properties of the specifications. The last columns are this index, including the live 7 day figures when the rollup has that protocol. "In Agent GDP" means a public settlement rule exists and is turned on. It does not mean the protocol is more important.
Read the specifications for the normative text. This table is a map. The glossary pages go one level down, and the measurement page says what happens to a row after it is in the database.
| Protocol | Standardizes | How value moves | Public settlement | In Agent GDP | 7d volume | 7d share |
|---|---|---|---|---|---|---|
| x402 | How a site asks for payment, how the agent signs it, and how a facilitator settles it. | The agent pays the service, usually in USDC. A facilitator can send that payment on a blockchain. | The USDC transfer a known facilitator submits for the payer, on the chains we read. A router hop counts once. | Yes | $40,133 | 100.0% |
| MPP | Machine payments over HTTP, including a metered session on Tempo. | The agent deposits on Tempo and signs vouchers. The service settles the amount used. | Settled events on Tempo. Card charges are a different record. | Yes | $0.072956 | 0.0% |
| AP2 | A signed permission for an agent to check out and pay. | The payment uses whatever rail the permission names. AP2 itself does not move money. | No ledger of its own. An x402 payment under AP2 is counted once, as x402. | No | — | — |
| ACP | A merchant checkout an agent can run, plus a token that lets the agent pay. | The merchant charges through its own processor. OpenAI is not the seller of record. | No public payment record we can add up. Orders stay with the merchant. | No | — | — |
| L402 | A web challenge with a Lightning invoice and a credential called a macaroon. | The agent pays a Lightning invoice and shows proof with the macaroon. | Lightning invoices are not one public ledger we can read. | No | — | — |
x402
x402 standardizes a payment challenge on a resource. Version 2 specifies the PaymentRequired object, the signed payload, scheme names, and facilitator verify and settle. HTTP is one transport. The economic event this index uses is narrower than the spec: a USDC transfer from a registered facilitator wallet on Base, Polygon, Solana, or Arc. Exact, upto, and batch settlement collapse to that transfer because the log does not distinguish them.
Strength for measurement: the settlement is on a public chain and the payer and payee are in the transfer. Limit: anything that never reaches a registered facilitator is invisible, including a correct x402 payment settled some other way.
MPP
MPP standardizes machine payment, including a 402-style challenge and a Tempo session channel. The session is built for metered work: deposit once, sign many vouchers, settle the delta. Stripe also documents card and shared-payment-token paths and deposit addresses that are not the escrow precompile.
The index uses the precompile only. deltaPaid on Settled, Tempo mainnet, named 6-decimal tokens, one-to-one. That is a real ledger with a real gap. A session that is quoted, opened, and never settled contributes nothing. A Stripe card charge under the MPP name contributes nothing here either.
AP2
AP2 standardizes authority. Version 0.2's checkout mandate and payment mandate tell a merchant and a payment actor what an agent is allowed to do, with hashes binding the mandate to a checkout and with open constraints for budgets and recurrence. The spec calls itself a security feature inside a commerce protocol.
There is nothing to sum until a rail settles. The x402 extension is still x402 when the USDC moves. Treating AP2 as a third series would double-count that movement and would invent numbers for mandates that never settled.
ACP
ACP standardizes merchant checkout inside an agent. OpenAI's spec fixes the session endpoints and the cart the merchant must return. Payment stays on the merchant's processor. Delegated payment tokens, including Stripe shared payment tokens, scope the charge. The merchant is the merchant of record.
That is a large commerce surface with a private ledger. Agent GDP does not scrape processor dashboards and does not estimate ACP from anecdote. The protocol page exists so the omission is explicit.
L402
L402 standardizes a Lightning-backed HTTP challenge: macaroon, BOLT 11 invoice, preimage on the retry. Verification can be stateless because the macaroon commits to the payment hash. Settlement is a Lightning payment, not an ERC-20 transfer and not a Tempo escrow event.
A global sum would require every node's invoices, which do not exist as one public log. The index stops there. It does not sample a node and scale up.
Other names that are not extra volume
Visa Intelligent Commerce, Mastercard Agent Pay, and custodial agent wallets show up in industry comparisons. They are not in the table because they add no public settlement this methodology knows how to attribute. Circle nanopayments and Arc facilitator traffic are x402 when they settle as registered USDC transfers, not a parallel product total. The protocols list is where those metadata rows live in the product.
If two of the five protocols are used in one purchase, count the settlement once, on the rail that actually moved the funds, and cite the other protocol as the authorization or checkout layer. The live shares under the table are already computed that way.
Questions
- Which agent payment protocols does Agent GDP index?
- x402 and MPP session settlements on Tempo. AP2, ACP, and L402 are compared here and listed in the product, and they are not added into the volume because they do not publish an attributable settlement log.
- Can one purchase be counted under two protocols?
- Not in this index. AP2 and ACP can sit on top of another rail. If that rail is an x402 USDC transfer from a registered facilitator, the transfer is counted once, as x402. The mandate or checkout session is not added again.
- Why is a protocol with no volume still listed?
- A zero or a blank means this database has no attributable settlements, not that the protocol has no users. Card captures, Lightning invoices, and signed mandates can be active and still be invisible to a chain indexer.
Related terms
All explainers · Glossary · Methodology
Sources
- x402 Protocol Specification, version 2 — Coinbase x402
- x402 HTTP transport, version 2 — Coinbase x402
- Machine Payments Protocol — Stripe
- Sessions: low-cost high-throughput payments — MPP
- Agentic Payment Protocol specification, v0.2 — AP2
- Agentic Checkout Spec — OpenAI
- Agentic commerce key concepts — OpenAI
- L402 protocol specification — Lightning Labs
- Agent GDP methodology — Agent GDP