x402 vs AP2 vs ACP vs MPP: which agent-payment protocol do you actually need?

If you've tried to figure out how to take payments from AI agents this year, you've hit the acronyms: x402, AP2, ACP, MPP — and if you go back far enough, L402. Every one of them launched with a post explaining why it's the future of agent commerce. Almost none of them explain how they fit together, which is the thing you actually need to know before you build.

Here's the short version, and it's the most useful sentence in this post: these are mostly layers, not rivals. A real agent transaction can touch three or four of them at once. Once you see which layer each one occupies, "which should I use?" stops being a fight and becomes a checklist.

The four layers of an agent payment

Think of an agent buying something the way you'd think of the web stack — different protocols owning different jobs:

• Identity — is this agent who it claims to be? (Web Bot Auth and friends.)
• Authorization — did a human actually approve this purchase, and within what limits? (AP2.)
• Checkout — how does the agent complete a purchase with a specific merchant? (ACP.)
• Settlement — how does the money actually move for this request? (x402, MPP, L402.)

Most of the confusion comes from comparing a settlement protocol to an authorization protocol as if they were the same kind of thing. They aren't. Let's take them in order.

AP2 — authorization (Google)

Agent Payments Protocol answers a trust question, not a money-movement question: did a human mandate this purchase? It uses verifiable credentials — signed "mandates" — to prove an agent was authorized to spend on a person's behalf, and for what. It's backed by a large consortium and has been moving toward standards-body governance, with newer versions reaching toward "human not present" autonomous spending.

AP2 doesn't move money by itself. It's the permission slip. It can sit on top of a settlement layer — including x402 — so that "the human approved this" and "the payment cleared" are two separate, verifiable facts.

ACP — merchant checkout (OpenAI / Stripe)

Agentic Commerce Protocol is about completing a purchase with a merchant. It's the machinery behind "buy it inside the chat" experiences — a small set of checkout endpoints a merchant exposes so an agent can place an order. It's consumer-commerce shaped: products, carts, orders, fulfillment, returns.

If you're a Shopify-style merchant selling physical or digital goods to consumers through an AI assistant, ACP is your world. If you're a developer selling API calls or tool invocations to autonomous agents, it mostly isn't — there's no cart and no fulfillment in a single metered API request.

MPP — Stripe-mediated settlement (Stripe + Tempo)

Machine Payments Protocol, co-authored by Stripe and Tempo, is built on the same HTTP 402 challenge-response as x402: an unpaid request gets a 402 with payment challenges, the agent authorizes and retries with a credential, and each payment is independent — there's no pre-authorized session or budget aggregation in the base protocol. What MPP adds is Stripe's rails and lifecycle — settlement in stablecoin (on Tempo) or fiat (cards via Shared Payment Tokens), plus recurring-subscription and streaming primitives, wrapped in Stripe's compliance, fraud screening, and reporting (with card-path disputes and chargebacks). It speaks both HTTP and MCP.

MPP shines when you want subscription or streamed billing and already run on Stripe; x402 stays leaner for the anonymous, one-off call. We compared them in depth in x402 vs Stripe's MPP, and the short of it: both share the 402 base — MPP layers Stripe's lifecycle and rails on top.

x402 — per-call settlement (HTTP-native)

x402 revives HTTP 402 Payment Required as a real, working mechanism. A monetized resource answers an unpaid request with a signed 402 challenge quoting a price; the caller pays in USDC and retries with proof; the server verifies and serves. There are no accounts, no sessions, no keys — the protocol is the entire surface. It's governed by the x402 Foundation under the Linux Foundation, with founding members spanning the card networks, the clouds, and Stripe itself.

x402's sweet spot is the discrete, anonymous, one-off call: a search, an enrichment, a model inference, a tool result, a scraped page. The unit you sell is the unit you charge for, and the caller can be an agent you've never met and will never see again. That's the agentic web's long tail, and it's exactly what API keys and plans were bad at — see x402 vs API keys.

L402 — the Lightning predecessor

Worth naming because it's the most common "isn't x402 just…?" objection. L402 does HTTP-402-style paid requests over Bitcoin's Lightning Network using macaroons. It predates x402, settles sub-cent and sub-second, and is more private — but it lives in the Bitcoin ecosystem with Bitcoin's volatility. If you're already on Lightning, it's a real option; we cover the trade-offs in Payrelayer vs L402.

So which do I actually use?

Match the layer to what you're building:

And the combinations are normal, not exotic. An agent can carry an AP2 mandate (authorized), present a verified identity, check out through ACP with a merchant, and settle the actual API calls underneath with x402. You don't pick one and reject the rest; you pick the layer your problem lives in and let it compose with the others.

The honest bottom line

If your job is "let autonomous agents pay my API or tool for a single call, with no signup," x402 is the default and the others are either above it (authorization, checkout) or adjacent to it (session billing, Lightning). The integration is small — a five-minute developer guide and one middleware across nine SDKs — and nothing about choosing x402 stops you from adding an AP2 mandate check or an MPP path later. Pick the layer, ship the endpoint, compose the rest when you need it.

Next steps

• The deep dive on the closest comparison: x402 vs Stripe's MPP
• The model x402 replaces: x402 vs API keys
• See every option side by side: the comparison hub
• Ship a paid endpoint today: developer integration guide · create an account