Universal Commerce Protocol: does it work for marketplaces?

Google and Shopify are pushing one protocol for AI agents that shop: the Universal Commerce Protocol, UCP. In nine months it has gone from a trade-show announcement to a cart inside Google Search and a setting that is on by default in the Shopify admin. It is built for one merchant at a time, and a marketplace is not one merchant. This post covers what UCP is, what it changes, how to get a marketplace ready, and why we built the Universal Marketplace Protocol, UMP, as a layer on top of it.

What UCP is

UCP is an open standard, published under the Apache 2.0 licence, for the conversation between a shopping agent and a business. Google and Shopify announced it on 11 January 2026, with Etsy, Wayfair, Target and Walmart as co-developers and more than twenty retailers and platforms backing it at launch.

It works like this. A business publishes a profile at one fixed address on its domain, /.well-known/ucp. The profile lists what the business can do as named, versioned capabilities: a checkout, an order, a cart, a catalog, and extensions for discounts, fulfilment, loyalty and buyer consent. An agent reads the profile, keeps the capabilities both sides share, and buys through them. The specification calls this permissionless onboarding: any platform with a profile of its own can trade with any business, with no registration first.

The protocol has had four releases this year, the latest on 25 August, and it has grown technical councils for food, lodging and payments. Shopify storefronts have advertised the August version since 4 September.

What it changes

Two things change, and one does not.

The checkout moves. On 15 October Google launched Universal Cart in the United States. A shopper gathers items from several retailers in Search or the Gemini app, then pays with Google Pay or sends the items to the retailer’s own cart. Google says the retailer stays the seller of record either way. For Shopify stores in the United States that qualify, direct checkout in Google’s AI Mode and Gemini is on by default. A merchant has to switch it off, and one who does is still listed, with buyers sent to the store to pay.

The integration work changes hands. Before UCP, selling through an assistant meant an integration per assistant. With UCP, a business publishes one profile and every agent that speaks the protocol can find it and buy. That is why Google could announce checkout inside Shopping ads on YouTube in May, and why Shopify can switch it on for a whole platform at once.

What does not change is the data. An agent buys what it can read. A listing with a photo and a price but no return window, no shipping countries and no answer to “can a seven-year-old come” gets passed over for one that answers. The protocol moves the checkout. It does not fill in your catalog.

Getting ready

For a single store the list is short, and most of it is good hygiene:

• A profile at /.well-known/ucp, or a redirect from your domain to whoever hosts it for you.
• Structured data on product pages. Agents and crawlers read Schema.org product markup: name, price, currency, availability, seller.
• A robots.txt that lets agents in, and keeps them out of your cart and checkout, which they should not crawl.
• A place to land when an agent cannot finish on its own: a promo code that needs review, a payment that needs 3-D Secure. UCP hands the buyer to a URL you choose.
• Facts in the catalog, not in brochures. Minimum ages, what is included, what happens if it rains. If it is not a field an agent can read, it does not exist.

Our guide walks a Traide marketplace through each of these, with the snippets.

Where UCP stops

UCP’s model is one business, one profile, one checkout, one order. The August release added split payments, but across payment instruments, not across merchants, and marketplaces do not appear in its release notes. Universal Cart gathers items from several retailers, but each retailer is a separate seller of record with a separate checkout behind it. The other common agent checkout, Stripe’s shared payment token, is scoped to one merchant and one cart total.

A marketplace breaks that model in a way the protocol cannot see. One checkout holds items from several independent sellers. Each seller has its own shipping methods, its own return policy, its own stock, and is paid separately. The buyer places one order and pays once. The marketplace splits it into an order per seller, and each ships and settles on its own.

So does it work for a marketplace? Partly. Put a marketplace behind plain UCP and it looks like a single merchant. That works, as far as it goes: the agent can buy. What it cannot do is tell the shopper which seller ships which item, choose a shipping method per seller, see that two of three parcels have shipped, or tell a marketplace policy from a seller’s. The things a marketplace buyer asks about are exactly the things the protocol has no words for.

UMP, the Universal Marketplace Protocol: a layer on top of UCP

So in the week UCP was announced we drafted the Universal Marketplace Protocol, UMP, and built it into our API beside UCP. UMP is not a rival to UCP and not a replacement for it. It is a layer on top: it extends UCP the way UCP’s own extensions do, with new capabilities that build on the base ones, under a namespace of their own.

• Sellers (dev.ump.seller). An agent can list a marketplace’s sellers, read a seller’s profile, rating, shipping countries and policies, and page through its products with their variants, prices, stock and the attributes a buyer asks about.
• Split checkout (dev.ump.checkout.split). The checkout answer groups lines by seller, with a subtotal and a choice of shipping methods per seller, under one total and one payment.
• Split order (dev.ump.order.split). One marketplace order with a seller order inside it for each seller, each with its own status, tracking and events.
• Seller fulfilment (dev.ump.fulfillment.seller). Per-seller shipping, and more than one shipment per order.
• Marketplace (dev.ump.marketplace). Who the operator is, what buyer protection applies, and how a dispute is raised.

It is backwards compatible by design. An agent that speaks only UCP gets a UCP answer, with the marketplace as one merchant. An agent that asks for UMP, with one request header, gets the split. Nothing breaks for anyone who has never heard of UMP.

We ran it end to end this month, in a demo of a cooperative of tour operators. A family asked their assistant for a food tour, something active after lunch and a sunset sail on Saturday, kid-friendly and under $300. The assistant read the three operators’ catalogs through the protocol, planned the day from the facts they had published, and booked all three in one UCP checkout. One payment, three operator orders, a ticket for every seat, and the seats dropped on each operator’s own manifest. A departure cannot be oversold through it: the API refuses the booking at completion.

What isn’t done yet

• UMP is a draft we wrote. No standards body has adopted it, and its namespace needs a public home before agents outside our own can rely on it, because UCP checks that a capability’s name and its specification come from the same place.
• Our UCP implementation is pinned to the January release. The August release, with 3-D Secure, buyer consent, policies and fractional quantities, is tracked and not yet adopted.
• The agent-facing host is switched on marketplace by marketplace, so not every Traide marketplace answers at its own address yet.

What this means for you

If you run a marketplace, agents will arrive speaking UCP, and the question will not be whether they can buy. It will be whether they can see your sellers, and whether your catalog answers the questions their users ask. If you sell through marketplaces, ask yours what an agent sees of you. And if you are building a marketplace and want it to carry a multi-vendor order through an agent, that is the conversation we want to have. Talk to us.