Google’s Universal Commerce Protocol (UCP), Explained

For two decades, online stores have been built for a person moving through pages. Search, product page, cart, checkout. Every store implemented that path its own way, and every integration (a marketplace, a price comparison site, a shopping app) had to be built against each store separately.

Agents make that unworkable. A shopping assistant that wants to buy from thousands of stores can’t scrape thousands of checkouts, and a store can’t build a custom integration for every assistant. UCP is the attempt to give both sides one contract.

A shared contract also moves where problems show up. When many agents reach the same store through the same protocol, they can all ask for the last unit within the same second. This page covers what UCP defines and the stock state the business still has to get right.

What Is the Universal Commerce Protocol?

The Universal Commerce Protocol (UCP) is an open standard for agentic commerce. A business publishes a profile describing its capabilities, and any compliant agent can use it to search the catalog, build a cart, run a checkout and follow the order, over REST, MCP or A2A. Payments plug in through handlers, and an optional extension carries AP2 mandates for autonomous agents.

Google announced UCP on January 11, 2026 as “a new open standard for agentic commerce that works across the entire shopping journey — from discovery and buying to post-purchase support.” Google said UCP “was co-developed with industry leaders including Shopify, Etsy, Wayfair, Target and Walmart” and “endorsed by more than 20 others across the ecosystem like Adyen, American Express, Best Buy, Flipkart, Macy’s Inc., Mastercard, Stripe, The Home Depot, Visa and Zalando.” It is “compatible with existing industry protocols like Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP),” and Google said it would “soon power a new checkout feature on eligible Google product listings in AI Mode in Search and the Gemini app.”

The protocol is published at ucp.dev under the Apache 2.0 license, with the source on GitHub. Its announcements page records the governance since launch: Stripe joined Google and Shopify on the Governing Council in April 2026, technical councils for food, lodging and payments formed between July and September, and the latest protocol release at the time of writing is v2026-08-25.

What UCP Defines

UCP is built from capabilities. The ucp.dev overview lists catalog, cart, checkout, identity linking (OAuth 2.0) and order, plus a draft booking capability for lodging, with food marked as coming soon.

Discovery. Per the specification overview, “Businesses publish their profile at /.well-known/ucp.” The profile carries the protocol version, the services and payment handlers the business supports, and optional capabilities.

Transports. The overview covers a REST transport, a Model Context Protocol binding, Agent-to-Agent (A2A), and an Embedded Protocol.

Payments. Payment handlers plug in per business. For autonomous agents the spec defines an optional AP2 Mandates Extension and walks through a scenario using it, where “Instead of a session token, the agent generates cryptographic mandates.”

UCP Example: The Business Profile and Negotiation

A business advertises what it supports in a JSON profile at /.well-known/ucp. Abridged from the specification overview:

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [
        { "version": "2026-08-25", "transport": "rest",
          "endpoint": "https://business.example.com/ucp/v1" }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [ { "version": "2026-08-25" } ]
    },
    "payment_handlers": {}
  },
  "keys": [ { "kty": "OKP", "crv": "Ed25519", "use": "sig", "alg": "EdDSA" } ]
}

The agent’s platform publishes a profile too, and “Platforms MUST communicate their profile URI with each request to enable capability negotiation.” Over HTTP that is a header such as UCP-Agent: profile=“https://agent.example/profiles/shopping-agent.json”. The business intersects the two profiles: it keeps each capability both sides list, selects “the highest version (latest date)” they share, and prunes extensions whose parent capability didn’t survive. If nothing is left, it returns capabilities_incompatible.

Shopify’s Ilya Grigorik, writing on launch day, describes the design: “Capabilities add major functional areas: Checkout, Orders, Catalog—each independently versioned,” and “Extensions augment capabilities with domain-specific schemas via composition.”

UCP on Google AI Mode and Gemini

Google’s merchant guide describes the first surface: “Adopt UCP to enable agentic actions on AI Mode in Google Search and Gemini, starting with direct buying.” Merchants use their “existing Merchant Center account shopping feeds” for discovery and “existing payment integrations using payment handlers” for payment. There are two checkout paths. Native checkout is the default: “Integrate checkout logic directly with AI Mode in Google Search and Gemini.” Embedded checkout is “An additional optional path for specific, approved merchants.” On ownership the guide is plain: “You remain the Merchant of Record.”

That puts stock where this page has it: with the business. Google’s surfaces bring the buyer, and the business’s checkout decides what it can promise.

Cart and Checkout

The two shopping objects behave differently, and the difference is where stock decisions live. From the cart spec:

An agent converts a cart by passing cart_id when it creates a checkout. Conversion is idempotent: “If an incomplete checkout already exists for the given cart_id, the business MUST return the existing checkout session rather than creating a new one.”

The checkout spec defines six statuses:

