Google's Universal Commerce Protocol, Explained: What It Means for Merchants and Their Payment Stack

Agentic commerce is moving from concept to plumbing. In the last eighteen months,  a new layer of protocols has emerged to govern how AI assistants discover, negotiate, and transact on behalf of users. Anthropic's Model Context Protocol (MCP) established the broader integration layer — connecting AI systems to external tools and data sources.

On top of that foundation, Google has introduced two commerce-specific standards: Agent Payments Protocol (AP2), focused on delegated payment mandates, and Universal Commerce Protocol (UCP), a broader specification that sits above payments and covers the entire merchant-to-AI-platform interaction. UCP was co-developed with Shopify and launched in January 2026, already backed by a coalition of 20+ retailers and platforms. 

If your store sells through Shopify, WooCommerce, Magento, or a custom stack today, the question is no longer whether customers will discover and buy your products through Gemini, Google AI Mode, or potentially other AI platforms. It's how — and what that means for your checkout, your tokens, your PSP, and your liability as merchant of record.

This post breaks down UCP from a payments perspective. What it solves, how the flow actually works, where the payment service provider fits, and what a European merchant should be thinking about as the standard rolls out.

Table of content

• The N×N problem UCP is trying to solve
• The actors
• How a UCP transaction actually works
• The variations that matter
• Six things to internalize
• What this means if you're a European merchant
• Where MONEI fits

The N×N problem UCP is trying to solve

Without a shared protocol, every merchant who wants to sell through every AI platform has to build a separate integration with each one. Three platforms means three integrations, each with its own spec, each with its own product-feed format, cart structure, checkout API, and payment surface. Five platforms means five. The work compounds, the maintenance burden compounds, and small merchants get priced out entirely.

UCP is a common agentic commerce language, co-developed by Google and Shopify. One spec, published openly, that any AI platform and any merchant can adopt. A merchant who exposes a UCP-compliant endpoint can be discovered and transacted with by every UCP-compliant platform — without bespoke work for each.

Importantly, the traffic does not route through Google. UCP is a specification, not a marketplace. Communication happens directly between the AI platform and the merchant. Google publishes the standard; the participants own the connection.

Source: Google  

The actors

Four entities show up in a UCP transaction:

