# AI agent payment protocols compared: x402, MPP, ACP, AP2, UCP (2026)

_By Nakul Kelkar, July 30, 2026_

There are five protocols with a serious claim to the phrase "agent payments", and the single most useful thing to know about them is that they belong to two families that are solving different problems. x402 and the Machine Payments Protocol let a piece of software pay a service for a single request, in amounts starting at a cent, with no account and no checkout. ACP, AP2, and UCP let a piece of software buy from a merchant on a person's behalf, with the consent, dispute, and card economics that a merchant purchase carries. The first family is about metering. The second is about delegation. Almost nothing built for one is useful for the other, and most confusion about which protocol "wins" comes from comparing across the line.

## The table

| | x402 | MPP | ACP | AP2 | UCP |
| --- | --- | --- | --- | --- | --- |
| Full name | x402 | Machine Payments Protocol | Agentic Commerce Protocol | Agent Payments Protocol | Universal Commerce Protocol |
| Who runs it | x402 Foundation, Apache-2.0; Coinbase is the largest facilitator | Stripe and Tempo, open protocol | OpenAI and Stripe, Apache-2.0 | Google, donated to the FIDO Alliance; v0.2 | Google, for Google surfaces |
| Family | Pay per request | Pay per request | Merchant checkout | Merchant checkout | Merchant checkout |
| The exchange | Request, 402 with requirements, signed retry, facilitator verifies and settles | Request, 402 challenge, retry with payment credential, receipt | Checkout session create, update, complete, with a delegated payment token | Checkout mandate and payment mandate as verifiable credentials | Session create, update, complete; Google Pay; order status sync |
| What settles | USDC or any ERC-20 or SPL token, on Base or Solana, in about a second | A stablecoin on Tempo, or a card through a shared payment token, into a Stripe balance | The merchant's own processor: Stripe, Adyen, Braintree | Cards today; wallets, bank transfers, and digital currencies on the roadmap | Google Pay |
| Buyer needs | A programmatic wallet with the asset and gas | A card credential via Link, or a stablecoin wallet on Tempo | To be ChatGPT, for now | An agent that can present signed mandates | To be Google Search or Gemini |
| Seller needs | An endpoint that returns 402 and calls a facilitator | A Stripe profile and the mppx library | Three REST endpoints and a processor | Merchant support for mandate verification | Waitlist approval from Google |
| Human in the loop | No | No | Yes, the buyer authorizes in ChatGPT | Yes, mandates encode the person's authorization | Yes |
| Smallest sensible payment | About a cent | About a cent with stablecoins; 50 cents with cards | Card minimums | Card minimums | Card minimums |
| Status | In production; used by APIs and agents | In production with Stripe; stablecoin on Tempo and cards via SPT | Live in ChatGPT; discovery still being built | v0.2; standardization at FIDO | Evolving; waitlisted |

## The pay-per-request family

**x402** revives the HTTP status code reserved in 1997 for exactly this. A client asks for a resource, the server answers `402 Payment Required` with a `PAYMENT-REQUIRED` header naming the amount, the asset, the network, and the address, the client signs an authorization with a wallet it controls and retries with a `PAYMENT-SIGNATURE` header, and a facilitator, Coinbase runs one and anyone may, verifies and settles it on-chain. USDC on Base is the common case, Solana is supported, and settlement takes about a second. The buyer pays gas, which is a fraction of a cent on Base, and most facilitators charge nothing on top. It is chain-native: there is no processor, no account, and no card anywhere in the flow. The standard is Apache-2.0 under the x402 Foundation.

**MPP** is the same shape from the processor's side. Stripe and Tempo co-authored it; a seller integrates with the `mppx` library and a Stripe profile, returns a 402 challenge, verifies the retry, and records the payment as a Stripe payment intent. What is different is what settles. An agent can pay with a stablecoin sent to a deposit address on Tempo, the chain Stripe launched this year, and Stripe off-ramps it into the seller's balance; or an agent can pay with a card through a shared payment token provisioned via Link, in which case the fifty-cent card minimum applies. MPP is what an API that already runs on Stripe adopts, and the card option is what makes it reach agents that have a person's card credential rather than a wallet.

The two are not rivals so much as the same idea landing in two ecosystems. An agent that pays over one can, with a different signer, pay over the other. A gateway that sits in front of many providers ends up speaking both, because providers choose based on where their money already lives.