• incomplete: missing information or has issues; the agent resolves them through Update Checkout.
• requires_escalation: needs buyer input the API can’t collect; hand off via continue_url.
• ready_for_complete: “has all necessary information and platform can finalize programmatically.”
• complete_in_progress: Complete Checkout was accepted and the business is processing the order.
• completed: “Order placed successfully.”
• canceled: “Checkout session is invalid or expired.”

Sessions carry an expires_at, and the spec says the platform “will honor the TTL provided by the business.” On stock, UCP gives the business vocabulary: an out_of_stock error code, and the right to revise a requested quantity “for its own reasons (for example, limited stock).”

What UCP Leaves to the Business

What UCP does not specify is when stock is reserved. ready_for_complete says the session has the information it needs. It does not say the item is held. A business can hold stock when the checkout is created, when it reaches ready_for_complete, or only when the agent completes, and the protocol works the same in every case.

Each choice makes a different promise:

No hold until complete. Nothing sits idle, but ready_for_complete can be true for more sessions than there are units.

Hold at checkout creation, expire with expires_at. The agent gets a stable answer while it collects payment. Abandoned sessions tie up stock until the TTL.

Hold, then re-check at complete. The common answer, and the one that needs the most state: open holds per SKU, each session’s hold, and on-hand, all read together.

A Worked Failure: Converting Carts at Once

The numbers below are illustrative, built to show the mechanism.

A home goods retailer lists a discounted espresso machine: 120 units. A shopping assistant features it, and agents start converting carts to checkouts. The retailer’s UCP service checks stock against a search index that a job updates from the warehouse system every two minutes. It holds nothing until complete.

The retailer cancels 110 orders that 110 agents already reported as placed. Through order webhooks the protocol delivers the bad news accurately. It can’t make the news good.

Every step matched the spec. The business said yes on context that was up to two minutes old and didn’t count the other checkouts it had already said yes to. That is a race condition, the same one real-time inventory oversell describes for human shoppers, with agents compressing the timeline.

Authorization-Time Context for a UCP Checkout

Call it authorization-time context: everything the decision to accept a checkout has to read, at the moment it decides. For UCP that decision happens twice, when the business returns ready_for_complete and when it accepts Complete Checkout. Both need:

• Available to sell, net of open holds, per SKU.
• This session’s hold, and whether it outlived expires_at.
• Per-buyer limits for constrained items (“two per customer”), counted across that buyer’s open checkouts, not only completed orders.
• The idempotency record for the request, so a retried Complete Checkout doesn’t create a second order.

These are derived reads over state that every agent session writes. They need to come from one snapshot, current when the business answers.

How to Hold Checkout State

Make the hold a conditional write, in the same transaction as the session change.

-- On transition to ready_for_complete (Postgres-style SQL)
BEGIN;

UPDATE checkouts SET status = 'ready_for_complete'
WHERE  id = :checkout_id AND status = 'incomplete'
RETURNING id;                  -- zero rows: a retry already did this; return the current state

UPDATE stock                   -- one UPDATE per SKU, in SKU order, to avoid deadlocks
SET    held = held + :qty
WHERE  sku = :sku
  AND  on_hand - held >= :qty
RETURNING sku;                 -- zero rows: ROLLBACK; return out_of_stock or revise quantity

INSERT INTO holds (checkout_id, sku, qty, buyer_id, expires_at)
VALUES (:checkout_id, :sku, :qty, :buyer_id, :session_expires_at);

COMMIT;

-- On completed: convert the hold. On canceled or expiry: release it,
-- in the same transaction that changes the status.

Under READ COMMITTED, a second UPDATE on the same stock row waits for the first, then re-evaluates its WHERE clause against the updated row, so two sessions can’t both take the last unit. The status check on the checkout row means a retried update can’t place a second hold. Expire holds with the session’s expires_at, so a checkout that reports ready_for_complete keeps its stock until the session expires.

The conditional update makes the second session wait for the first, then see the stock the first one took.

If your catalog is small and your commerce platform can take agent-rate traffic, put this there. It gets harder when on-hand comes from warehouses and stores, when your order system can’t absorb a read per agent call, or when the checkout also needs per-buyer counts across open sessions.

Where Tacnode Fits

Tacnode holds the checkout’s decision context: what each UCP response reads and what it decides. Orders stay in your order system, which remains the system of record.

On-hand from the warehouse and order systems arrives by change data capture. Holds, checkout status, per-buyer counts and idempotency keys are state the checkout owns. Held in the Tacnode Context Lake™, they are covered by full ACID transactions: two sessions cannot both hold the last unit, because the hold is a committed write. Available-to-sell net of holds and per-buyer open quantity are computed on demand against the latest committed data, in the same snapshot as the hold. Each completed or canceled checkout is written back and becomes context for the next one.

That closes the context gap for the moment a business tells an agent “ready.” For how UCP compares with the other agent protocols, see agentic commerce protocols compared, and for the buyer side of the loop, how shopping agents buy.

FAQ