Agentic Commerce Protocol and UCP are not the same job

Two standards now want your catalogue and your checkout. OpenAI's Agentic Commerce Protocol and Google's Universal Commerce Protocol are usually described as rivals doing the same thing, and they are not. They ask for different artefacts, they put the integration in different places, and a team that scopes one by reading about the other will be wrong about the effort in both directions.

Both are worth understanding now, because the expensive part of either is the part you should be fixing anyway.

What the Agentic Commerce Protocol asks you to build

ACP is prescriptive. You publish a product feed and you implement a checkout API to OpenAI's shape.

The feed specification names nine required fields per item: a stable item_id unique per item or variant, title, description, url pointing at the product page with the variant selected where possible, brand, seller_name, image_url showing that variant, price in major currency units, and availability restricted to in_stock, out_of_stock, pre_order, backorder or unknown. Feeds go in OpenAI's JSONL format or a Google-compatible tab or comma delimited file. Product and image URLs must be publicly accessible, and stock status is submitted with each row.

The checkout specification is a five-endpoint REST contract: create a session, update it for address, shipping or item changes, complete it, cancel it, and read it back. Every response carries the full cart state — items, pricing, taxes and fees, shipping, discounts, totals, status. Every endpoint receives an Idempotency-Key header you must honour and echo. You emit order_created and order_updated events to OpenAI's webhook, signed with HMAC using merchant-specific keys.

Payments are the part teams worry about and the part that is least disruptive. The specification's own instruction is to keep payments where they are: use your current provider and settlement processes, and integrate Delegated Payments only if applicable. Under delegated payments you receive an encrypted token naming a provider — Stripe, Adyen or Braintree — and apply your normal authorisation and capture flow. Nothing about your ledger changes.

What UCP asks for instead

UCP, announced at NRF in January 2026 and co-developed with Shopify, Etsy, Wayfair, Target and Walmart, is a negotiation framework rather than a fixed API.

The centre of it is a discovery document. You publish a profile at /.well-known/ucp declaring your protocol version, services, capabilities, payment handlers and signing keys in JWK format. The specification requires that profiles be served over HTTPS and that responses include a Cache-Control header with public and a max-age of at least sixty seconds.

From there it diverges sharply from ACP. Services are transports, and four are defined: REST, MCP, agent-to-agent, and an embedded protocol. Capabilities are feature modules that can extend other capabilities. Businesses must compute the intersection of platform and business capabilities, and must include a ucp field in every response naming the version used and the active capabilities. Webhooks are signed per RFC 9421 rather than with a bearer HMAC. Payments route through AP2, a separate protocol in which an agent presents a cryptographically signed mandate — non-repudiable evidence that a specific user authorised a specific transaction — rather than a session token.

The comparison that actually matters

Read side by side, the two are answering different questions. ACP asks how a shopping conversation completes a purchase, and hands you the sequence. UCP asks how an arbitrary agent discovers what a business can do and then negotiates a transport, with payment authorisation delegated to a protocol designed for machine consent.

That difference has consequences for how you plan. An ACP integration is a bounded, testable piece of work: five endpoints, a feed, a webhook, conformance checks on schema, error codes, rate limits and webhook delivery. A UCP integration is smaller at the edges and larger in the middle, because capability negotiation means your responses have to describe themselves, and because signing keys and mandate verification pull in cryptographic handling most storefronts do not have today.

Neither specification, incidentally, states a response-time requirement. Secondary coverage repeats a figure that agent-facing endpoints must answer within 200 milliseconds; it does not appear in either specification we read, and we have cut it rather than pass it on. Be fast anyway — an agent comparing three merchants will not wait — but do not size an engineering programme around a number nobody can source.

There is also a governance difference worth raising before anyone signs anything. Under ACP the relationship is bilateral: OpenAI holds your feed, calls your endpoints, and signs its webhooks with keys it issued you. Under UCP the merchant publishes signing keys and any conforming agent can discover and transact, which is more open and correspondingly harder to reason about. Deciding who may transact with you, and on what evidence, is a policy question your finance and legal people will want answered, and it is easier to answer before the integration than after it.

This is a product data problem wearing an AI costume

Here is the part that decides whether either integration succeeds, and it has nothing to do with agents.

Both protocols expose your catalogue to a consumer that cannot be charmed. A human shopper forgives a stale availability flag, a missing brand, a photograph of the wrong colourway — they look at the page and work it out. An agent takes the field at face value, recommends the item, and puts the customer into a checkout for something you cannot ship. That failure is not attributed to your data. It is attributed to you.

So the honest first question is not which protocol to adopt. It is whether your availability field is true right now, on every variant, at the moment it is read. Most mid-market catalogues we review fail that test somewhere: stock synced on a nightly job, variants inheriting the parent's status, discontinued lines still marked in stock because nobody owns the retirement process. Every one of those is a returned order and a refund today and an agent-driven incident tomorrow.

Pricing has the same property. ACP wants the price in major currency units, which sounds trivial until a promotion engine that computes discounts at render time meets a feed generated from the base table. The agent quotes one number and the basket shows another, and the shopper abandons at the only moment that counts.

The related failure is identity. ACP wants a stable item_id unique per variant. If your product IDs are regenerated by an export, or if the same SKU appears twice under different identifiers, agent-side deduplication will make choices on your behalf that you will not enjoy.

None of this is exotic to fix. It is a synchronisation job and an ownership question — who is accountable for a product record being true — and both are cheaper now than they will be once an agent is quoting your catalogue to a customer in a conversation you never see.

What we would do this quarter

For most mid-market merchants, the sequence is the same regardless of which protocol wins.

1. Audit the feed you already have. You almost certainly publish one for Google Shopping. Score it against the nine ACP-required fields and check how quickly availability reflects reality. This is the work that carries into either protocol and improves paid performance in the meantime.
2. Fix stock truth before anything else. If availability is a nightly export, that is the project. Nothing downstream is better than this number.
3. Make product identifiers stable and unique per variant. Then never regenerate them.
4. Implement ACP first if you are going to pick one. It is the more bounded contract, the endpoints are conventional REST, and idempotency and order webhooks are patterns your team already knows from payments work — the same discipline as any webhook integration where retries and ordering matter.
5. Treat UCP as a platform decision. If you are on Shopify, much of the profile and negotiation is likely to arrive through the platform rather than your codebase, which changes the build-versus-wait calculation entirely.
6. Check you are readable at all. A storefront that paints its copy after JavaScript runs may be invisible to the fetchers behind these agents, which is the same trap we described for AI crawlers and robots.txt.

The strategic read is that agentic commerce is doing to product data what mobile did to page weight: taking something teams had tolerated as imperfect and making it load-bearing. The merchants who benefit will not be the ones who integrated first. They will be the ones whose catalogue was already true. If you want a view on where yours stands, that assessment is part of how we approach e-commerce builds, and the integration work afterwards is the easy half.