Google Universal Commerce Protocol: What Is Live, Limited, and Next

The three phases UCP defines

The protocol splits an agent-driven purchase into three phases, and knowing which one a claim refers to prevents most of the confusion around it. Discovery is a merchant advertising what it can do. Checkout is the money moving. Order is everything after, which is the phase most coverage skips and the one that generates the support tickets.

What UCP is

The open UCP project describes a common language for platforms, businesses, payment service providers, and credential providers. Its architecture separates capabilities such as checkout, identity linking and order handling from extensions and transport methods. The project documents REST, Model Context Protocol and Agent-to-Agent as possible service transports.

Being able to connect does not mean anyone will send you traffic. Standing up an MCP endpoint does not put your store in front of Google, ChatGPT, Bing or any other agent. Each of them decides for itself who gets in, who gets found, who qualifies, what is safe to show, how it ranks, how it looks, and what the commercial terms are.

UCP, MCP, A2A and AP2 are four different things

These arrive together in the same announcements and get used interchangeably, which is why two of the most common questions on this topic are what separates UCP from MCP and what separates UCP from AP2. They sit at different layers and none of them replaces another.

The practical consequence is that “we support MCP” and “we are UCP ready” are not the same claim. MCP is a pipe. UCP is what you say down it. A vendor telling you an MCP endpoint makes your catalogue agent-ready has described the connection and skipped the part where your product data, availability, pricing and checkout have to be expressed in a form an agent can act on. When someone quotes you for this work, ask which of the four they mean and what they are delivering in each.

What Google documents, as read on July 24, 2026

Google has published a merchant guide, an FAQ and a set of Merchant API updates covering UCP, and five things in them decide whether this is relevant to you. The most consequential is the liability one: in the integration model Google describes, you stay Merchant of Record. The rest set out which surfaces are in scope, which checkout paths exist, what Merchant Center has to contain, and which capabilities are gated behind approval. Every item below was read from those documents on July 24, 2026, and the access position in particular can change without notice.

• ✓
  Google positions UCP for agentic actions across AI Mode in Google Search and Gemini, beginning with direct buying.
• ✓
  The merchant remains Merchant of Record in Google's described integration model. That is a tax and liability position, not a technical detail, so confirm it against the current guide and your own advisers before you build against it.
• ✓
  Google describes native checkout as the default integration and an embedded checkout option for specific approved merchants.
• ✓
  The FAQ says Merchant Center remains central and product feeds, brand assets, return policies and business contact information must be complete and current.
• ✓
  Google's Merchant API updates include UCP checkout eligibility reporting contexts and some capabilities that are allowlisted or require a Google representative.

"A documented path is not the same as an available one.

Can someone buy without visiting the merchant website?

Google's documented UCP direction includes checkout in Google surfaces, so a qualifying transaction may not require the normal merchant-site journey. But it is inaccurate to say this already applies to every shopper or store, or that the website receives no visit in every flow. Some flows embed the purchase, some fall back to your site, and sign-in, policy, support and after-sale steps can each behave differently.

Your website still does the work it always did. It is where people find you directly, where the brand lives, where you explain things, where your policies and accounts sit, where support happens, and where shoppers land when the other route fails. Being UCP-ready adds a place to sell. It does not retire the site.

Platform readiness cannot be reduced to a ranking

Shopify, WooCommerce, custom storefronts and other platforms have different official integrations, partner paths and implementation options that can change quickly. Co-development or protocol compatibility does not mean a one-click setting exists for every merchant. A custom stack gives you control over how it is built, and hands you the security, conformance, payment, monitoring and upgrade work that comes with it.

• ✓
  Check the platform vendor's current UCP statement and the exact merchant account, edition and country.
• ✓
  Confirm Google access, Merchant Center eligibility, required feeds and policy status.
• ✓
  Confirm the payment service provider can support the required token and transaction flow.
• ✓
  Write down what will not work: which products, promotions, tax cases, shipping options, sign-in situations, returns, subscriptions and account states fall outside it.
• ✓
  Price all of it: building it, proving it conforms, whatever your vendors charge, running it, having someone review the security, and keeping up as the protocol changes.

Platform-specific reading helps before that check: what headless commerce means for a store owner, how a headless Shopify architecture is put together, and where WooCommerce stores tend to need attention. Our store engineering service page covers the custom-stack version of the same work.

A merchant readiness audit

Eight domains have to hold up before anyone can claim a store is UCP-ready, and this is an inventory rather than a sequence. Most of it is work you should already be able to evidence: catalog accuracy, Merchant Center standing, checkout correctness, payment lifecycle, identity, order handling, request security and data privacy. If a domain below has no owner today, that gap exists whether or not UCP ever reaches you.

