UCP, ACP and AP2: Which One to Build For

A store owner told to “support the agentic commerce standard” is being told something incoherent, because there are four specifications in play and they are not alternatives to one another. Two are commerce protocols, one is a payments protocol, and one is the transport layer they sit on. Getting the division of labour right before writing code is the difference between one integration and three.

Four specifications, doing three different jobs

The layering is clearer than the naming suggests:

• UCP, the Universal Commerce Protocol, defines commerce capabilities directly: catalog, cart, checkout and order under a dev.ucp.shopping namespace, plus location and identity linking under dev.ucp.common.
• ACP, the Agentic Commerce Protocol, covers the same ground from a different starting point, with cart, feed, orders and authentication in its current release.
• AP2, the Agent Payments Protocol, is not a commerce protocol at all. It concerns proving who authorised a payment, which is a separate problem from deciding what is in the basket.
• MCP, the Model Context Protocol, is the substrate. It is how an agent talks to a tool server at all, and both commerce protocols can ride on it.

Implementing both UCP and ACP is duplicated work. Implementing a commerce protocol and ignoring the payments question is not, because they answer different things.

Where each one sits right now

UCP’s specification version is 2026-08-25, visible in the "version" field of the profile examples throughout the UCP specification overview. It is published under the Apache License 2.0 and describes itself as an open standard, open and extensible by design.

ACP’s latest stable snapshot is dated 2026-04-17. Its repository states the specification “is currently maintained by OpenAI and Stripe and is currently in beta“, with the two named as founding maintainers, also under Apache 2.0. The repository’s roadmap language points to “neutral foundation stewardship as ecosystem matures” — a future intention rather than a completed governance move.

AP2 was donated by Google to the FIDO Alliance and sits at version 0.2, which added support for transactions where the human is not present at the moment of purchase. That donation is the most concrete governance event of the three, because it moved a specification out of a single vendor’s control rather than announcing that it might one day.

MCP’s current specification version is 2026-07-28. Alongside the base protocol it now carries optional extensions, and the specification lists Tasks, Skills over MCP and MCP Apps as the notable ones. Tasks matters most for commerce: it covers “asynchronous execution of long-running operations, with polling, mid-flight input, and durable handles”, which is what a checkout that waits on a payment processor actually looks like.

Why the backer list is the strongest signal available

None of these has a track record long enough to judge on outcomes, so the honest tiebreaker is who has committed. UCP’s own site names its co-developers across shopping, lodging and food: Amazon, Booking.com, DoorDash, Etsy, Expedia Group, Google, Hilton, Marriott, Meta, Microsoft, Salesforce, Shopify, Square, Stripe, Target, Toast, Trip.com, Uber Eats, Walmart and Wayfair, with a longer list of endorsed partners including Mastercard, PayPal, Visa, Klarna and Adyen. ACP has two founding maintainers, one of which — Stripe — also appears on UCP’s co-developer list.

That is a count of logos, not of shipped integrations, and should be read as exactly that. But when two specifications overlap and neither has proved itself in production, the one whose backers include the platforms your store already runs on is the cheaper bet. The same reasoning applies to the new product-feed SEO, where the feed you already maintain does most of the work regardless of which protocol wins.

What a merchant actually has to implement

Less than the protocol documents suggest. Google’s merchant UCP documentation describes a native integration as the default path and makes two commitments plainly: “You remain the Merchant of Record” and “Keep all of your customer data and relationships.” On the input side, Google’s merchant UCP guidance says to “use your existing Merchant Center account shopping feeds to capture high-intent customers during discovery” — the feed you already submit, not a new one.

So for most stores on a mainstream platform, the work is not implementing a protocol. It is making sure the feed is accurate, the availability and price fields are current, and the platform’s own agentic settings have been looked at deliberately rather than left at whatever the vendor defaulted them to. The technical surface — catalog, cart, checkout, order — belongs to the platform, and only a merchant running a bespoke storefront inherits it directly.

The assessment that would change this is a demonstrated volume of completed agentic transactions through one protocol and not the other. That number does not exist publicly yet from any of the four, which is worth saying out loud before anyone commits a quarter of engineering time. The practical behaviour of these agents, as opposed to their specifications, is covered in agentic browsers and shopping agents, and the feed quality question in Merchant Center requirements.