## The merchant checkout family

**ACP** is how an agent inside ChatGPT buys from a merchant. OpenAI and Stripe published it under Apache-2.0. The merchant implements a checkout session with create, update, and complete endpoints, keeps its existing processor, and optionally accepts a delegated payment token so the buyer's card credential is never exposed to the agent. It supports physical goods, digital products, and subscriptions. It is the protocol behind Instant Checkout in ChatGPT, and today ChatGPT is the buyer.

**AP2** is Google's answer to a harder question: how does anyone prove, after the fact, that a person authorized an agent to make a specific purchase. Its mechanism is mandates, verifiable digital credentials that are cryptographically signed and tamper-evident. A checkout mandate captures what is being bought and the person's authorization; a payment mandate authorizes a specific amount to the credential provider and processor. It is an extension of the Agent2Agent protocol and interoperates with UCP. Cards are supported today, with wallets, bank transfers such as UPI and PIX, and digital currencies on the roadmap. Google donated it to the FIDO Alliance, where standardization is underway in a technical working group; the current release is v0.2.

**UCP** is narrower than its name. It is the protocol merchants implement to transact inside Google's own surfaces, Search in AI Mode and Gemini, covering product discovery, a three-endpoint native checkout, payment through Google Pay, and order status. It is under development, not every feature in the spec is live, and merchants need waitlist approval. It matters if you sell things and want Google's agents to sell them; it does not matter to an agent paying for an API.

## Choosing

For an agent that needs to pay a service per call, a search, a scrape, a minute of compute, a row of data, the answer is x402 or MPP, and which one is decided by the seller, not the buyer. Both are built for amounts from a cent up, both remove the account and the checkout, and neither involves a person. The checkout protocols would be the wrong tool even if they were available, because they carry card minimums and consent flows designed for a person buying shoes.

For an agent buying from a merchant on someone's behalf, the answer is whichever checkout protocol the surface the agent lives in supports: ACP in ChatGPT, UCP in Google, AP2 wherever mandates are honored. These exist because delegation to an agent needs a proof of consent that a card network can rely on, and that is a genuinely new requirement.

For a person or a team giving an agent spending power across many services, the practical answer is not a protocol but a policy in front of the protocols. The agent holds a key with categories, a monthly limit, and a maximum cost it must state on every call; something behind the key pays each provider on the rail that provider accepts. That is what Vaaya does. It settles on x402 in USDC on Base, on MPP, and on Tempo, and the agent never learns which, because it does not need to. **The rail is the seller's choice. The limit is the buyer's.** A protocol comparison tells you how money moves; it does not tell an agent how much it may spend, and the second question is the one that keeps people up at night.

The definitions behind x402 are in [what is x402](/blog/what-is-x402), and the mechanics of an agent paying over it, directly and through a gateway, are in [how x402 works for AI agents](/blog/how-x402-works-for-ai-agents). Official documentation: [x402](https://docs.x402.org/introduction), [MPP](https://docs.stripe.com/payments/machine/mpp), [ACP](https://www.agenticcommerce.dev/), [AP2](https://ap2-protocol.org/), [UCP](https://developers.google.com/merchant/ucp/guides/overview).

## Questions

**What payment protocols exist for AI agents?**

Two families. For machine-to-machine payments per request: x402, from the x402 Foundation with Coinbase, and MPP, the Machine Payments Protocol from Stripe and Tempo. For an agent buying from a merchant on a person's behalf: ACP from OpenAI and Stripe, AP2 from Google now at the FIDO Alliance, and UCP from Google for its own surfaces.

**What is the difference between x402 and MPP?**

Both use an HTTP 402 challenge and a signed retry. x402 settles in stablecoins on-chain, USDC on Base or Solana, through a facilitator. MPP settles through Stripe, accepting either a stablecoin on Tempo or a card via a shared payment token, and lands in the seller's Stripe balance. x402 is chain-native; MPP is processor-native with a chain option.

**Which protocol should an agent use to pay for an API?**

x402 or MPP, depending on what the API accepts. Both are built for per-request payments in amounts from a cent upward. Checkout protocols such as ACP, AP2, and UCP are for merchant purchases and carry card economics, which make small API calls uneconomic.