Universal Commerce Protocol (UCP) is an open commerce protocol launched in January 2026. Its public specification defines how a business advertises the commerce services and capabilities that compatible agents can use.
The canonical discovery mechanism is a JSON profile at /.well-known/ucp. The profile declares services, versioned capabilities, extensions and payment handlers. A caller and a business negotiate the intersection of the capabilities and versions they both support. These mechanics are documented in the project's core concepts and public repository.
Definition in one sentence
An open protocol through which a business publishes commerce capabilities and compatible parties negotiate the versions, extensions, payment handlers and transports they can use together.
The architecture defined by the specification
A UCP service groups related commerce behavior. Within a service, a capability is a versioned feature. An extension adds optional data or behavior to a parent capability, while a payment handler describes a supported payment mechanism. An extension is removed when none of its declared parents is retained in the negotiated result.
UCP separates this commerce model from the channel used to carry it. The documented transport bindings are REST, Model Context Protocol (MCP), Agent2Agent (A2A) and Embedded. A business can expose more than one binding without redefining its commerce capabilities.
Discovery and negotiation, step by step
- The business publishes its UCP profile at
/.well-known/ucp. - The caller reads the advertised services, capabilities, extensions, handlers and transports.
- Both sides retain the compatible intersection of capability versions.
- Extensions with no retained parent capability are pruned.
- Public keys represented as JWKs support verification where the specification requires signed material.
This is capability negotiation, not a claim that every implementation exposes every operation. The profile is evidence of what a particular business advertises at a particular time; support, deployment and adoption must be verified separately.
Names, versions and extensions are part of interoperability
Capability identifiers use reverse-domain names, such as dev.ucp.shopping.checkout, so the namespace owner is explicit. Versions are dates. During negotiation, the server selects the newest date supported by both parties; if there is no shared version, that capability is excluded. Extensions declare their parent capabilities and are pruned when none is retained. Capabilities in the UCP-owned namespace follow the specification release; third-party extensions can publish on their own cadence. These rules are small, but they prevent two implementations from claiming compatibility while silently speaking different revisions.
UCP also should not be confused with the Agent Payments Protocol (AP2). AP2 v0.2 defines itself as a security feature used inside a commerce protocol: it adds verifiable evidence of intent and authorization, while product discovery and checkout APIs remain outside its scope. The AP2 specification explicitly lists UCP as compatible. In practical terms, UCP can describe the transaction and AP2 can prove what was authorized.
Four editorial views of the wider ecosystem
The following views are an editorial map of the wider commerce ecosystem. They are not four normative layers of the UCP specification, and the listed technologies are not automatically part of UCP.
- Semantic plane, how a product, offer, variant, policy and intent are described. Touches product catalogs for AI, schema.org Product/Offer, GS1 attributes, category taxonomies.
- Discovery plane, how an agent finds a merchant or a specific offer. Touches feeds, sitemaps, marketplace APIs, retrieval indexes, agent-facing catalogs.
- Transactional plane, how an agent places an order and pays. Touches Stripe Agentic Commerce, Visa Intelligent Commerce, Mastercard Agent Pay, PayPal, checkout APIs, order lifecycle events.
- Trust plane, how both sides verify identity, authenticity, provenance and policy compliance. Touches agent-as-user credentials, verifiable claims, dispute mechanisms, fraud controls scoped to agents.
Why the protocol model matters
The conversation today is badly fragmented. Payment companies discuss agent checkout. PIM vendors discuss catalog enrichment. AI labs discuss tool use and retrieval. Standards bodies discuss schema evolution. Each is right about their piece. None alone explains why a small merchant in Lyon, a global brand in Tokyo and an autonomous agent written by a student in São Paulo should be able to interoperate by default.
Reading UCP as a concrete protocol forces three disciplines:
- Systemic view. Treat commerce as a system that must serve a new client (the agent), not a feature to bolt on.
- Composability. Recognize that no single vendor owns the stack, so designs must compose.
- Operator framing. Translate infrastructure conversations into what merchants should actually do.
Relate each topic to the specification
| Topic | Relationship to UCP |
|---|---|
| Catalog, cart and checkout | Check the capability, version and extensions exposed by the implementation. |
| Feeds, sitemaps, schema.org and GS1 | Adjacent sources or standards; their presence does not establish UCP compatibility. |
| Payment and authorization | Check negotiated handlers. AP2 is a separate specification whose support must be established. |
| Merchant migration, SEO and organization | Operational preparation, rather than normative protocol capabilities. |
Four levels of adoption evidence
This is an editorial classification for assessing a specific claim, not a blanket maturity score for a vendor.
- Specified: a function appears in an identified documentation version.
- Announced: a company describes a product or plan with a date and scope.
- Available: the function is accessible in an identified product and market.
- Measured usage: evidence documents actual use over a stated period and method.
A scenario remains a hypothesis until evidence supports the claimed outcome. A partner list does not replace an integration test or an order measurement.
A precise mental model
Think of UCP as a discoverable contract. The business publishes what it supports, the caller selects the compatible intersection, and the parties use a documented transport binding. This model is narrower and more testable than treating every commerce feed, payment rail or AI integration as part of UCP.
To go deeper, read why commerce needs machine-readable infrastructure, then map the ecosystem via standards, schemas and protocols, and see how this applies to AI agents in commerce.
Frequently asked questions
Is UCP an actual specification?
Yes. UCP has a public specification and repository. Its documented concepts include discovery profiles, services, capabilities, extensions, payment handlers, negotiation and transport bindings.
Who owns it?
Google and Shopify each document their work on UCP, and the specification is published in a public project repository. That does not make either company's product API synonymous with the protocol. Governance and contribution claims should be taken from the current repository rather than inferred from branding.
Is this "conversational commerce" rebranded?
Conversational commerce describes an interaction through dialogue. UCP describes a technical contract between systems. A conversational interface can use UCP, depending on its integration.
Does UCP require me to adopt a specific vendor?
The specification is public and supports several transports, but that fact alone does not prove that every implementation is portable or interoperable in practice. Evaluate the exact capabilities, versions, extensions and payment handlers exposed by each implementation.
Is it the same as AI SEO or llms.txt?
No. AI SEO / GEO addresses content-site visibility in AI answer surfaces. llms.txt is a site-level guidance file. UCP is scoped to commerce-specific primitives, catalogs, offers, stock, policies, transactional intent.
Where to go next
- Understand the problem UCP responds to.
- See how AI agents actually interact with commerce today.
- Map the standards and protocols in play.
- If you're a merchant, start with the readiness checklist.
Primary sources
- UCP core concepts: discovery, services, capabilities and negotiation
- Universal Commerce Protocol public repository
- Shopify Engineering: Building the Universal Commerce Protocol
- Google Developers Blog: Under the hood of UCP
- AP2 v0.2 specification: scope, roles and compatibility with commerce protocols
Deep dives
- Implementing UCP: complete technical guide (2026)
- Agent Payments Protocol (AP2): how agentic payment works
- UCP vs MCP: two complementary AI agent protocols
- UCP retailers: announcements, support and adoption evidence
- Agentic commerce statistics 2026: key figures
- From HTTPS to UCP: history of open standards in e-commerce
- ACP vs UCP: the two agentic commerce protocols
- Universal Commerce Protocol Google 2026: the real technical standard
Update · May 2026
Google's official guide for AI search names the Universal Commerce Protocol and links to ucp.dev. See our breakdown of Google's GEO guide. Source: Google.