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

x402AP2MPP
Primary rolePer-request settlement over HTTPAuthorization / proof of consentBudgeted settlement for high-frequency calls
Unit of paymentOne stablecoin transfer per requestRail-agnostic (carries a mandate)Many micropayments per session
On/off-chainOn-chain per callRail-agnostic (card or crypto)On-chain (Tempo), settled in aggregate
Key primitive402 challenge + signed payloadIntent & Cart mandatesSpending session / limit
Stewardshipx402 Foundation, Linux Foundation (Apr 2, 2026)Google + 60+ partners (Sep 16, 2025)Stripe + Tempo (Mar 18, 2026)
Best whenDiscrete, occasional paid calls; no accountYou need a verifiable consent trail across railsA 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