Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
AI agents got good at finding products long before they got a standardized way to actually buy them. The unfortunate reality for consumers is that an agent can compare headphones across two dozen retailers, but completing a purchase on the user’s behalf hasn’t yet matured to a point of universal acceptance. For most scenarios today, shopping with an agent means either clicking a link (for the user to transact manually) or relying on a custom integration.
The Universal Commerce Protocol (UCP) is a direct response to this problem. Launched in January 2026 by Google, UCP is an open standard that gives agents, merchants, and payment providers a shared language for the full commerce lifecycle: product discovery, checkout, identity linking, payments, and post-purchase order management.
This post covers what UCP is, how its discovery and capability model works, and why its identity linking capabilities deserve more attention than they’re getting.
What is the Universal Commerce Protocol (UCP)?
UCP is an open-source specification that standardizes how AI platforms transact with businesses. Beyond its notable co-developers (Shopify, Etsy, Wayfair, Target, and Walmart), the protocol launched with endorsements from more than 20 partners across retail and payment providers, including Mastercard, Stripe, Visa, and American Express.
The big differentiator between UCP and similar protocols is scope. Where OpenAI and Stripe’s Agentic Commerce Protocol (ACP) concentrates entirely on checkout and payment delegation, UCP covers the entire journey: catalog search, payment, tracking, returns, and everything in between.
Google’s other agentic commerce protocol, the Agent Payments Protocol (AP2), handles the main trust question (“Did the user actually authorize that payment?”), and UCP answers the orchestration piece (“How do an agent and a merchant transact at all?”). The two are designed to work together; UCP includes an AP2 mandates extension for transactions that require cryptographic proof of user consent.
Read more: The Developer’s Guide to Agentic Commerce
The core design philosophy behind UCP is comprised of two parts, both which distinguish the protocol from a traditional API:
The merchant isn’t superseded by the agent’s platform. The agent platform is just an interaction layer, and the customer relationship stays with the business. UCP transactions run against the merchant’s own catalog and payment processes, and those make it the merchant of record.
The protocol is transport-agnostic. Merchants can expose UCP capabilities over REST, as tools on a Model Context Protocol (MCP) server, or via Agent2Agent (A2A) Protocol, depending on what they already support.
How UCP works
UCP defines four participant roles:
The platform is the agent-facing surface where the user expresses intent. This could be an AI assistant, a chat interface, or an app.
The business is the merchant selling the product.
The credential provider manages the user’s payment credentials and personal data, issuing tokens rather than exposing raw card numbers.
The payment service provider (PSP) processes the actual charge.
The user in the above diagram isn’t really a participant role in the language of UCP. They authorize everything, through consent screens, identity linking, and (where applicable) AP2 mandates. But they never speak the language of the protocol themselves. Every UCP message flows between these four participants acting on the user’s behalf. The discovery profile, covered next, is likewise an artifact the business publishes rather than an actor in the UCP equation.
Discovery and capability negotiation
UCP begins with a JSON document the merchant publishes at /.well-known/ucp (a discovery profile at a standardized URL path). The profile states the protocol version, the services and capabilities the merchant supports, its accepted payment handlers, and the public signing keys platforms use to verify webhook and other authenticated messages from the business.
Platforms publish profiles of their own, and the active capability set for any interaction is negotiated as the intersection of what both sides declare. UCP’s capability negotiation follows a server-selects architecture, which lets the business determine the active capabilities from that intersection. This means a small merchant that only supports UCP’s checkout and a large retailer that supports everything can both use it while speaking the same language.
Capabilities and extensions
The UCP spec is quite layered, with core shopping primitives (checkout sessions, line items, totals, statuses) settling at the bottom:
Capabilities are the major functional units built on those primitives: Checkout, Catalog, Order, Identity Linking, and Payment Token Exchange (and each are independently versioned).
Extensions augment capabilities with optional, domain-specific behavior; the AP2 mandates extension (which attaches cryptographic proof of user authorization to a checkout) is the flagship example.
With extensions, merchants implement only what they need, and the extension model keeps the core spec from attempting to resolve every industry’s edge cases.
The checkout lifecycle
A UCP checkout is a stateful session that moves through a defined state machine. Example session states include:
incompleteis as the name suggests; the session lacks required information the agent should try to resolveready_for_completemeans the checkout session has all the information it needs, and platform the can finalize it programmaticallycompletedis self-explanatoryMeanwhile, cancellation is available throughout the session.
This design is aware that not every transaction can finish headlessly: Strong Customer Authentication (SCA) challenges, identity verification, and CAPTCHA still require a human. When they appear, the merchant returns a continue_url (a fallback link into the merchant’s own web experience) so the user can finish the step the agent cannot.
But a UCP order’s journey doesn’t simply end after payment. Order lifecycle events that surface after purchase completion (e.g., shipped, delivered, returned) flow back into the platform as signed webhooks.
Payments
UCP deliberately separates the commerce flow from payment execution. Merchants declare supported payment handlers in their profile (/.well-known/ucp), which lets them keep existing PSP integrations rather than adopting a new payment rail. Credentials move as tokens from the credential provider through the platform to the merchant; the design goal here is that raw payment credentials are never handled by the agent. For autonomous, human-not-present (HNP) purchases, the AP2 extension added the mandated-based audit trail.
Read more: What is the Agent Payments Protocol (AP2) and How Does It Work?
How identity linking enables agents to shop on a user’s behalf
Most explanations of UCP focus on the checkout enablement piece. The most consequential element from an auth perspective, however, is its identity linking capability. This is the mechanism by which the platform obtains authorization to act on a specific user’s behalf at a specific merchant.
Without it, an agent transacts anonymously. The merchant can’t connect the session to an existing account, so the user’s stored information (addresses, order history, loyalty entitlements, etc.) are all unavailable. Every checkout starts with the agent collecting basic buyer details from scratch, which defeats the purported ease of agentic commerce.
Identity linking closes the loop by letting the user delegate their standing at the merchant to the agent, with the merchant’s knowledge and consent.
The mechanism is standard OAuth 2.0:
The platform initiates an Authorization Code Flow with Proof Key for Code Exchange (PKCE) against the merchant’s authorization server. PKCE is mandatory for public clients. The user authenticates directly with the merchant, and the agent never sees credentials.
The merchant publishes its OAuth endpoints via authorization server metadata at
/.well-known/oauth-authorization-server, so platforms can discover them programmatically.The merchant issues scoped access tokens. PKCE with S256 (a secure hashing protocol) for all code exchanges since agent platforms are frequently public clients.
With a valid token, the platform can resolve the buyer’s profile and carry their entitlements into checkout.
How UCP identity linking addresses scopes
The March 2026 revision to the identity linking spec of UCP reworked this capability in a way that should look familiar to anyone tackling Model Context Protocol (MCP) authorization. A mechanism registry lets merchants declare which linking mechanisms they support in a structured way, so the spec can absorb new authentication methods without breaking existing implementations. Capability-driven scopes tie what an agent requests to what it intends to do, so an agent that only needs catalog access never holds checkout permissions.
But the required flow is more demanding than vanilla OAuth 2.0, since PKCE is now a requirement. MCP as a transport brings in Dynamic Client Registration (DCR), which allows agent platforms to onboard without manual setup. This combination of Authorization Code Flow with PKCE, metadata discovery, and DCR is effectively the OAuth 2.1 posture the MCP authorization spec arrived at after its first year, just applied to agentic commerce. It faces the same open challenges, though, like how to trust clients that register themselves, which the MCP ecosystem is answering with Client ID Metadata Documents (CIMD).
Ultimately, the implementation burden lands on the merchant. To participate in the identity linking piece of UCP, you need to operate a full OAuth 2.0 authorization server—that means token lifecycle management, client registration, consent, everything. Merchants who already run OAuth for their own apps can extend it, but merchants who don’t face a substantial identity build before the capability can be declared at all.
The alternative is sidestepping the build with an existing authorization server. For example, Descope can serve as the authorization server behind a UCP identity linking implementation, providing the endpoints, metadata, consent screens, and scope enforcement while the merchant’s UCP profile points agents to it. Our guide to building a UCP server with identity linking walks through that setup end to end.
Where UCP stands in the wider protocol ecosystem
Google shipped the first UCP reference implementation, which powers direct checkout from eligible U.S. retailers inside AI Mode in Google Search and the Gemini app. Google Pay handles payment using credentials already stored in Google Wallet. To participate in this, merchants must have an active Merchant Center account.
Shopify, as a co-developer, built UCP support into its platform, and the protocol’s roadmap currently points beyond retail into lodging and food ordering, along with multi-item carts, loyalty account linking, and expanded post-purchase support. Those aren’t the only production implementations, but those outside them are relatively few, for now.
The open question at the heart of UCP’s adoption (or really any other agentic commerce protocol) is not whether the plumbing works, but whether consumers will actually use it anytime soon. Customers are warming to the idea of agents as shopping assistants more than they are to agents as shoppers. Accenture’s 2026 Consumer Pulse survey of more than 25,000 consumers found that 74% would delegate routine commerce tasks like reorders and subscription renewals to an agent, but only 9% are open to fully autonomous purchasing.
Meanwhile, Zeta Global’s research on what they term “active” AI shoppers points in a similar direction: 70% prefer to complete the purchase on the brand’s own site even when AI handled the discovery. OpenAI already adjusted to this reality, shifting its ACP-based flows toward merchant hosted checkout after in-chat purchasing saw minimal adoption. Agents now handle discovery and cart building, then hand the user to the merchant’s own environment to pay.
But this is where UCP gets really interesting. Unlike other protocols in play, UCP doesn’t live or die on in-chat checkout. Merchants declare only what they support, and each capability is still useful on its own:
Discovery profiles make catalogs agent-parseable
Identity linking carries loyalty and saved details into agent sessions
Order webhooks keep post-purchase status updated
None of these depend on the agent pressing that final “buy” button. UCP doesn’t need universal buy-in or full delegation to be worth implementing; it just needs to be useful wherever an agent actually joins the journey. As agentic workflows become routine in daily life, and the trust mechanisms mature, UCP is uniquely positioned to tackle the steps consumers eventually hand over.
The identity layer underneath UCP
Every commerce protocol in this space carries its own trust mechanisms. ACP has Shared Payment Tokens, AP2 has mandates, UCP has identity linking and signed messages. All of these assume an earlier question has already been addressed: who is this agent, who is it acting for, and what is it authorized to do?
That question is actually answered upstream of the protocol. An agent connecting to a merchant’s MCP server (one of UCP’s supported transports) has to authenticate, establish the user it represents, and receive scoped access before any UCP capability can fire. And on the merchant side, identity linking turns the quest to “support agentic commerce” into a harrowing “build and maintain a standards-compliant OAuth 2.0 authorization server,” loaded with consent management and client registration for agents you’ve never met.
This is the layer where the Descope Agentic Identity Hub operates. It gives developers an OAuth 2.1 authorization server for the MCP servers and APIs, support for both DCR and CIMD, along with consent, scope, and token management out of the box. Agentic commerce may take years to settle, and in the meantime, protocols like UCP will keep raising tough questions and requirements. Identity infrastructure that’s driven by the same underlying standards is what will let developers move with these shifting challenges instead of rebuilding for each one.
Check out this working implementation of a FastMCP server built for a shopping site that uses Descope Agentic Identity Hub as the identity layer while supporting UCP.
Explore Descope’s Agentic Identity Hub now by signing up for a Free Forever Descope account. If you’d like to talk through your agentic commerce project with our auth experts, schedule a demo and join the AuthTown dev community.
