x402, MPP, AP2 and ACP: four agent payment protocols compared

Since 2025 four names come up whenever people talk about AI agents paying for things: x402, MPP, AP2 and ACP. They are often listed as if they competed. Mostly they don't. They sit at different points of a purchase, and one payment can involve two of them.

This is a plain comparison as of October 2026: what each protocol does, who is behind it, how the money moves, and what you end up with when your accountant asks for the paperwork.

The overview

x402: a price inside the HTTP response

x402 uses the status code 402 Payment Required. The server answers an unpaid request with a price in a PAYMENT-REQUIRED header. The client signs a payment authorization and repeats the request with a PAYMENT-SIGNATURE header. A facilitator verifies the signature and settles the transfer on chain, usually in USDC on Base. Our walkthrough shows a real exchange header by header.

Coinbase published x402 in May 2025. On April 2, 2026 the x402 Foundation launched under the Linux Foundation and Coinbase handed over the protocol. Forty organizations joined at launch, among them Amazon Web Services, American Express, Cloudflare, Google, Mastercard, Shopify, the Solana Foundation, Stripe and Visa.

Where you meet it: paid APIs and MCP tools that agents call directly. CoinGecko, Nansen, Glassnode and Messari sell data this way.

What it leaves you: a transfer on chain from your wallet to the seller's payTo address, with a transaction hash. No seller name and no invoice.

MPP: the same idea, as HTTP authentication

The Machine Payments Protocol was written by Tempo and Stripe and published in March 2026. It also uses HTTP 402, but treats payment as an HTTP authentication scheme called Payment, and it is proposed to the IETF as an Internet-Draft.

The exchange has three parts. The server sends a challenge in a WWW-Authenticate: Payment header, the client answers with a credential in Authorization: Payment, and the server confirms with a Payment-Receipt header. Besides single charges, MPP knows sessions, metered pay as you go usage that is paid off chain and settled on chain later, and subscriptions.

MPP is not tied to one network. Its documentation lists stablecoins on Tempo, cards and wallets through Stripe, Lightning and a number of other chains. Cloudflare describes MPP as backwards compatible with x402, and some servers offer both.

Where you meet it: the same places as x402, paid APIs and tools.

What it leaves you: that depends on the method. A stablecoin payment leaves a transfer on chain, just like x402. A card payment through Stripe leaves a line on your card statement and whatever receipt the seller's Stripe account sends.

AP2: proof of what the user allowed

The Agent Payments Protocol answers a different question. Not how money moves, but how a merchant, a bank or a card network can tell that an agent was allowed to make this purchase.

Google announced AP2 on September 16, 2025. Its core is the mandate, a signed digital credential. The current version has two kinds. A checkout mandate records the items and terms the agent agreed with the merchant. A payment mandate authorizes a payment with a specific instrument. Each comes in an open form, the user's limits such as a budget before anything is final, and a closed form, the approval of one finished checkout and one amount. The mandates are chained together, so the path from "buy me running shoes under 120 euros" to the actual charge can be audited later.

AP2 does not settle payments itself. It works with cards and with x402, and the project ships samples in which the payment step is an x402 transfer. Google has since handed the specification to the FIDO Alliance, where its technical working groups continue it.

Where you meet it: purchases an agent makes for a person, where the merchant or the bank needs to see consent.

What it leaves you: the mandates as evidence of authorization, plus whatever the payment rail produces.

ACP: a checkout for AI apps

The Agentic Commerce Protocol was developed by OpenAI and Stripe and released on September 29, 2025. It describes how an AI app and a merchant run a checkout together. The app collects what the buyer wants, the merchant confirms items, price and shipping, and the payment goes through the merchant's own payment provider.

The key piece is the Shared Payment Token. The app hands the merchant a token that only works for that merchant and that cart total, so the merchant can charge the buyer without ever seeing the card details. Merchants who do not use Stripe can implement the protocol with their own provider.

Where you meet it: consumer shopping inside AI apps. It is not meant for an agent that pays an API per call.

What it leaves you: a normal order with the merchant, and the merchant's usual receipt or invoice.

Which ones matter if your agents buy data and tools

If your agents call paid APIs, the protocols you will actually meet are x402 and, more and more, MPP. AP2 and ACP matter when an agent shops for a person.

That has a consequence for bookkeeping. With ACP and card payments, the paperwork looks like it always did: a merchant, a card statement, a receipt. With x402, and with stablecoin payments over MPP, you get something new: hundreds of small transfers to wallet addresses, without a seller name and without an invoice. That is fine for the protocol and a problem for your books.

We wrote about how to find out who is behind a wallet, how to book these payments and which VAT rules apply.

Sources

• x402 Foundation: Coinbase developer docs
• MPP: mpp.dev and Cloudflare's MPP page
• AP2: ap2-protocol.org
• ACP: Stripe's announcement