Get the latest on AI, LLMs & developer tools
New MCP servers, model updates, and guides like this one — delivered weekly.
The Short Answer
There is no single winner, because the four protocols solve different problems. AP2 is an authorization layer, ACP is merchant checkout, x402 is a crypto payment rail, and MPP is a machine-to-machine payment protocol. Asking which one wins is a bit like asking whether HTTP beats TLS.
If you want a recommendation to start from: building consumer shopping into an assistant points you at ACP; monetizing an API for other agents points you at x402 or MPP; and if you care most about proving a user authorized a purchase across any rail, anchor on AP2 and add a rail underneath it. For the wider landscape and the players involved, the agentic payments explainer is the companion to this comparison.
What Each Protocol Is
Four quick definitions before the table. Each gets one job; keep the job in mind and the rest of the comparison falls into place.
AP2 — Agent Payments Protocol (Google)
Announced on September 17, 2025, AP2 is an open protocol built on top of A2A and MCP. It frames agent payments around three problems: authorization, authenticity, and accountability. Its core idea is the cryptographically signed mandate. An Intent Mandate captures what the user asked for, a Cart Mandate captures the exact items and price, and a Payment Mandate ties the charge to that consent. AP2 is payment-agnostic, so the same mandates can ride cards, stablecoins, or real-time bank transfers, and it launched with 60+ partners including Mastercard, PayPal, Amex, and Coinbase. Its crypto extension is x402.
ACP — Agentic Commerce Protocol (OpenAI + Stripe)
ACP standardizes the checkout and order flow between an agent and a merchant: the cart, the order, and the handoff of payment. It uses Shared Payment Tokens and settles on cards and fiat through Stripe. ACP is what powered ChatGPT's Instant Checkout. Worth noting: press reports say the standalone Instant Checkout feature was wound down in March 2026. The protocol underneath is a separate, open spec, so treat the product status as reported and the spec as its own question.
x402 — Coinbase
x402 revives the long-dormant HTTP 402 “Payment Required” status code so a server can ask for money mid-request and an agent can pay on the spot. Built by Coinbase with the Ethereum Foundation and MetaMask, it carries instant stablecoin micropayments over plain HTTP, which makes it a natural fit for machine-to-machine spend and API monetization. It also ships as the stablecoin and crypto extension of AP2, so the two are designed to work together rather than against each other.
MPP — Machine Payments Protocol (Stripe + Tempo)
Announced on March 18, 2026, MPP is Stripe and Tempo's open protocol for agents and services to coordinate payments programmatically — microtransactions, recurring charges, pay-per-call. Like x402, it revives HTTP 402. Under the hood it uses Stripe PaymentIntents and Shared Payment Tokens, supports stablecoin and fiat, and settles on Tempo, the Stripe and Paradigm stablecoin Layer 1. Early adopters named at launch include Browserbase, PostalForm, and Prospect Butcher.
Side by Side
The same four protocols, lined up by what they are, who is behind them, the layer they solve, the rails they move money on, and where they stand as of 2026.
| Protocol | Backed by | Layer it solves | Rails | Status (date) |
|---|---|---|---|---|
| AP2Agent Payments Protocol (Google) | Google, with 60+ launch partners (Mastercard, PayPal, Amex, Coinbase) | Authorization: proving a user genuinely authorized what the agent bought | Payment-agnostic — cards, stablecoins, real-time bank transfers | Announced Sep 17, 2025; open |
| ACPAgentic Commerce Protocol (OpenAI + Stripe) | OpenAI and Stripe | Merchant checkout: the agent-to-merchant cart and order flow | Cards / fiat via Stripe, using Shared Payment Tokens | Live; powered ChatGPT Instant Checkout (standalone feature reportedly wound down Mar 2026) |
| x402x402 (Coinbase) | Coinbase, with the Ethereum Foundation and MetaMask | The payment rail: instant machine micropayments over HTTP | Stablecoins over HTTP, reviving the 402 status code | Live; ships as AP2's stablecoin/crypto extension |
| MPPMachine Payments Protocol (Stripe + Tempo) | Stripe and Tempo | Machine-to-machine payments: agents and services paying each other programmatically | Stablecoin + fiat; Stripe PaymentIntents and Shared Payment Tokens; settles on Tempo | Announced Mar 18, 2026; open |
Read the table down the “layer it solves” column and the overlap mostly disappears. AP2 sits at authorization. ACP sits at checkout. x402 and MPP sit at the rail, which is the one place two of these genuinely compete.
They Stack, Not Compete
The most useful mental model is a stack, not a bracket. A single agent purchase can touch more than one of these at once. Picture a shopping assistant buying a product for a user:
- AP2 captures the signed mandate that the user authorized this cart at this price. That is the authorization layer.
- ACP runs the checkout handshake with the merchant and turns the cart into an order. That is the commerce layer.
- x402 or MPP moves the actual money, whether that is a stablecoin micropayment to an API or a card charge through Stripe. That is the rail.
x402 being an explicit extension of AP2 is the clearest signal here: the people building these expect them to compose. The honest competition is narrower than the headlines suggest. It is mostly x402 against MPP at the rail layer, and even there the split is stablecoin-native versus Stripe-native rather than a winner-take-all fight.
Which to Use When
Match the protocol to the job in front of you. This is the table to keep.
| If you are… | Reach for | Why |
|---|---|---|
| You are adding consumer shopping to an assistant | ACP | It standardizes the cart-to-order handshake with merchants and settles on cards through Stripe, so a user can buy without leaving the chat. |
| You need proof a user authorized a specific purchase | AP2 | Its signed Intent, Cart, and Payment Mandates build a verifiable chain from user consent to the charge, and that chain works across any rail. |
| You are monetizing an API or service for other agents | x402 or MPP | Both revive HTTP 402 for pay-per-call access. Pick x402 for a stablecoin-native rail; pick MPP if you want Stripe tooling and fiat alongside stablecoins. |
| Your agents pay other services in a loop (microtransactions, recurring) | MPP | It is built for programmatic machine-to-machine spend, with PaymentIntents and settlement on Tempo, Stripe and Paradigm's stablecoin chain. |
| You want one authorization model and the freedom to swap rails later | AP2, plus x402 for crypto | AP2 stays payment-agnostic, so you keep the mandate layer and slot in whichever rail fits the moment. |
Once you have picked a rail, the next problem is control: spend limits, allowlists, and an audit trail so an agent cannot drain an account. That is its own design exercise, and we walk through it in how to give your AI coding agent a budget.
Open Questions
Two things are genuinely unresolved, and it is worth being upfront about them.
Fragmentation. Four protocols is already a lot to track, and there are more entrants circling the same space, including efforts like the Universal Commerce Protocol. Some of this will consolidate, some will settle into the layered stack above, and some will quietly disappear. As of 2026 it is too early to call which standards win, so betting your whole architecture on one is risky. The payment-agnostic posture of AP2 is partly a hedge against exactly this.
Liability. When an agent buys the wrong thing, who pays? AP2's signed mandates give you a non-repudiable record of what the user authorized, which makes a dispute easier to reason about. But the legal allocation of blame across the user, the merchant, the platform, and the model provider is still being worked out in practice rather than written into any spec. If money moves, that gap is yours to manage. We dig into the controls and the managed options in the trust layer for agent payments.
FAQ
Is AP2 a competitor to ACP?
Not really. AP2 is an authorization layer that proves a user approved an agent's purchase, and it stays payment-agnostic. ACP standardizes the checkout flow between an agent and a merchant and settles through Stripe. You can run an ACP checkout inside an AP2 authorization, so they tend to layer rather than fight.
What is the difference between x402 and MPP?
Both revive the HTTP 402 status code so a service can charge per request. x402 is Coinbase's stablecoin rail for machine micropayments, and it also ships as AP2's crypto extension. MPP is Stripe and Tempo's broader machine-to-machine payment protocol: it supports stablecoin and fiat, uses Stripe PaymentIntents and Shared Payment Tokens, and settles on the Tempo chain. As of 2026, think of x402 as crypto-first and MPP as Stripe-native with crypto support.
Which protocol should I use to monetize an API for AI agents?
x402 or MPP. Both let a service return a 402 and accept payment over HTTP without a human signing in. Choose x402 if your customers and treasury are already stablecoin-native, or MPP if you want Stripe's billing, fiat settlement, and tooling around the payment.
Did ACP go away when Instant Checkout was wound down?
The two are not the same thing. Press reports say OpenAI wound down the standalone ChatGPT Instant Checkout feature in March 2026. The Agentic Commerce Protocol is the open spec underneath it, co-authored with Stripe, and a protocol can outlive any one product built on it. Treat the feature's status as reported and the spec as a separate question.
Do I need crypto to use any of these?
It depends on the protocol. AP2 is payment-agnostic and works with cards, stablecoins, or bank transfers. ACP runs on cards and fiat through Stripe. x402 is stablecoin-native. MPP supports both stablecoin and fiat. So you can build agent payments with no crypto at all, or lean into stablecoins if that suits your use case.
Who is liable if an agent buys the wrong thing?
This is still unsettled, and it is the part the protocols help with but do not finish. AP2's signed mandates create a non-repudiable record of what the user authorized, which makes disputes easier to reason about. But the legal question of who eats the cost of a bad agent purchase — the user, the merchant, the platform, or the model provider — is being worked out in practice rather than written into a spec.