What the Universal Commerce Protocol is
UCP is a common language for commerce, written so that software agents can use it without a human in the loop. The problem it solves is combinatorial: every AI surface that wants to sell things has to understand every merchant's cart rules, discount stacking, tax logic, shipping options, and payment methods, and every merchant would otherwise build a separate integration for every surface. UCP replaces that with one standard vocabulary. A business implements a set of named capabilities, declares which ones it supports, and any agent that speaks UCP can transact with it. Shopify's engineering team described the design as borrowing from TCP/IP: core shopping primitives at the bottom (checkout sessions, line items, totals), named capabilities in the middle, and reverse-domain-named extensions on top that anyone can define without a committee vote. The capability names in the specification look like dev.ucp.shopping.checkout, dev.ucp.shopping.cart, dev.ucp.shopping.catalog.search, dev.ucp.shopping.catalog.lookup, dev.ucp.shopping.order, and dev.ucp.common.identity_linking. That naming scheme is the point: a vendor who owns the domain owns the namespace, so extensions can grow sideways instead of forcing a version bump on the core.
Who developed the Universal Commerce Protocol and who signed on
Google and Shopify co-developed it. Sundar Pichai announced UCP in the NRF 2026 keynote on January 11, 2026, and Google's developer blog and Shopify's engineering blog both published on the same day. The launch coalition Google named runs past twenty partners and mixes retailers, networks, and processors: Etsy, Wayfair, Target, Walmart, Best Buy, Macy's, The Home Depot, Flipkart, Zalando, plus Adyen, American Express, Mastercard, Stripe, and Visa. The presence of the card networks matters more than the retailer names. Visa and Mastercard already run their own agent programs, which we cover in the Visa Intelligent Commerce and Mastercard Agent Pay comparison, and their participation in UCP signals that the networks intend to be the payment handlers inside it rather than compete with it. Governance is genuinely open rather than nominal: the specification lives at github.com/Universal-Commerce-Protocol/ucp under Apache 2.0, with maintainers listed in the repository and contributions accepted through ordinary pull requests.
How the Universal Commerce Protocol works
Discovery comes first. A business publishes a JSON profile at /.well-known/ucp that declares which services and capabilities it supports, which versions, and which payment handlers it accepts. An agent advertises its own profile URL in a UCP-Agent request header. Both sides then compute the intersection of what they mutually support and select the highest shared version of each capability, per transaction. Nothing is hard-coded, which is what lets a merchant add fulfillment options or a new payment handler without every agent re-integrating. Transport is deliberately not fixed. The same capability can be exposed as a REST endpoint described by OpenAPI 3.1.0, as an MCP tool for agents that already speak the Model Context Protocol, over A2A for agent-to-agent flows, or through an embedded binding. Checkout itself is a state machine rather than a single call, and the specification allows escalation: when an agent hits something it cannot handle, the merchant hands back a continue_url and the human finishes in an embedded checkout. That escalation path is the honest part of the design. It admits that autonomous checkout will not cover every cart. UCP orchestrates the purchase; the narrower job of proving the buyer authorized it belongs to Google AP2, which is specified as an extension for UCP rather than a competitor to it.
The four roles UCP defines, and why they matter for payments
The specification names four participants, and the split is where the payments story lives. A Platform is anything that consumes capabilities: an AI agent, a mobile app, a procurement system, or another business. A Business exposes capabilities and is typically the merchant of record. A Credential Provider holds the sensitive user data, meaning payment instruments and shipping addresses. A Payment Service Provider processes the money for the business. Credentials move in one direction only. The platform obtains a payment instrument from the credential provider, passes a token to the business, and the business must not echo credentials back in its responses. Three separate bilateral trust relationships, no shared secret sitting in the agent's context window. That design decision is why prompt injection against a UCP agent cannot exfiltrate a raw card number, though it can still convince the agent to buy the wrong thing, which is a different failure we walk through in prompt injection and agent spend.
UCP vs ACP: what is the difference
The two standards were built by rival coalitions for overlapping jobs, and most US retailers will end up supporting both. The Agentic Commerce Protocol came out of OpenAI and Stripe and powers Instant Checkout inside ChatGPT: the merchant shares a product feed with the platform, the shopper buys without leaving the chat, and the merchant receives a tokenized payment. UCP is merchant-hosted and pull-based. Agents query your live catalog through your own endpoints, so inventory and pricing are current by construction rather than as current as your last feed push. The trade is effort: ACP is quicker to adopt because the platform does the heavy lifting, UCP demands real API infrastructure but gives you control and freshness. Scope differs too. ACP concentrates on the checkout handoff. UCP covers catalog search, cart, checkout, order lifecycle webhooks, and account linking, which makes it closer to a full commerce API than a checkout bridge. The practical answer for a US merchant in 2026 is that these are distribution channels, not architectures you pick between. ACP reaches ChatGPT. UCP reaches AI Mode in Google Search, the Gemini apps, and any open-standard agent. We covered the readiness work either one requires in the agentic commerce readiness guide for merchants, and the fee and setup detail specific to ChatGPT in the Instant Checkout guide.
Is UCP the same as AP2, and where does x402 fit
No, and the confusion is understandable because they ship from the same company. AP2, Google's Agent Payments Protocol, is a payment authorization layer: it carries signed intent and cart mandates that prove a human authorized a purchase within stated limits. UCP is the commerce layer above it, and Google documents the two as interoperable, with AP2 providing the secure payment support inside a UCP flow. Neither is a budget. A mandate proves consent for a purchase; it does not stop an agent from making forty consented purchases in an hour. x402 sits somewhere else entirely, reviving HTTP 402 so a machine can pay a fraction of a cent for a single API response, settled in stablecoins. It is the right tool when an agent buys compute or data per call and the wrong tool when it buys a laptop from Best Buy. If you want the three payment standards side by side rather than the commerce layer, we break them down in AP2 vs ACP vs x402.
What a merchant has to do to accept UCP-powered checkout on Google
Google's Merchant Center documentation is specific about the setup, and it is a short list. Meet the technical requirements in the developer documentation, submit the interest form, add the native_commerce(checkout_eligibility) attribute to your product data, make sure your Merchant Center feed is complete and current, and create a Google Pay and Wallet Console account. We walk through each requirement, the eligibility attribute and the fee question in our UCP checkout setup guide for Google AI Mode and Gemini. Availability at the time of writing is early access, limited to products eligible in the United States, Canada, and Australia, and to participating merchants and partners. It surfaces as a Buy button on product listings inside AI Mode in Search and the Gemini app, paid with credentials the shopper already has in Google Wallet. You stay the seller of record, and Google states merchants may customize the integration to preserve their own checkout requirements. Shopify merchants have a shorter path: Shopify's Checkout Kit implements UCP capabilities for you, which is the practical reason a large share of early UCP volume will come through Shopify stores. What nobody has published is a fee. Google's merchant help page discloses no take rate for UCP-powered checkout, and the protocol itself is free and Apache licensed, so your costs are ordinary payment processing plus whatever engineering the integration takes. Treat any specific UCP commission number you read elsewhere as unverified until Google publishes one. Shopify merchants get the UCP side for free and largely pre-built: every Shopify storefront already publishes a live UCP capability document, which we probed across fourteen US brands in the Shopify agentic commerce guide.
What UCP does not do: the spend-control gap on the buying side
Every one of these standards is written from the merchant's side of the counter. UCP tells your store how to accept an agent order. It says nothing about whether the agent placing that order was supposed to spend $4,000 on cloud credits at 3am. Read the capability list again with a finance hat on: there is no per-agent budget, no approval threshold, no merchant allowlist for the buyer, no way to revoke one agent's ability to transact without breaking the others. That is not an oversight, it is a scope boundary, and it is the same boundary in ACP, AP2, and x402. The controls have to live on the buyer side, in whatever issues the credential the agent presents. Card-level caps from an issuer are the first layer, since an issuer declines at authorization and an agent cannot argue with a decline. Above that you need a policy that spans cards and rails, an approval step for anything unusual, and a record that ties every authorization to a specific agent, a specific task, and the human who authorized the agent. If you are choosing a vendor for that layer, the category map is on our AI agent payment platforms comparison.
Where Agentspay fits
Agentspay is rail-neutral and protocol-neutral by design, which in a market with four competing standards is the useful property. Your agent can check out through UCP at a Google surface, through ACP in ChatGPT, or with a plain card at any US merchant, and the same policy applies before any of it authorizes. Each agent gets a wallet and a hard spend limit that is evaluated before authorization rather than reported afterward, human approval fires above the threshold you set, scoped virtual cards lock spend to specific merchants and single uses, and the policy engine writes an immutable record of who asked, what was approved, and what actually settled. When the next protocol arrives, and it will, the control layer does not need rewriting.