# Which agentic-payment rail can a seller accept today? > A sourced, neutral comparison of the three agentic-payment standards — x402, Google's AP2, and the Stripe/Tempo Machine Payments Protocol — from the point of view of a developer wiring an endpoint. Published 2026-06-28 · Updated 2026-08-16 · HTML version: https://invoket.com/blog/x402-vs-ap2-vs-stripe-mpp-choosing-rails-2026 --- A seller wiring a paid endpoint has to decide what it will accept — and by mid-2026 there is no single "agent payment standard" to accept. There are at least three, built to solve different problems. **x402** settles one stablecoin payment per HTTP request, and a seller can put it in front of an endpoint on its own. **AP2** (Google's Agent Payments Protocol) defines signed *mandates* that prove a user authorized an agent to pay, across card and crypto rails — an authorization layer above whatever settles underneath. **The Machine Payments Protocol (MPP)** from Stripe and Tempo lets an agent authorize a spending budget once and stream many small payments against it. This article compares them on the axes a developer wiring an endpoint actually cares about — what gets settled, where, who governs it, and granularity — and says where each fits. None of them "wins"; they overlap at the edges and increasingly interoperate. ## They sit at different layers The first thing to get right is that x402, AP2 and MPP are not three brands of the same thing. Roughly: - **x402** is a **settlement protocol** at the HTTP layer: how a server demands payment for a request and how a client pays it. - **AP2** is an **authorization protocol**: how an agent proves it was authorized to spend, with an audit trail, independent of the rail underneath. - **MPP** is a **settlement-plus-budgeting protocol** built on a payments chain: how an agent commits a spending limit and settles a stream of small payments. So "x402 vs AP2" is partly a category error — AP2 explicitly *extends* to crypto via an A2A x402 extension (more below). The real choice for a developer is which model matches the call pattern you are building. ## x402: one on-chain payment per request [x402](https://github.com/coinbase/x402) embeds payment into the HTTP request/response cycle: a server answers an unpaid request with `402 Payment Required` plus payment requirements, the client signs a stablecoin transfer for one of the offered rails and replays the request, and a facilitator verifies and settles it on-chain. One request, one settlement, no account or key — the model covered in [Why an API key does not work for an autonomous agent](/blog/why-agents-pay-per-call-instead-of-api-keys) and [What happens between a 402 challenge and the paid response](/blog/how-an-agent-discovers-and-buys-a-paid-api). Originally introduced by Coinbase, x402 moved to neutral governance on **April 2, 2026**, when the Linux Foundation announced it would host the **x402 Foundation** with the protocol contributed by Coinbase and early participation from Google, Microsoft, AWS, Cloudflare, Stripe, Visa, Mastercard, American Express, Circle and others ([Linux Foundation press release](https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol), [The Block](https://www.theblock.co/post/396155/tech-crypto-giants-to-help-steward-coinbases-neutral-x402-payments-protocol-under-linux-foundation)). The settlement is a real on-chain transfer per call, which is its strength (no standing credential, instant finality) and its constraint (a chain transaction per request is heavy if you call thousands of times a minute). ## AP2: signed mandates that prove authorization Google announced the **Agent Payments Protocol (AP2)** on **September 16, 2025** ([Google Cloud blog](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)). AP2 addresses a different gap: when an agent pays on a user's behalf, how does the *merchant* know the user actually authorized that purchase? Its answer is the **mandate** — a cryptographically signed, tamper-proof credential. AP2 defines an **Intent Mandate** (the user's delegated instruction, e.g. price limits and conditions) and a **Cart Mandate** (a signed record of the exact items and price), which together form a non-repudiable audit trail of who authorized what. AP2 is **rail-agnostic**: it works with cards (via Mastercard, Visa, American Express) and with crypto. The crypto path is the **A2A x402 extension**, co-developed by Google with Coinbase, the Ethereum Foundation and MetaMask, which lets AP2 mandates carry crypto payment authority — packaged as an extension to Google's A2A (Agent-to-Agent) protocol so authorization travels across multi-agent hops ([Google Cloud blog](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol)). In other words, AP2 can sit *on top of* x402 rather than competing with it. ## MPP: a spending session, settled in aggregate The **Machine Payments Protocol (MPP)** launched on **March 18, 2026**, co-authored by **Stripe and Tempo** (a payments-oriented blockchain), alongside Tempo's mainnet ([Stripe blog](https://stripe.com/blog/machine-payments-protocol)). MPP targets the high-frequency case: rather than one on-chain transaction per request, an agent authorizes a **spending limit upfront** and then streams many micropayments against that **session**, settled in aggregate rather than one transfer at a time — useful when an agent hits a data feed thousands of times an hour ([WorkOS comparison](https://workos.com/blog/x402-vs-stripe-mpp-how-to-choose-payment-infrastructure-for-ai-agents-and-mcp-tools-in-2026)). For a Stripe business, the resulting agent payments appear in the dashboard and settle into the existing balance like any other transaction. ## Side-by-side | | **x402** | **AP2** | **MPP** | |---|---|---|---| | **Primary role** | Per-request settlement over HTTP | Authorization / proof of consent | Budgeted settlement for high-frequency calls | | **Unit of payment** | One stablecoin transfer per request | Rail-agnostic (carries a mandate) | Many micropayments per session | | **On/off-chain** | On-chain per call | Rail-agnostic (card or crypto) | On-chain (Tempo), settled in aggregate | | **Key primitive** | `402` challenge + signed payload | Intent & Cart mandates | Spending session / limit | | **Stewardship** | x402 Foundation, Linux Foundation (Apr 2, 2026) | Google + 60+ partners (Sep 16, 2025) | Stripe + Tempo (Mar 18, 2026) | | **Best when** | Discrete, occasional paid calls; no account | You need a verifiable consent trail across rails | A long stream of tiny, frequent payments | Dates and stewardship reflect the announcements cited in *Sources*; this is a fast-moving area — re-check status before relying on it. ## When to reach for which From the seat of a developer wiring an endpoint: - **Discrete, pay-as-you-go calls with no relationship to maintain** — an agent that needs *one* IBAN check or *one* climate value — map cleanly to **x402**: no account, no budget to provision, settlement travels with the request. - **You must prove a human authorized the spend**, possibly across mixed card and crypto rails and across several agents, lean toward **AP2's mandate model** — and note it can ride x402 for the crypto leg via the A2A x402 extension. - **A single agent makes a long, dense stream of tiny payments** to the same kind of resource — high-frequency metering — is where **MPP's session/budget** model avoids a per-call on-chain transaction. These are tendencies, not rules, and the lines blur: AP2 layering over x402 is the clearest example that the standards compose more than they exclude. ## Where Invoket sits Invoket's endpoints speak **x402**: an agent discovers a resource, reads its price and rails, and settles per call — the [For agents](/docs/for-agents) page covers discovery, the [Quickstart](/docs/quickstart) shows the runnable probe → sign → replay, and [Payments and rails](/docs/payments-and-rails) explains atomic amounts and accepted networks. That is a deliberate scope choice for discrete paid calls, not a claim that x402 is the right rail for every workload — for streamed metering or a cross-rail consent trail, AP2 or MPP may fit better. As always, the actual assets, networks and prices come live from the [catalog](https://api.invoket.com/catalog); this article compares models, it does not quote anyone's prices. ## Sources - x402 protocol and governance — [coinbase/x402 (GitHub)](https://github.com/coinbase/x402), [Linux Foundation: launching the x402 Foundation](https://www.linuxfoundation.org/press/linux-foundation-is-launching-the-x402-foundation-and-welcoming-the-contribution-of-the-x402-protocol) (Apr 2, 2026), [The Block](https://www.theblock.co/post/396155/tech-crypto-giants-to-help-steward-coinbases-neutral-x402-payments-protocol-under-linux-foundation). - AP2 — [Announcing the Agent Payments Protocol (AP2), Google Cloud blog](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) (Sep 16, 2025). - MPP — [Introducing the Machine Payments Protocol, Stripe blog](https://stripe.com/blog/machine-payments-protocol) (Mar 18, 2026), [WorkOS: x402 vs Stripe MPP](https://workos.com/blog/x402-vs-stripe-mpp-how-to-choose-payment-infrastructure-for-ai-agents-and-mcp-tools-in-2026).