UCP, ACP, AP2 and MCP: which one does your store actually need?
Four acronyms, four different heights in the same stack. Adopting one does not give you the others, and the one your platform handed you for free is table stakes, not an advantage.
Every vendor deck on agentic commerce presents these four acronyms as competitors, usually with the vendor's preferred one winning. They are not competitors. They sit at four different heights in one stack, and a store that has adopted one has not adopted the others. Knowing which height you are missing is most of the work.
The stack, from the bottom up
MCP: how an agent calls anything
The Model Context Protocol is the transport. It describes how a model discovers a tool, reads its schema and calls it. It is domain agnostic, which is exactly why it is not a commerce protocol. MCP tells an agent that a search_products function exists and what arguments it takes. It says nothing about what a cart is, how tax is calculated or what constitutes a valid order.
If you already run an MCP server, you have a callable surface. You do not yet have a commerce surface, and an agent arriving from a shopping context has no standard way to discover you.
UCP and ACP: what the commerce operations are
These two describe the operations themselves. Search a catalogue, build a cart, get real tax and shipping for an address, place an order, check status. They are the layer that turns your store from a website into something transactable.
ACP, the Agentic Commerce Protocol, is maintained by OpenAI and Stripe and has been live in ChatGPT since September 2025. Its distribution advantage is that it was built into Stripe's checkout infrastructure, so a very large number of merchants became reachable through a configuration change rather than an engineering project. The specification is still in beta.
UCP, the Universal Commerce Protocol, was announced by Google in January 2026 with Shopify, Target, Etsy, Walmart and Wayfair. It is discovered through a manifest at
/.well-known/ucp. Google added Merchant Center onboarding in March 2026, along with cart support and catalogue access, and checkout is currently available to eligible US merchants with wider rollout through the year.
Adopting one does not give you the other. They declare different manifests, expose different endpoints and are discovered by different agents. A store live on ACP through Stripe is invisible to an agent that only speaks UCP, and the reverse.
AP2: proving a human authorised the purchase
The Agent Payments Protocol covers the mandate. It uses W3C verifiable credentials to carry a signed statement that a specific person approved a specific purchase within stated limits, so a merchant can verify authorisation rather than trust that the agent on the other end is acting honestly.
This is the layer that decides whether agentic commerce is safe enough to scale. It is also the layer almost nobody has implemented, which is tolerable at current volumes and will not be for long.
x402 and payment rails: moving the money
Settlement sits below all of it. This is the least interesting layer for most merchants, because your existing processor is going to handle it and the protocols are being designed to sit on top of what you already have.
MCP is how an agent calls. UCP and ACP are what it calls. AP2 is proof that a human said yes. The rails move the money. Four layers, four separate decisions, and no vendor sells you all four.
The trap: a manifest you did not write
If you are on Shopify, you very likely already have a commerce manifest, provisioned by the platform. It is easy to read that as being ahead. It is the opposite. A platform default is byte identical across every merchant on that platform, which means it is table stakes and cannot differentiate you from any competitor sharing your stack.
We have also found that the minority of manifests written by hand frequently get a required field wrong, most commonly by publishing signing keys somewhere other than the canonical location the specification names. The file exists, it looks correct to a human reading it, and a compliant verifier cannot use it. Nothing warns you, because there is no error path for a manifest that parses but does not conform.
What to actually do, by situation
Platform store with default settings. Your work is not at the protocol layer. It is at the readable layer: server rendered price and stock, complete Product structured data, returns and shipping published as data. The manifest you already have is worth nothing if the agent cannot read your catalogue.
Custom stack with real engineering capacity. Expose search, product lookup and cart as a callable endpoint, then declare it in whichever manifest matches where your buyers actually are. Verify the manifest with an independent parser rather than trusting that it looks right.
High value or regulated categories. AP2 matters to you sooner than to anyone else, because the first serious dispute over an agent placed order will be about authorisation, not about the cart.
Everyone. Monitor all of it. Every layer in this stack fails silently. A manifest that stops resolving, a bot rule that starts challenging, a price that moves back behind JavaScript in a theme update. None of these produce an alert unless you build one.
The honest summary is that the protocol layer is where the attention is and the readable layer is where the money is. Most stores asking which protocol to adopt would get more return in the next two quarters from making their product pages legible to a plain HTTP request.
Sources
AISmith Team
Author