What is the Universal Commerce Protocol?

UCP is a protocol for agentic commerce covering five core capabilities: catalog search and lookup, cart building, identity linking over OAuth 2.0, checkout and order management. It runs over REST and JSON-RPC with AP2, A2A and MCP supported alongside, and it is explicit that the business remains the merchant of record with its own business logic and customer relationships. As of September 2026 retail is specified, lodging is in draft and food is announced.

What is the difference between UCP, ACP and AP2?

UCP is the commerce lifecycle, from product search to order management, and it keeps the merchant as merchant of record. AP2 is the payment layer: it proves that a human authorized a specific purchase, using mandates carried as signed verifiable credentials. ACP is the assistant-native path co-developed by Stripe and OpenAI, where orders flow from a chat assistant to the merchant's backend and payment happens through a token that never exposes card credentials.

What is a mandate in AP2?

A mandate is a cryptographically signed, tamper-evident credential recording either the user's constraints or their authorization. There are two: the checkout mandate, whose open stage captures the user's goals before a cart is final and whose closed stage authorizes a specific finalized checkout, and the payment mandate, whose open stage captures constraints such as budget and allowed instruments and whose closed stage authorizes one amount bound to that checkout. Chained together they give a non-repudiable audit trail.

Do I need to join one of these protocols to sell to AI agents?

Not yet, and the order of work matters more than the protocol. Make your catalog machine-readable first, with variants, SKUs, minor-unit prices, tax class, stock state and machine-readable return and shipping policies, because every protocol starts from the assumption that you can answer questions about a product. Then read the spec your largest platform partner actually asks for, and keep your own checkout, since all three designs keep the merchant of record.

Is a Shared Payment Token safe to accept from an agent?

A Shared Payment Token is scoped to a specific merchant and basket total, and it exists so an assistant can initiate a payment without ever handling the buyer's card credentials. The token arrives over the API and you process it through your payment provider, optionally using the issuer's risk signals for fraud scoring. What you are accepting is a scoped payment instruction with an audit trail, not a stored card.

Agentic commerce: UCP, ACP and AP2 compared

Agentic commerce is the attempt to let a language model buy things on a user's behalf, and it needs a machine interface for a purchase: a protocol, not a web page. Three of them matter as of September 2026. The Universal Commerce Protocol (UCP) covers the whole commerce lifecycle, the Agentic Commerce Protocol (ACP) covers orders and payment inside an assistant, and the Agent Payments Protocol (AP2) covers proving that a human actually authorized what the agent did.

This article compares them mechanism by mechanism, and ends with what a mid-size EU shop should actually build now. The short version: all three keep the merchant as the merchant of record, and none of them asks you to rebuild your checkout.

Why shopping agents need protocols at all

A browser agent driving your checkout page is a bad idea for everyone involved. It mis-clicks, it cannot see a hidden fee, it guesses at a shipping field, and the audit trail is a video of a cursor moving. Payment is worse: an agent that types card numbers is an agent that handles card numbers.

A protocol replaces the clicking with signed, structured messages. The agent asks a merchant's system for a product, builds a cart, starts a checkout session and gets back something it can show a human, and the merchant still runs pricing, tax, fulfilment and refunds from its own system. Stripe's framing of the problem is the sharpest version: traditional e-commerce assumed a human clicking "buy" on a site the business controlled, and "in AI-led commerce, agents act for the buyer, carrying their identity, payment method and purchase context into the transaction".

The consequence for developers is the part that matters commercially: an agent-facing interface is a second front end. You already have two (your shop and your checkout); a third one is not a rewrite, but it is real work, and it is where most teams should start.

What UCP actually covers

The Universal Commerce Protocol is the broadest of the three. It describes five core capabilities: catalog search and lookup, cart building, identity linking, checkout and order management, with a lodging draft in progress and food announced. It runs over REST and JSON-RPC, and AP2, A2A and MCP are supported alongside it, which means the same merchant can serve an assistant, an agent-to-agent flow and an MCP client.