• The platform. The AI-powered interface where the buyer is interacting — a chat assistant, an agent, a voice surface.
• The business. The merchant. (UCP uses business throughout; we'll follow that convention.)
• The credentials provider. The party that holds and tokenizes payment credentials — Google Pay, Apple Pay, PayPal, or the equivalent.
• The payment service provider (PSP). The acquirer-facing party that processes the resulting payment token. This is where MONEI sits.

A clean separation of concerns. The AI platform handles discovery and conversation. The business handles catalog, inventory, fulfillment, and merchant-of-record obligations. The credentials provider handles tokenization and authentication. The PSP handles processing, acquiring, and settlement.

How a UCP transaction actually works

Source: Google. Example Query: "Find a light-weight suitcase for an upcoming trip."

Step 1: Profiles published in advance

Both the platform and the business publish a UCP profile — a structured document declaring which version of UCP they support, which services (REST API, MCP, etc.) they speak, which capabilities they offer (catalog, cart, checkout, orders, identity linking), and — critical for payments — which payment handlers they support (Google Pay, Apple Pay, raw card, saved cards, AP2 mandates, and so on).

The business hosts its profile at a UCP-defined web address on its own servers. The platform does the same.

Step 2: Capability negotiation

When a platform wants to engage with a business, it fetches the business's profile, sends its own profile back, and the two compute the intersection of jointly supported services and capabilities. The platform then picks which service to use from that intersection.

This negotiation can happen in advance and be cached. Platforms don't need to wait for a user's intent to look up business profiles — they can pre-negotiate with thousands of merchants and have the connection warm by the time a user asks "find me a vegan pizza near Plaça de Catalunya."

Step 3: Product discovery

Once a service and capabilities are agreed, the platform can call the business's catalog endpoints. Two patterns:

• Search — the platform sends a query ("pizza") and the business returns matching products with metadata, IDs, SKUs, variants, prices, and links.
• Lookup — the platform already knows specific product IDs (single or batch) and fetches their details.

The business responds with structured product data the platform can render in its own UI.

Step 4: Checkout session

When the user confirms intent to buy, the platform sends a checkout-session request to the business. This call carries the line items, billing address, and shipping address.

The business validates everything (availability, pricing, address support), generates a checkout ID, and responds with:

• The checkout ID
• Expiry and a fallback checkout link
• The list of supported payment handlers for this specific checkout, plus their merchant-specific configuration

It's that last piece that matters most for payments. The business is telling the platform, "for this transaction, I accept Google Pay configured against my account ID X, with these card networks and these issuer-country constraints." The merchant's payment surface is being projected into the platform's UI in a structured, controllable way.

Step 5: Payment authorization

The platform shows the user only the payment options that meet the business's constraints. The user picks one — say Google Pay.

Google Pay (the credentials provider) authenticates the user, generates a business-specific payment token based on the merchant's configuration, and hands that token to the platform. The platform never sees the raw PAN. The token is bound to that merchant; it cannot be replayed against a different one.

Step 6: Checkout completion

The platform sends a final checkout request to the business with the payment token, the checkout ID, and any other required details. The business hands the token to its PSP. The PSP processes the payment — running any required checks against the credentials provider — and returns a result to the business, which in turn returns fulfillment details to the platform.

The order capability (which we won't go deep on here) then handles tracking links, delivery status, and post-purchase events.

The variations that matter

UCP isn't one payment flow — it's a shell that accommodates several, each appropriate for a different scenario.

Raw card entry. When the user wants to enter a new card, the credentials provider's PCI-compliant iframe is rendered inside the platform's interface. The platform never touches PAN data. The iframe produces a token usable downstream by the business and its PSP.

Saved card at the merchant. If the user already has cards on file with the business, no retokenization is needed. The platform displays the user's saved cards at that merchant; the user picks one; the platform passes a reference (a payment-method ID), not a fresh token. This requires UCP's identity-linking capability — the platform has to be able to recognize the user as a known account at the business.

Google Pay. At launch, UCP's checkout flow uses standard funding PANs stored in Google Wallet. Additional payment forms — including Apple Pay and PayPal — are part of the broader spec but may not be fully live across all integrations yet.

Delegated agentic purchases (AP2). When the user authorizes the AI to buy on their behalf under specific conditions, those conditions are captured as a payment mandate signed at authorization time. When the conditions are later met, the platform requests a token from the credentials provider, which generates a mandate-bound, merchant-compliant token. This is where Google's AP2 protocol lives — it's UCP's recommended (but not required) payment-protocol for delegated scenarios.

Six things to internalize

1. Each payment method defines its own spec inside UCP. UCP standardizes the shell — the profiles, the negotiation, the checkout envelope — but the rules of how a Google Pay token or an Apple Pay token or an AP2 mandate behaves are still defined by the relevant authority. UCP doesn't replace payment-method standards; it harmonizes how they're advertised and consumed.
2. UCP solves the N×N problem at the payments layer too. By keeping payment architecture decoupled, UCP lets new payment methods plug in without each platform-merchant pair re-integrating.
3. UCP is payment-protocol agnostic. Google promotes AP2 for delegated-shopping scenarios, but UCP works with other agentic-payment protocols. A business can support whatever payment surface it wants, provided it's exposed in the profile.
4. The business stays merchant of record. This is the single most important sentence in the whole spec for a regulated PSP-merchant relationship. The AI platform does not absorb merchant-of-record obligations. PCI scope, refunds, chargebacks, dispute liability, AML obligations — all stay where they were. UCP is plumbing, not a marketplace flip.
5. Escalations stay on the merchant's domain. When 3D Secure, SCA, or KYC is required, the user is handed off via a web view to whatever URL the business provides. PSD2-grade strong customer authentication continues to live where it always did.
6. Discovery is not in scope. Each AI platform decides how it ranks, recommends, or presents products. UCP defines the communication language between platform and business — not the AI's editorial logic.

What this means if you're a European merchant

Three things to plan for.

• Your PSP needs to operate inside this model. When the business hands the payment token to its processor, that processor needs to accept tokens from the credentials providers your customers actually use — Google Pay, Apple Pay, raw card via PCI iframe, and increasingly AP2-style mandates. If your PSP isn't on track to support agentic-commerce flows natively, that's a roadmap question to ask now, not in 2027.
• Your checkout configuration needs to be expressive. UCP profiles carry constraints — accepted card networks, issuer-country rules, supported payment methods per region. If your current PSP doesn't let you configure checkout granularly per channel, you'll struggle to project a clean payment surface into AI platforms.
• SCA, refunds, and disputes don't go away. They get more interesting. A delegated AP2 purchase where the user pre-authorized a mandate four days ago isn't the same evidentiary record as a user-present checkout. If a chargeback arrives, the mandate, the conditions, and the platform-side audit trail all become part of representment. PSPs and merchants need to think now about how that evidence is captured and stored.

Where MONEI fits

MONEI's bet is that European merchants will need a payment layer that is fluent in every agentic protocol that matters — UCP, MCP, AP2, and whatever comes next — without exporting their merchant-of-record status, their PCI compliance, or their regulatory standing to the AI platform.

We've already shipped a public MCP Server that lets AI assistants interact with MONEI accounts directly, and we run a parallel research track on the Machine Payments Protocol — the broader question of how machine-to-machine commerce gets settled inside Europe's regulatory perimeter. UCP slots into that thesis cleanly: it's the merchant-platform language, MCP and AP2 are payment-side standards, and a PSP licensed by the Banco de España is what makes the resulting transaction legal, settled, and SCA-compliant under PSD2.

Agentic commerce is going to be a multi-protocol world. The merchants who win are the ones whose payment stack is ready for that on day one — not the ones still building bespoke integrations when the third major protocol launches.

If you want to talk through what your roadmap should look like, we're here.

Alex Saiz Verdaguer

Alex Saiz Verdaguer is the founder and CEO of MONEI. When he’s not developing partnerships, overseeing product development, and thinking up new ways to innovate payments, you can find him skiing, spending time with his daughter, or working on his next artistic project.