x402 vs AP2 vs Stripe MPP: choosing rails in 2026
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.
By mid-2026 there is no single “agent payment standard” — there are at least three, and they were built to solve different problems. x402 settles one stablecoin payment per HTTP request. AP2 (Google’s Agent Payments Protocol) defines signed mandates that prove a user authorized an agent to pay, across card and crypto rails. 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 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 agents pay per call instead of API keys
and 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, The Block). 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). 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). 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). 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). 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 page covers discovery, the Quickstart shows the runnable probe → sign → replay, and 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; this article compares models, it does not quote anyone’s prices.
Sources
- x402 protocol and governance — coinbase/x402 (GitHub), Linux Foundation: launching the x402 Foundation (Apr 2, 2026), The Block.
- AP2 — Announcing the Agent Payments Protocol (AP2), Google Cloud blog (Sep 16, 2025).
- MPP — Introducing the Machine Payments Protocol, Stripe blog (Mar 18, 2026), WorkOS: x402 vs Stripe MPP.