UCP vs ACP vs AP2: the agentic commerce standards compared

Three standards are routinely described as competitors in agentic commerce. Mostly they are not. They solve different problems, and the confusion comes from summarising all three as "a standard for AI shopping" when they operate at different layers.

Here is what each one actually does.

Accurate as of July 2026. This area is moving quickly and several widely repeated descriptions are out of date.

The one paragraph version

UCP is discovery and description: how an agent finds out what your business sells and how to transact with it. ACP is the transaction itself: how an agent and a merchant exchange a checkout. AP2 is authorisation: how you prove the human actually agreed to this purchase.

You can use more than one. They are not mutually exclusive, and the question "which should I pick" is often the wrong question.

Side by side

| | UCP | ACP | AP2 | |---|---|---|---| | Full name | Universal Commerce Protocol | Agentic Commerce Protocol | Agent Payments Protocol | | Behind it | Google, Shopify, Amazon, Microsoft, Meta, Salesforce, Stripe, Walmart, Target and others | OpenAI and Stripe | Google, donated to the FIDO Alliance in April 2026 | | Answers | What do you sell and how do I buy? | How do I run this checkout? | Did the human authorise this? | | Discovery | /.well-known/ucp on your domain | None; you integrate directly | Not applicable | | Agent identity | Request signing added April 2026 | None: a bearer API key | Not its job | | Version | 2026-04-08 | 2026-04-17 | v0.2 | | Governance | Multi-vendor | OpenAI and Stripe controlled | FIDO Alliance |

UCP: the discovery layer

UCP is the only one of the three with genuine public discovery. You publish a JSON profile at a fixed well-known path on your own domain, and any agent can read it without asking anyone's permission. There is no registry and no approval step; the specification explicitly rejects a central registry.

That design choice has a side effect worth appreciating: because the profile is public and unauthenticated, third parties can inspect it. That is what makes an external conformance checker possible at all. Neither of the other two standards has an equivalent public surface.

Its scope is description and capability negotiation rather than the mechanics of moving money.

ACP: the transaction layer

The Agentic Commerce Protocol comes from OpenAI and Stripe and is published under Apache 2.0. Its current spec is dated 2026-04-17. It defines how an agent and a merchant conduct a checkout: the request shapes, the headers, the idempotency behaviour.

Two things are commonly got wrong about it.

It has no cryptographic agent identity. Authentication is a bearer API key. There is a Signature header in the specification, but it is an HMAC for verifying webhooks, not for attesting which agent is calling. Blog posts describing ACP as providing OAuth-based delegated agent authentication are not supported by the published OpenAPI files. If you integrate ACP, you know which API key was used, which is a different assurance from knowing which agent is on the other end.

Its version header is API-Version. A small detail, but one that trips up implementations copying from secondary sources.

The relationship with UCP is not really head to head. ACP assumes you already have a commercial relationship and an API key; UCP is about being discoverable in the first place. A merchant could reasonably do both.

AP2: the authorisation layer

AP2 is the one most often mischaracterised, largely because it changed substantially between versions and the old description is still everywhere.

It answers a question the other two do not touch: when an agent buys something, how does everyone downstream prove the human actually authorised this purchase, at this price, from this merchant? That matters for disputes, chargebacks and fraud, and it is a genuinely hard problem once a machine is doing the clicking.

Google announced AP2 in September 2025 and donated it to the FIDO Alliance in April 2026, which moves it from a single vendor's project toward a standards body with a track record in authentication.

Two corrections worth making, because the outdated version is repeated constantly:

• The mandate objects are Checkout Mandate and Payment Mandate. "Intent Mandate" and "Cart Mandate" were the v0.1 names and are obsolete.
• They are bound using SD-JWT, not JSON-LD W3C Verifiable Credentials, despite many write-ups saying otherwise.

If you are reading a guide that still says Intent and Cart Mandates as JSON-LD VCs, it predates v0.2.

Where agent identity actually lives

Since "which one identifies the agent" is the question that causes the most confusion, it is worth separating cleanly:

| Layer | Mechanism | Identifies the agent? | Proves user authorised? | |---|---|---|---| | Transport | Web Bot Auth (RFC 9421) | Yes | No | | Commerce identity | Visa Trusted Agent Protocol | Yes | Partly | | Authorisation | AP2 mandates | No | Yes | | Transaction | ACP | No | No |

The thing that tells your origin which agent is knocking is not any of the three commerce standards. It is Web Bot Auth, a transport-layer profile of RFC 9421 HTTP Message Signatures, which is being standardised in an IETF working group and is what Cloudflare validates. Visa's Trusted Agent Protocol is built directly on it, using the tag field to distinguish browsing from paying.

This is why our agents directory tracks signing directories rather than commerce protocol support. Identity and commerce are separate concerns, and conflating them is how people end up believing an API key tells them who they are talking to.

Which should you care about?

If you sell online: UCP first. It is live, you may already have a profile through your platform, and it is the only one with public discovery you can verify from the outside today. Check what yours says.

If you are integrating with OpenAI's commerce surfaces: ACP, because that is the contract those surfaces use. Do not expect it to tell you which agent is calling.

If you are a payments provider, issuer or acquirer: AP2 is the one to watch, and its move to FIDO makes it likelier to matter. For most merchants it will arrive through your payment provider rather than as something you implement.

If you are trying to tell real agent traffic from anything else: none of the above. That is Web Bot Auth, and it is largely handled for you if you sit behind a CDN that validates signatures.

Will these converge?

Some consolidation looks likely, and there is already evidence of it. UCP added request and response signing in its April 2026 release, which is the same verify-rather-than-trust idea appearing at the transport layer. AP2 moving to FIDO points the same way.

But the layers themselves are unlikely to merge, because they genuinely are different problems. Describing your catalogue, running a checkout, and proving consent are three jobs, and a single standard doing all three would be worse at each.

For now, the practical answer is unglamorous: understand which layer a given standard occupies before deciding whether it is your problem, and be careful with summaries written more than a couple of months ago.

Read next

• What is UCP? — the one most merchants should look at first
• AI crawlers vs AI agents — where agent identity actually gets established
• The UCP changelog — what each release changed, in plain English