• ✓
  Catalog: do your product IDs stay stable, are variants right, are price and availability current, are the images and descriptions there, and how quickly do changes show up.
• ✓
  Merchant Center: are your feeds clean, is your business identity verified, are brand assets and policies in place, can Google reach you, and is the account in good standing.
• ✓
  Checkout: how carts behave, how discounts apply, how tax and shipping are worked out, which currency, whether stock is held while someone pays, whether the total is right, and when a cart expires.
• ✓
  Payments: whether your provider is supported, how tokens move, what happens when a payment is authorized, when it fails, when it captures, when you refund, when a customer disputes it, and whether the numbers match at the end.
• ✓
  Identity: what a guest can do versus someone with a linked account, what each is allowed to do, how someone gets back into a locked account, how an account is deleted, and making sure nobody has more access than they need.
• ✓
  Orders: confirming them, canceling them, shipping them, tracking them, taking returns, issuing refunds, and who answers the customer when something goes wrong.
• ✓
  Security: proving each request is genuine, stopping the same one being replayed, making sure a repeat does not charge twice, checking what was sent, limiting how often, logging it, storing secrets properly, and knowing what to do when something breaks.
• ✓
  Privacy: why you hold each thing, what you tell people, what they can choose, who else sees it, which fields travel, which countries are involved, how long you keep it, who can read it, and how it gets deleted.

Most of that list is catalog and operations work rather than front-end work. The Panda Patches store build shows how we handle catalog, checkout and order data on a shop we operate ourselves, and our WooCommerce engineering page covers the equivalent work on that platform.

Where to start

The audit above is the full picture. If it is more than a small team can take on at once, the first five moves below are useful regardless of when or whether access arrives, because each one improves the store you already run.

• ✓
  Work through your top-selling products first. Check that titles carry the attributes a buyer would specify, that price and availability match what checkout will actually charge, and that specifications, shipping terms and images are complete and current.
• ✓
  Check the Merchant Center account itself: feed status, diagnostics, business identity, policies and contact details. Incomplete or stale account data limits what any Google surface can do with the catalog.
• ✓
  Establish what your current platform and payment provider actually support today, from their own documentation, and what would need building or buying rather than switching on.
• ✓
  Fix the measurable problems on the storefront you already have. Speed, reliability and correct structured data serve human buyers now and remain relevant to any agent-driven surface later.
• ✓
  Keep spending on your own site. It is where you win customers, build the brand, publish your policies, handle support, hold accounts, and catch people when the third-party route fails. None of that moves across.

None of those steps depends on eligibility, an announcement date or a rebuild, which is what makes them safe to start before the access picture is settled.

Discovery and request verification

The open standard uses a well-known profile to declare capabilities. Google's FAQ, read July 24, 2026, also describes signals for identifying UCP traffic and recommends authenticating requests using the provided OAuth bearer token or other secure signatures instead of relying only on geographic IP blocking. Use the current implementation guide, validate issuer and audience where applicable, rotate credentials, and reject unexpected capabilities and payloads.

Measure business impact without inventing it

There is no published universal UCP conversion lift, cart-abandonment reduction, traffic loss, revenue gain, recommendation advantage or adoption deadline that can be applied to a store. Measure the stages separately: who was eligible, who saw you, who started a checkout, who finished one, who cancelled, who returned, who was refunded, what the fees took, and what was left. Compare a defined period and cohort while documenting campaigns, product mix, seasonality and other releases.

• ✓
  Define the merchant system of record and order identity across Google, payment provider and commerce backend.
• ✓
  Use documented channel markers and reporting contexts where available.
• ✓
  Reconcile the money and the order state, not just the events Google says it drove.
• ✓
  Say what the integration covered, when you checked, what it could not do, and how sure you are. Do not assume it caused whatever happened next.

Two references on the measurement side of a storefront: how store speed is measured and improved and Core Web Vitals explained for the difference between lab and field data.

Do you need to rebuild the website for UCP?

Not by default. Improve catalog, Merchant Center, policy, payment and operational data first. Only change platform when the one you have genuinely cannot meet the UCP, performance, security, content, ownership or integration requirements you have agreed, and the total cost still favors replacing it. A headless CMS, Next.js, structured data or an MCP endpoint alone does not guarantee eligibility, discovery, recommendation or a sale.

If replacement does come onto the table, cost the whole thing before deciding: what a store rebuild involves and how a hosted store compares with a custom build set out the trade-offs. A scoping conversation turns that into a plan for the specific catalog and payment setup.

Primary sources

• Universal Commerce Protocol specification and releases
• Google: 2026 NRF announcement