Two design decisions in UCP are worth copying regardless of whether you adopt it. The first is that the business stays the merchant of record: the docs are explicit that the business retains control, its own business logic and the customer relationship. The second is identity linking over OAuth 2.0, so an agent holds an authorized, scoped relationship with the merchant instead of a copy of the customer's credentials. The sample authorization-server document advertises a scope like dev.ucp.shopping.checkout through a standard /.well-known/oauth-authorization-server document, which is an ordinary OAuth integration you can reason about.

UCP owns the commerce lifecycle, AP2 owns the proof of payment. Neither one moves your existing checkout logic.

How a UCP purchase flows through the system

The sample payloads on the UCP site are the fastest way to understand the design, because they show the fields a merchant has to be able to answer. A catalog response carries products with variants, SKU, options, price ranges in minor units, categories from three taxonomies at once (a platform taxonomy, a merchant's own and a Google product category), media with alt text, ratings, arbitrary metadata and a cursor for pagination. That is a product feed an agent can reason about without scraping a page.

A cart is more than a list of lines. The sample cart carries a context with the buyer's country, region, postal code, intent, language and currency; an attribution block with source, medium, campaign, click ID and referrer; a buyer; totals; messages for things the agent should say out loud; links to the privacy policy, terms and FAQ; machine-readable policies such as a return policy with JSON pointers saying which line items it applies to; a continue_url to hand the shopper back to your site; and an expires_at. Two of those fields matter more than they look: attribution is how you keep the marketing credit, and the policy block is how an agent learns your return terms instead of guessing them.

Checkout is a session object with a status such as ready_for_complete, line items, totals, payment and fulfillment groups with selectable shipping options. The order object then carries a checkout_id, a permalink_url, fulfillment expectations, events such as delivered with a tracking number, and adjustments for refunds. In other words the order is a living record, not a confirmation email, which is what an agent needs when the shopper asks about delivery three weeks later.

Google's under-the-hood write-up from January 2026 reported more than 20 endorsing companies including Shopify, Walmart, Target, Stripe, Visa and Mastercard, across retail, travel and food. The endorsement list is the signal worth watching: a protocol only matters once payment networks and platforms are in it, because those are the parts a merchant cannot replace.

What AP2 adds: proving the human said yes

AP2 exists because of one hard question: when an autonomous agent pays, how does anyone prove the user authorized that specific purchase? The documentation names three gaps that today's payment systems cannot close, and they are the right three: authorization (did the user give this agent authority for this purchase), authenticity (does the request reflect real intent rather than an agent error or hallucination) and accountability (who is answerable if it was wrong).

The mechanism is a mandate, carried as a verifiable digital credential: a tamper-evident, cryptographically signed object. There are two mandates, each with an open and a closed stage. The checkout mandate open stage captures the user's constraints and goals before a cart is final, and the closed stage is the authorization for a specific finalized checkout. The payment mandate open stage captures constraints on payment, such as a budget and allowed instruments, and the closed stage authorizes a specific amount bound to that checkout.

AP2 records intent twice: the constraints the user gave, then the authorization for the exact cart and amount.

Two details from the documentation matter for implementation. AP2 is a non-proprietary extension of A2A and MCP rather than a closed loop, and standardization continues in FIDO Alliance working groups, with the spec at version 0.2 and the first version covering "pull" payment methods such as credit and debit cards, with push payments and wallets on the roadmap. If your business is B2B and invoices rather than cards, AP2 matters to you mainly through UCP, not directly.

Where ACP fits: orders from inside an assistant

ACP is the narrowest of the three and the most concrete. Stripe and OpenAI announced it on 29 September 2025 as "a new, merchant-friendly open standard co-developed by Stripe and OpenAI", alongside Instant Checkout in ChatGPT, where US shoppers could buy from Etsy merchants and shortly from a large group of Shopify merchants.

The mechanism is worth understanding because it solves the credential problem without a protocol for credentials. After the buyer pays in the chat, Stripe issues a Shared Payment Token, scoped to a specific merchant and basket total, which lets the assistant initiate a payment without ever exposing the buyer's payment credentials. The token goes to the merchant over the API, and the merchant can process it through Stripe or another provider while still using Stripe's risk scores. Orders themselves flow from the assistant to the merchant's backend over ACP, where the merchant accepts or declines, charges, handles tax and does fulfilment exactly as it always has.

Two caveats. ACP is an assistant-and-platform story rather than a general agent standard, and in March 2026 reporting described Instant Checkout as moving to Apps, which is a change of emphasis rather than a retirement. Also relevant: Stripe has been shipping an agent toolkit and a Stripe MCP server, so a lot of "agentic commerce" in practice is an MCP client talking to a payments API, not a protocol rollout.

The three protocols compared

The three overlap and none replaces the others. UCP is the lifecycle, AP2 is the payment proof, ACP is the assistant-native order path, and WebMCP is the on-site alternative where the agent stays in the browser.

	UCP	AP2	ACP
Scope	Catalog, cart, identity, checkout, order	Payment authorization and audit trail	Orders and payment from an assistant
Who runs it	Google with retail, travel and payment partners	Google, standardizing in FIDO groups	Stripe and OpenAI
Identity	OAuth 2.0 account linking, scoped	Signed mandates, role-based privacy	Shared Payment Token, no raw credentials
Merchant of record	Stays with the business	Not a commerce role	Stays with the merchant
Maturity in 2026	Core spec, lodging draft, food announced	Version 0.2, card methods first	Live in ChatGPT, emphasis shifting to apps
Use it when	You want to be purchasable by any agent	Autonomous or delegated payment is real	Your customers shop inside an assistant

The fourth option is not a protocol and often the cheapest. If the agent is inside your own page, you do not need any of this: register declared tools with the browser and let the agent call your catalog, your stock and your cart directly, as this site's WebMCP implementation does. That works today in an origin-trial browser, it needs no partner integration, and it keeps the shopper on your checkout.

What a mid-size EU shop should do now

Having spent a decade on B2B commerce and PIM platforms, my advice for a shop in this position is deliberately boring. Make the catalog machine-readable and correct before joining anything: a product feed with variants, SKUs, tax classes, stock state and unit pricing, because every one of these protocols starts from the same assumption that you can answer questions about a product. That is the same discipline as serving Markdown to agents instead of scraping HTML, applied to data instead of pages. Then implement UCP's shape of catalog, cart and order if your customers are consumers, because it is the broadest spec and the one most likely to be required by a platform you cannot negotiate with.

Do not rebuild checkout. Every one of these designs explicitly keeps the merchant's own systems as the merchant of record, and a checkout rewrite is a multi-quarter risk with no proven payoff. For B2B, the higher-leverage move is an MCP server over your own domain APIs, quoting tools for availability, lead times and order status, so your customers' internal agents can work with you directly. That is a smaller project than a protocol certification and it produces value immediately, and it pays off whatever the protocols do next as long as the tools are few and well described.

The honest trade-off: all three specifications are young and may change, AP2 is not yet relevant unless you take card payments for autonomous purchases, and being early costs integration work with no guaranteed traffic. Wait for the parts that your biggest platform partner demands, and spend the time on the data quality every protocol needs.

Agentic commerce checklist

Make the catalog queryable: variants, SKUs, minor-unit prices, tax class, stock state, images with alt text.
Publish machine-readable policies, returns and shipping included, so an agent can state your terms instead of guessing.
Keep attribution in the cart payload, or you will lose the credit for sales you were sent.
Stay the merchant of record and keep pricing, tax, fulfilment and refunds in your own system.
Use scoped OAuth for agent access, never a shared account or a long-lived token.
Never let an agent see raw card data; if you join ACP, that is what the Shared Payment Token is for.
Add WebMCP tools on your own site for read actions, so in-page agents do not have to scrape.
Expect the spec to move. Version your integration and keep the adapter thin.

If you are building this kind of integration, the B2B e-commerce developer page covers how I structure the work, and the B2B e-commerce page covers the PIM and catalog side that every one of these protocols depends on.

Agentic commerce for shop developers: UCP, ACP and AP2 compared

Key takeaways