Agentic AI Wiki
AI Blog / x402 vs AP2 vs ACP vs MPP: The Only Difference That Changes Your Risk
AI Blog

x402 vs AP2 vs ACP vs MPP: The Only Difference That Changes Your Risk

Four agent-payment standards, usually compared on rails. The axis that matters is where the spending cap is stored — a pre-funded wallet, an issuer rule, a one-checkout token, or a mandate the user signed — because that fixes how much a prompt-injected agent can spend before anything else gets a vote.

By Agentic AI Wiki 11 min read

Four standards now let an agent pay for something, and the comparison everyone writes is about rails — cards versus stablecoins, HTTP versus checkout API. That is the wrong axis. They disagree about where the spending limit is stored, and that single choice fixes how much a prompt-injected agent can spend before anything else in your stack gets a vote. Pick the protocol that holds the cap where you can defend it, and the rail question answers itself.

At a glance

These four are usually presented as rivals. They are not — they occupy different layers, and a real deployment uses two or three of them together. What follows is the shape of each before we get to the part that matters.

ProtocolWhoLayerSettles over
x402 Coinbase Developer Platform; governance now under the Linux Foundation, with Google, Visa, Mastercard, Stripe, AWS and Circle behind it. Transport. Revives the dormant HTTP 402 Payment Required so an agent can pay per request. Stablecoins, predominantly USDC, on Base and Solana. Zero protocol fees.
MPP Stripe and Tempo, launched alongside the Tempo mainnet in March 2026. Settlement for machine buyers — APIs, compute, digital services. Stripe's existing rails via PaymentIntents, plus a Visa card spec and SDK built on Visa Intelligent Commerce.
ACP OpenAI and Stripe, who maintain the spec. PayPal joined as a second compliant provider. Checkout. Cart, product feed, orders, delegated payment, and an MCP binding. Whatever the buyer already uses, brokered through a Shared Payment Token.
AP2 Google with 60+ launch partners; governance donated to the FIDO Alliance. Authorization. Three signed mandates — Intent, Cart, Payment — as W3C Verifiable Credentials. Rail-agnostic by design: cards, bank transfer, or crypto through an x402 extension.
Four agent-payment protocols placed on the stack they occupy A vertical stack between an agent and a merchant or API. AP2 sits at the authorization layer carrying signed mandates. ACP sits at the checkout layer carrying a shared payment token. x402 and MPP sit at the settlement and transport layer. Underneath, card networks provide issuer authorization through Visa Trusted Agent Protocol and Mastercard Agent Pay. Agent acting for a user Merchant or metered API AUTHORIZATION — WAS THIS ALLOWED? AP2 Intent · Cart · Payment mandates, signed as W3C Verifiable Credentials Google, 60+ launch partners, governance donated to the FIDO Alliance. Produces evidence, not enforcement. CHECKOUT — WHAT IS IN THE CART? ACP Cart, feed, orders, and a Shared Payment Token scoped to one checkout OpenAI and Stripe. Live surface: Instant Checkout in ChatGPT. The agent never holds a card number. SETTLEMENT — MOVE THE MONEY x402 HTTP 402 revived; pay-per-request from a pre-funded wallet. Coinbase. MPP Machine payments for APIs and compute. Stripe and Tempo. EXISTING RAILS Card networks — Visa Trusted Agent Protocol, Mastercard Agent Pay Issuer authorization rules, agent attestation, and the chargeback you already have
Stacked, not queued. The question is which pair you need, not which one wins.

The only question that changes your risk

Every agent that can spend money has a number attached to it: the most it can spend before a human, a bank or a server says no. Call it the cap. Each of these four protocols stores that cap somewhere different, and the storage location determines everything about what happens on a bad day.

Where the spending limit lives in each protocol Four columns for x402, MPP, ACP and AP2, compared across three rows: where the cap is stored, who can raise it, and what a compromised agent can spend. x402 stores the cap in a pre-funded wallet balance, MPP and the card rails store it in issuer authorization rules, ACP stores it in a per-checkout shared payment token, and AP2 stores it in a mandate the user signed. CAP LIVES IN RAISED BY IF INJECTED x402 MPP + card rails ACP AP2 The wallet balance you pre-funded. The issuer's authorization rules. A token minted for exactly one checkout. A mandate the user signed, in the request. Anyone who can top the wallet up. The bank, on its own risk model. Nobody — you mint a new one instead. Only the user, with a fresh signature. The whole balance, irreversibly. Up to the limit — but chargeable back. One cart, at the price you approved. Nothing new — if the merchant checks. STRONGEST CONTAINMENT AT THE RIGHT, AND IT DEPENDS ON A VERIFIER THAT MAY NOT EXIST YET
Read the bottom row first. It is the row you will be explaining to someone.

In x402 the cap is the wallet balance. There is no per-payment authorization step by design — that is the point of the protocol, and it is why it works for sub-cent API calls at a volume the other three cannot approach. It also means a compromised agent's spending limit is exactly what you pre-funded, the payments are irreversible, and no third party is positioned to refuse one. Security researchers have already published attack families against x402 flows for this reason; the protocol is not broken, it simply has no opinion about authorisation.

In MPP and the card specs beneath it, the cap is the issuer's authorization rules — the same machinery that already declines your card in an unusual country. That is the most battle-tested option on the list, and it comes with the one property none of the others have: a chargeback. Money moved wrongly can move back.

