· Updated
Google's Universal Commerce Protocol (UCP): what it asks of your online store
UCP lets AI agents search a store's catalogue, build a basket, check out and track the order. Here's what a store has to run to support it (discovery, negotiation, checkout states, idempotency, signed messages, order webhooks, versions) and what you can do today.
Short answer: the Universal Commerce Protocol (UCP) is the open standard, backed by Google, that lets an AI agent shop a store on someone’s behalf: find products, build a basket, check out and follow the order. Supporting it isn’t a setting you switch on. A store has to publish a signed profile, negotiate capabilities with every agent platform, run checkout as a strict state machine, sign its responses and webhooks, and keep up with a specification that ships new dated versions. Shopify builds this into the platform; WooCommerce, Magento and custom stores need it built for them.
This guide walks through what UCP actually involves, using the current release (2026-08-25), so you can judge what it means for your store.
What UCP does
UCP describes, in machine-readable form, everything an AI agent needs to buy from a store without a human clicking through the website:
- Discover what the store supports and how to reach it.
- Search and look up products, variants, prices and availability.
- Build a cart and a checkout, including delivery options and totals.
- Hand over payment to the shopper, or complete it with a supported payment method.
- Follow the order after it’s placed: shipping, refunds, cancellations.
It’s published as an open specification with dated releases. The same capabilities can be offered over a REST API and over MCP (the Model Context Protocol that AI assistants use to call tools).
The parts a store has to run
1. A discovery profile at /.well-known/ucp
Every UCP store publishes a profile at a fixed address on its domain. It lists the services the store offers, each capability with its specification and schema, the payment handlers it accepts, and the store’s public signing keys (as JSON Web Keys). Agents read this first. If it’s missing, malformed or out of date, an agent can’t shop the store at all.
2. Capability negotiation on every request
Agents don’t just call the store. Each request names the agent platform’s own profile (the UCP-Agent header). The store has to fetch that profile, cache it properly, work out the intersection of what both sides support, prune extensions neither can use, and answer with the specific errors the spec defines when something doesn’t line up: an unreachable profile, a malformed one, an unsupported version, incompatible capabilities.
3. Catalogue search and lookup
Search with filters (prices in minor units, categories), cursor pagination, and one featured variant per product. Lookup by product or variant ID, with limits on batch size. Product detail with selected options, and whether each option value exists and is available. All of it has to match what the shop is really selling, in real time.
4. Carts and checkout as a state machine
A UCP checkout moves through defined states: incomplete, requires_escalation (the shopper has to do something, such as give an address), ready_for_complete, complete_in_progress, completed and canceled. Updates replace the whole object rather than patching fields. Delivery options come from the store’s real shipping rates. Get a transition wrong and the agent stalls, or worse, thinks an order exists when it doesn’t.
5. Idempotency on every write
Agents retry. So every write carries an Idempotency-Key, and the store must replay the original response for a repeat, refuse the same key with a different body (HTTP 409), and compare requests by the SHA-256 of the raw body bytes, not by “the JSON looks the same”. Without this, a network blip can create two checkouts or two orders.
6. Payment: handlers or a hand-off
UCP lets a store advertise payment handlers, or hand the shopper to its own checkout to pay (an escalation with a continue_url), optionally inside an embedded checkout that talks to the agent through a defined message channel. Which route you take decides who touches the money, and that has security and compliance consequences of its own.
7. Signed responses and messages
UCP uses HTTP Message Signatures (RFC 9421) with a Content-Digest of the body. The store signs its responses with the key from its profile, and verifies signed requests from platforms against the keys in their profiles, within a time window. Bodies are canonicalised (JCS) so the digest is the same however they’re read. Rotate a key carelessly and every agent stops trusting the store.
8. Orders and webhooks
After checkout, the store sends order events to the platform that placed the order: created, status changes, refunds. They have to be signed, retried with back-off, never delivered twice, and survive a server restart. Only the platform that created a checkout may read its order.
9. An MCP binding
The same catalogue, cart, checkout and order capabilities are defined as MCP tools (thirteen of them in the current release), with their own rules for metadata, idempotency keys and errors. Many AI assistants will reach a store this way.
10. Versions
UCP ships as dated releases. Each one can change schemas, add capabilities or alter behaviour, and stores have to negotiate versions with platforms that may be on a different one. Supporting UCP is a commitment to keep up, not a one-off build.
Why this is hard for an independent store
- It’s protocol engineering, not a plugin setting. Signatures, canonical JSON, idempotency and state machines are the kind of work payment companies have specialist teams for.
- It has to stay true to the shop. Stock, prices, variants, delivery rates and tax all have to be right in every answer, or agents will recommend things that can’t be bought.
- Agents placing orders is a security question. Which agents may buy, with what limits, and how you switch them off all need deciding and enforcing.
- It keeps moving. New releases, new capabilities and new agent platforms arrive through the year.
Shopify stores get agent checkout built into the platform. For everyone else, it has to be built and kept up to date on top of the store.
What you can do today
- Get your product data right. UCP’s catalogue answers are only as good as your product data: names, prices, stock, GTINs, variants and images. It’s also what AI assistants use to recommend you right now. Our guide to structured product data for AI agents covers it.
- Run the free check. Its protocol readiness section looks for a UCP profile at
/.well-known/ucp, and for discoverable ACP checkout and MCP endpoints, alongside everything else agents need. - Let Proxa Monitor watch it. Once you publish protocol endpoints, Monitor checks them every day with the rest of your store.
- Proxa Connect (coming soon). Connect will publish and run UCP, ACP and MCP for your store, starting with WooCommerce, so you get agent checkout without building any of the above. It isn’t available yet; tell us you’re interested and we’ll let you know when it launches.
In the UK, buying through AI agents isn’t open to stores yet, but AI assistants already search for products and send shoppers to the stores they can read. Getting the product data right now is what puts you in a position to take orders when it does.