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 — session-based settlement (Stripe)

Machine Payments Protocol is a settlement layer built for sessions. An operator authorizes a spending budget upfront; over a long-running task the agent draws against that budget, and Stripe aggregates the many small draws rather than running each one through a full charge. It speaks both HTTP and MCP, settles in stablecoins or fiat, and inherits Stripe's compliance, disputes, and chargebacks.

MPP shines when one agent makes many calls in one session and you want them billed as a stream. We compared it to x402 in depth in x402 vs Stripe's MPP, and the short of it: MPP optimizes the session; x402 optimizes the single call.

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 Paywall 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