In ACP the cap is the Shared Payment Token, minted by the payment provider for exactly one checkout at a price the buyer saw. The agent never holds a credential that works twice. Blast radius is one cart.

In AP2 the cap travels inside the request as a mandate the user cryptographically signed — "running shoes, size 10, under $150" — and the merchant can verify it independently. That is the tightest scoping of the four, and it carries the largest asterisk on this page.

Evidence is not enforcement

AP2's mandates are frequently described as a safety feature. They are a non-repudiation feature, which is a different thing with a different failure mode. A signed Intent Mandate proves, afterwards, that the user authorised a class of purchase and that the agent stayed inside it — or proves that it did not. It does not stop anything. It cannot: the mandate is verified by the merchant, and the merchant's incentive to reject a sale is weaker than yours.

Compare that with ACP, where the payment provider refuses a second use of the token, or MPP, where the issuer declines the authorization. Those are enforcement: a party that is not the agent, and not the merchant, says no at the moment of the payment.

So the taxonomy that actually helps is not "cards versus crypto". It is:

  • Enforcement — someone independent can refuse in flight. ACP's token, the issuer's rules, and any spending proxy you run yourself.
  • Evidence — someone can prove afterwards what was authorised. AP2's mandates, and the receipt trail your own audit log keeps.

You want both, and no single protocol on this list gives you both. Research red-teaming AP2 with prompt injection makes the point concretely: an attacker who cannot forge a signature can still influence what the user is asked to sign. A mandate signed under a manipulated description is a perfectly valid mandate.

Agent payment protocols across four properties Heatmap matrix with rows for x402, MPP, ACP and AP2 and columns for enforcement at the moment of payment, after-the-fact evidence, reach without crypto rails, and live consumer checkout today. Each cell is marked strong, medium or weak. Where each protocol is strong Refuses a bad payment in flight Proves who authorised what Works with no crypto rail Live consumer checkout today x402 Medium Medium Weak Weak MPP Strong (issuer) Medium Strong (cards) Medium ACP Strong (token) Medium Strong Strong AP2 Weak on its own Strong (mandates) Strong Weak Weak Medium Strong
No row is strong across all four columns, which is why real stacks combine them.

Cloudflare's wallet product is the argument in miniature

The clearest evidence that the cap location is the real design question came this month from a company that shipped on top of x402 rather than instead of it. Cloudflare Wallets lets a human fund an Account Wallet and then delegate capped spending to agents through Virtual Wallets, settling in stablecoins over x402 alongside its Monetization Gateway.

Read the shape of that product. x402 supplies the payment mechanism and nothing else; Cloudflare added the layer x402 deliberately omits — a per-agent limit, held by a party that is neither the agent nor the merchant, that can refuse. That is the enforcement layer, rebuilt at the infrastructure vendor because the protocol does not carry one.

If you adopt x402 without building or buying that layer, you have adopted a pre-funded, irreversible, unrefusable payment channel wired directly into a system that reads untrusted text for a living. The right mental model is scoped credentials: the wallet is a credential, and an unscoped one.

When to pick which

You are building…Start withAdd
An agent paying for APIs, data or compute per call x402 — nothing else settles at that size, and it charges no protocol fee A capped virtual wallet per agent. Buy it or build it; do not skip it.
A shopping agent buying physical goods for a consumer ACP — the merchant integrations and the live surface already exist AP2 mandates if you need to prove intent to a regulator or an insurer.
An enterprise agent spending against a corporate card MPP with the card rails underneath — you inherit issuer controls and chargebacks Your own pre-authorization step for anything above a threshold you set.
A platform where third-party agents transact with your merchants AP2 — you need verifiable evidence of who authorised what, per transaction An enforcement layer of your own. The mandate proves; it does not prevent.

One recommendation cuts across all four rows. Whatever you adopt, keep a spending decision outside the agent loop — a proxy, a policy service, a human gate above a threshold — because every protocol here assumes the caller is honest about what it is buying, and the caller is a language model reading text written by strangers. See human in the loop for where to place that gate, and AP2 and agent commerce for the mandate mechanics in detail.

FAQ

Do I have to choose one of these?

No, and choosing exactly one is the common mistake. They sit at different layers: AP2 authorises, ACP checks out, x402 and MPP settle. A shopping agent plausibly uses AP2 mandates over an ACP checkout; an API-consuming agent uses x402 under a wallet with caps.

Is x402 unsafe?

It is unopinionated, which becomes unsafe when you wire it to an autonomous agent without a limit layer. The protocol was designed for machine-to-machine micropayments where the payer is a program you wrote. An agent that reads web pages is a different payer, and published attack analyses of x402 flows are worth reading before you fund a wallet.

Which one has real production volume?

x402 by a wide margin on transaction count — well over a hundred million payments across Base and Solana — because per-request API payments are high-frequency and tiny. ACP has the most consumer-visible volume through Instant Checkout in ChatGPT. Those are different meters and comparing them directly is meaningless.

What happens when an agent buys the wrong thing?

Under MPP and the card rails: a chargeback, the same as any card dispute. Under ACP: a merchant refund through the normal order flow. Under x402: the stablecoin is gone. Under AP2: you have cryptographic proof of what was authorised, which helps you argue and does not by itself return the money. This is usually the deciding fact for anyone with a finance team.

Further reading

On this wiki:

Protocol sources: