Protocols · Comparison matrix
How do the rails differ, and which is used for what?
Four payment rails for agentic commerce, side by side. This table describes; it does not rank.
How should I read this table?
Every cell is qualitative, and every factual cell links the primary source it came from. Where a backer has published nothing on a point, the cell says so plainly instead of guessing. The rails appear in the one alphabetical order used on every page of this site — the order is not a ranking, and neither is anything else here. One column, verified on-chain activity, is reserved for numbers: it fills only from recomputable public data, once our verification engine is live.
| Rail | Backer & governance | Money type | Authorization model | Receipt & proof | Dispute model | Payment-size sweet spot | Status today | Openness (spec license) | Where it runs today | Verified on-chain activity reserved |
|---|---|---|---|---|---|---|---|---|---|---|
| AP2 & UCP | Backed by Google. AP2 standardization continues in FIDO Alliance working groups; UCP is published as open source and co-designed with industry partners. AP2 spec site · Google UCP guide | A permission layer above the money movement. AP2’s first version supports card payments; its published roadmap adds e-wallets, real-time bank transfers, and digital currencies. AP2 spec site | Mandates — signed verifiable digital credentials. A Checkout Mandate captures the agreed purchase; a Payment Mandate authorizes payment from a specific instrument. AP2 spec site | Mandates chain into a non-repudiable cryptographic audit trail, for both human-present and human-not-present purchases. AP2 spec site | The audit trail is designed to aid dispute resolution. The protocol moves no money itself, so reversal rules stay with the payment method used. AP2 spec site | Not stated in the specification. The protocol covers both human-present and human-not-present purchases. AP2 spec site | Published specification: AP2 v0.2, announced 2025-09-16, donated to the FIDO Alliance. UCP checkout is live on AI Mode in Google Search and Gemini on the web. AP2 spec site · Google UCP guide | Open specifications, Apache 2.0 — both repositories. AP2 repository · UCP repository | UCP: Google’s AI surfaces, with merchant onboarding by waitlist. AP2: published samples, and an extension of the A2A agent protocol. Google UCP guide · AP2 spec site | No public settlement data published by Google. |
| Stripe machine payments | Backed by Stripe. The Machine Payments Protocol (MPP) is co-authored by Tempo and Stripe; Stripe is also a founding participant in the x402 Foundation. MPP announcement · Linux Foundation press release | Stablecoins, plus cards and buy-now-pay-later via Shared Payment Tokens. Funds settle into the business’s existing Stripe balance, in its default currency. MPP announcement | Payment credentials scoped to the purchase: Shared Payment Tokens are limited to a specific business, bounded by time or amount, and revocable at any time. Stripe SPT announcement | Payments appear in the Stripe API and Dashboard like any other transaction, with standard reporting and accounting integrations. MPP announcement | Stripe’s standard infrastructure applies to MPP payments, including refunds and fraud protection. MPP announcement | “Microtransactions, recurring payments, and more.” Early adopters charge per API call and per browser session. MPP announcement | Live. MPP launched 2026-03-18 with named businesses accepting agent payments; Shared Payment Tokens were introduced 2025-10-07. MPP announcement · Stripe SPT announcement | MPP specification documents are public domain (CC0 1.0) in the Tempo–Stripe spec repository. MPP spec repository | On Stripe’s rails, through the PaymentIntents API; stablecoin payments settle over supported networks such as Tempo. MPP announcement | No public settlement data published by Stripe. |
| Verifiable Intent & Agent Pay | Backed by Mastercard, in collaboration with Google. Verifiable Intent builds on FIDO Alliance, EMVCo, IETF, and W3C specifications, and is designed to be protocol-agnostic. Mastercard announcement | Card payments on Mastercard’s network: the cardholder authorizes the agent; the card moves the money. Mastercard announcement | A signed delegation chain: the issuer signs a credential, the user sets constraints, the agent proves scope — eight constraint types, including amount bounds, merchant allowlists, and budget caps. Verifiable Intent spec site | A tamper-resistant record linking identity, intent, and action, with selective disclosure: only the minimum necessary detail is shared, and only when needed. Mastercard announcement | Card-network dispute machinery, plus the record above: “If a dispute occurs, all parties can rely on a clear audit trail.” Mastercard announcement | Not yet published by Mastercard. | Specification open-sourced 2026-03-05 (Draft v0.1); Agent Pay integration announced as forthcoming at that date. Agent Pay for Machines launched 2026-06-10. Mastercard announcement · Agent Pay for Machines press release | Open specification, Apache 2.0, on GitHub and verifiableintent.dev. Verifiable Intent repository | Across Mastercard’s network and named partner platforms; the machine-payments program launched 2026-06-10. Agent Pay for Machines press release | No public settlement data published by Mastercard. |
| x402 | Created by Coinbase; stewarded by the x402 Foundation under the Linux Foundation since 2026-04-02. The Foundation was initially developed by Coinbase, Cloudflare, and Stripe. Linux Foundation press release | Stablecoins are the primary use case; the specification is deliberately network- and token-agnostic. x402.org · x402 repository | Pay-per-request: the buyer signs a payment payload for each request against the server’s stated price; a facilitator verifies and settles it. x402 repository | Settlement is a public-ledger transaction: the server returns a settlement response, and anyone can inspect the payment on-chain. x402 repository | None defined in the protocol — the flow specifies verify and settle steps, no reversal step. Any dispute process must be built on top. x402 repository | Instant, low-cost per-request payments for digital services: API monetization, paywalled content, agentic commerce. x402.org | Live in production, per the protocol’s own site; governance moved to the x402 Foundation 2026-04-02. x402.org · Linux Foundation press release | Open standard, Apache 2.0. x402 repository | Any HTTP service can adopt it; reference SDKs cover many networks. Our engine will measure the USDC-on-Base slice. x402 repository | Measured by our engine — coming. See how we verify. |
What does this table leave out?
Specs change. This table was last reviewed on 2026-09-01; the linked sources may have moved since, and they win over us.
Announced is not shipped. A press release proves an announcement, not adoption. Where usage cannot be verified from public data, no usage claim appears here.
Adoption numbers without public data are excluded by policy. That is why the only numeric column waits for our engine — the bar it must clear is in the methodology.
The rails are not equally measurable, and that is a fact, not a ranking. x402 settles on public ledgers anyone can inspect; the card-side rails settle on private networks. So one column can eventually carry independent numbers, and the others can only carry what their backers publish.
What changed on this page?
- 2026-09-01 — first publish.