Universal Commerce Protocol (UCP): How AI Shopping Integrations Work

The Universal Commerce Protocol (UCP) is an open standard that lets commerce platforms, AI agents, merchants, and payment systems describe and use compatible shopping capabilities. It is intended to reduce the need for a different custom integration between every agent and every retailer.

Google introduced UCP with retail and commerce partners, but UCP is not a proprietary Google-only checkout product. The specification is open source, and a business chooses which capabilities it exposes. Current capabilities cover areas such as catalog search, cart building, identity linking, checkout, and order management.

What problem UCP is designed to solve

An AI assistant can suggest a product from information on the web, but completing a reliable purchase requires authoritative data and actions. It must know whether the exact variant is available, obtain the current price, calculate shipping options, apply the merchant's policies, request a valid payment method, and create an order without duplication.

Without a shared protocol, each platform would need to learn a different set of merchant endpoints and data structures. UCP provides common concepts and schemas so the two sides can discover supported capabilities and agree on how to communicate. It works over familiar web technologies; this guide to how HTTP works explains the request-and-response foundation used by web APIs.

Who developed UCP?

Google announced UCP in January 2026 and said it was co-developed with Shopify, Etsy, Wayfair, Target, and Walmart, with support from additional companies across retail, payments, and technology. The partner list demonstrates broad industry participation, but endorsement does not mean every feature is live at every company or available to every merchant.

The safest source for implementation details is the current UCP project documentation. Protocol capabilities and platform onboarding requirements can change, so developers should use the current specification rather than treating an announcement article as an integration guide.

Core UCP capabilities

Capability	Purpose	Important merchant responsibility
Catalog search and lookup	Lets a compatible platform find products and retrieve selected details	Return the correct product, variant, price, currency, availability, and attributes
Cart	Builds or transfers a cart while preserving item and quantity selections	Revalidate every line and provide a stable destination or continuation state
Identity linking	Connects a customer's merchant account with explicit authorization	Limit scope, protect account data, and provide a way to disconnect access
Checkout	Coordinates fulfillment choices, totals, payment, and transaction completion	Calculate authoritative totals, validate inventory, process payment, and prevent duplicates
Order management	Exposes supported post-purchase status or actions	Keep order state accurate and identify the merchant's support and policy paths

Support is negotiated by capability. A business can expose only the functions it has implemented, while a platform can adapt to that declared set. UCP does not require every merchant to support the entire shopping lifecycle.

Catalog access is not the same as a product feed

A scheduled product feed helps a platform index a catalog for discovery. A real-time catalog capability can retrieve selected current details when an interaction requires them. These mechanisms complement each other: a feed can provide broad coverage, while a live lookup can verify a specific variant, price, or inventory state.

Visible product pages and product structured data still matter for conventional search and customer verification. However, adding Schema.org markup does not itself implement UCP. A UCP integration requires the profiles, schemas, endpoints, authentication, and behavior defined by the protocol or the participating platform.

How cart continuity works

When an AI assistant has identified several items, a cart capability can preserve the exact selections rather than forcing the shopper to repeat the search on the merchant's site. The merchant must still check the line items. A transferred cart should not carry forward an expired price, an unavailable variant, or an invalid promotion as though it were guaranteed.

Each cart or checkout request should use stable identifiers and duplicate-request protection. If the network times out after an order is created, a retry must return the existing result or safely continue—not charge the customer twice.

Identity linking and loyalty

Identity linking allows a customer to authorize a relationship between a platform and an existing merchant account. When the integration supports it, this can make account-specific information or benefits available during the shopping journey.

It should not be implemented as a transfer of raw account credentials. Use supported authorization flows, request only necessary scopes, set appropriate expiration, and let the customer review and revoke access. Account linking also does not guarantee that every membership benefit applies; the checkout must calculate the actual eligible price and terms.

Both customers and merchant staff should protect connected accounts with strong, unique passwords and multi-factor authentication where available.

Checkout and payment responsibilities

UCP can carry checkout information and support tokenized payment patterns, but the protocol is not a payment processor. The business commonly remains the merchant of record, and a payment service provider authorizes and settles the transaction.

Before completion, the merchant needs to validate:

• the exact items, variants, quantities, and seller;
• current price, discounts, currency, tax, duties, shipping, and final total;
• inventory and destination restrictions;
• delivery or pickup options;
• return, warranty, subscription, and cancellation terms;
• the customer's explicit authorization; and
• payment status and a unique order identifier.

UCP security features do not remove a merchant's existing legal, privacy, payment-card, fraud, tax, or consumer-protection obligations. Requirements depend on the transaction and jurisdiction, so regulated or high-risk implementations need appropriate specialist review.

How a merchant can prepare

1. Normalize product data

Create stable IDs for products and variants. Standardize titles, brands, model numbers, dimensions, compatibility, materials, images, price, currency, and stock. Resolve contradictions between the catalog, feed, visible page, and checkout.

2. Decide which capabilities are useful

A merchant may begin with discovery or cart transfer rather than direct checkout. Map each proposed capability to a customer need, an authoritative backend system, an owner, and a fallback path.

3. Build against the current specification

Publish the required business profile, declare only implemented capabilities, secure the endpoints, and validate request and response schemas. Developers who are new to application interfaces can first review a practical introduction to working with APIs; a production commerce integration also requires experienced security and payments engineering.

4. Test failures, not only the happy path

Cover an unavailable variant, changed price, invalid address, unsupported shipping option, tax recalculation, payment decline, expired token, repeated request, timeout, partial response, cancellation, and refund. Confirm that uncertain cases stop safely and show the customer what to do next.

5. Use the platform's onboarding tools

Google's Merchant Center UCP integration tools support configuration, sandbox testing, endpoint validation, and production readiness checks. Google says this interface is rolling out gradually in the United States, so it may not be visible in every account.

6. Monitor production behavior

Track catalog misses, stale-data conflicts, cart-transfer success, checkout errors, authorization failures, duplicate prevention, completion, cancellations, returns, and support contacts. Version the integration and plan how to disable a capability without taking the normal store offline.

What UCP does—and does not—guarantee

• It does provide a shared way to declare and invoke commerce capabilities.
• It does support interoperability with existing merchant and payment infrastructure.
• It does not guarantee that a platform will display a particular product.
• It does not make inaccurate catalog data reliable.
• It does not automatically activate every capability or merchant.
• It does not replace user consent, security controls, or operational ownership.

UCP is best understood as integration infrastructure. Its value depends on disciplined product data, secure endpoints, authoritative checkout calculations, clear customer approval, and dependable post-purchase support.