The Agentic Commerce Protocol Stack, Explained
ACP, UCP, MCP, AP2, A2A, x402, MPP — the agentic commerce protocols are layers, not rivals. Here is the job each does, and how one purchase uses several.
If you have read about agentic commerce for more than ten minutes, you have met the alphabet soup: ACP, UCP, MCP, AP2, A2A, x402, MPP. They all sound alike. It is easy to think they are seven rivals fighting for the same crown.
They are not. And once you see why, the whole thing gets simple.
The trick is this: these are layers, not competitors. Each one does a different job in a single purchase. Think of ordering food — one app finds the restaurant, another takes the order, a third handles the payment. Nobody asks "which one wins?" They work together. The protocol stack is the same.
Let me walk the layers from the top.
Layer 1: Discovery — how the agent finds things
Before an agent can buy, it has to find the store and understand its tools.
- MCP (Model Context Protocol). From Anthropic, released in late 2024 and now governed by the Linux Foundation. It lets an agent discover and call a system's tools in a standard way. It is the "how do I even talk to this store?" layer. By the time it moved to the Linux Foundation in December 2025 it already had more than 10,000 public servers.
- A2A (Agent-to-Agent). Introduced by Google in 2025, now also a Linux Foundation project. It is for agents talking to other agents — useful when one agent hands a task to another.
Keep it clear: this layer is about finding and talking, not paying.
Layer 2: Checkout — how the agent and store agree on a purchase
Now the agent wants to actually buy. This is where the two big names live.
- ACP (Agentic Commerce Protocol). Co-developed by OpenAI and Stripe, released 29 September 2025. It began as the standard behind ChatGPT's checkout. It defines how an agent and a merchant agree on a cart and complete an order.
- UCP (Universal Commerce Protocol). From Google and Shopify, detailed in January 2026. It is broader — it tries to cover the whole journey, from discovery to post-purchase, and it is decentralised and free.
These two are the closest thing to real rivals in the stack. But even here, the smart move for a merchant is usually to support both. (I wrote more on that trade-off in the examples and landscape posts.)
Layer 3: Authorization — how we prove a human said yes
This is the hard, serious layer. Before money moves, the system must prove the purchase was actually allowed.
- AP2 (Agent Payments Protocol). Started by Google, donated to the FIDO Alliance in April 2026. It uses "mandates" — signed proofs that a human approved an action, within limits. More than 60 organisations backed it at launch.
- Card-network identity. Alongside AP2 sit the networks' own schemes, such as Visa's Trusted Agent Protocol and Mastercard's agent programs, which check who the agent is before a card is used.
If you only remember one thing about this layer: it answers "who said yes, and who is this agent?" That is the question the whole industry is still working hardest on.
Layer 4: Settlement — how the money actually moves
Finally, the money. For normal card payments, this runs over the usual card rails. But for machine-native payments, two protocols stand out.
- x402. From Coinbase, launched May 2025. It revives the old HTTP 402 code for pay-per-request payments, usually in stablecoins. Open and neutral, now under a Linux Foundation foundation.
- MPP (Machine Payments Protocol). Co-authored by Stripe and Tempo, launched 18 March 2026. Session-based, aimed at business use, and it handles both stablecoins and normal card/fiat payments out of the box.
This layer answers the plain question: "how does the cash get from A to B?"
The whole stack, in one table
| Layer | Job | Protocols | Main backers |
|---|---|---|---|
| Discovery | Find and talk to the store | MCP, A2A | Anthropic, Google |
| Checkout | Agree on the purchase | ACP, UCP | OpenAI + Stripe, Google + Shopify |
| Authorization | Prove it was allowed | AP2, network identity | Google → FIDO, Visa, Mastercard |
| Settlement | Move the money | x402, MPP, card rails | Coinbase, Stripe + Tempo |
How one purchase uses the whole stack
Here is the payoff. A single agent purchase might go like this:
- The agent uses MCP to find the store's tools.
- It uses ACP or UCP to build the cart and start checkout.
- It uses AP2 (or a network scheme) to prove you approved it.
- It settles over a card rail, or over x402 / MPP for a machine payment.
Four layers, one purchase. Not a fight — a relay race.
So who is "winning"?
The honest answer: wrong question. The layers will likely settle on one or two winners each, and most of them are moving to neutral standards bodies (MCP and AP2 both did). The companies doing best are the ones sitting across several layers at once — but that is a story for another post.
If you want the people and companies behind each name, see the agentic commerce landscape. For how these pieces show up in real purchases, see agentic commerce examples. And for the order it all arrived in, see the timeline.
Key takeaway
There is no single agentic commerce protocol, and there does not need to be. There is a stack: discovery (MCP, A2A), checkout (ACP, UCP), authorization (AP2, network identity), and settlement (x402, MPP, cards). Learn the four layers, and every new three-letter name will slot straight into place.
Sources and further reading
- Model Context Protocol (MCP), Anthropic: https://modelcontextprotocol.io
- Agentic Commerce Protocol (ACP), OpenAI + Stripe: https://www.agenticcommerce.dev
- Google Developers Blog, "Under the Hood: UCP" (2026-01-11): https://developers.googleblog.com
- Google Cloud, "Announcing Agent Payments Protocol (AP2)" (2025-09-16): https://cloud.google.com/blog
- FIDO Alliance, AP2 and trusted agent work (2026-04-28): https://fidoalliance.org
- Coinbase x402 and the x402 Foundation: https://www.x402.org
- Stripe and Tempo, Machine Payments Protocol (2026-03-18): https://stripe.com/blog
Note: this stack is young and the pieces move monthly. Please check the primary sources above before relying on a version number or status.