How to set up the Universal Commerce Protocol for your store.Google has to approve the integration before a shopper can buy from you in AI Mode or Gemini.

A shopper in Google’s AI Mode asks for a product, the agent finds it in your catalog, and the purchase happens without the shopper ever loading your site. The Universal Commerce Protocol (UCP) lets the agent do that, and it works only when your store answers correctly at the moment the agent asks. What does your store have to publish? Which products can an agent buy? What does Google check before it lets you go live? In the UCP work we’ve done, the product page has known more than the feed every time, and an endpoint built from the feed alone would give agents less to work with than a shopper sees on the page.

UCP is an open standard, and your store publishes what it supports

UCP was co-developed by Google with Shopify, Etsy, Wayfair, Target and Walmart, and its specification lives at ucp.dev. Your store is the merchant of record: you keep the customer, the order and the payment liability, and the agent acts on the shopper’s behalf.

Everything starts with a profile your store publishes at /.well-known/ucp. It names the protocol version, the services you offer and how to reach them, your payment handlers, and the public keys an agent uses to verify your signed messages. An agent reads it before it does anything else.

UCP versions are dates. The latest specification as of October 2026 is 2026-08-25, and Google’s implementation guides use 2026-04-08. A store can serve REST, MCP, A2A or an embedded checkout, and REST is the core one.

Step 1: Fix the product data that’s wrong

Google reads a feed on a schedule, but an agent calls a UCP endpoint in real time, so whatever is wrong in your data reaches the shopper at the point of purchase, with nobody there to catch it. We fix wrong data before we add anything, and these fixes pay off in Merchant Center whether or not UCP ever ships.

Keep GTINs as text from end to end. A system that treats them as numbers strips the leading zeros, and the GTIN stops matching. Check each one against the manufacturer’s GS1 record rather than padding it until it fits.

Step 2: Add the data an agent needs to finish a purchase

Product pages usually carry more than the feed does: the full image gallery, the brand, ratings, the real list price and delivery terms. An agent only sees what you send it.

• Long-form descriptions. Put the product’s main difference first, because an agent may quote only the opening. State constraints plainly, such as weight limits, power needs and where it can ship, and give measurements in both unit systems.
• Separate variants. A parent product with sizes or colors flattened into one row needs to become one row per variant, grouped with item_group_id.
• Shipping, returns and warranty as data, not only as paragraphs on a policy page.
• Every image the page shows. A feed that carries only the first leaves the agent with less than the shopper sees.
• Live stock levels instead of an in-stock or out-of-stock flag. Google requires a live inventory check at checkout, and an out_of_stock error when the item has sold out.

Merchant Center caps a description at 5,000 characters and doesn’t want promotional details such as prices or shipping offers in it, while a UCP description can carry delivery, warranty and constraints. Write the complete version for UCP and strip it down for the feed.

Prices in UCP are whole numbers in the currency’s smallest unit, so $129.99 is sent as 12999. Getting the unit wrong misprices the product by a factor of a hundred, in either direction, so check it before anything goes live.

Step 3: Decide which products an agent can buy

Google’s Merchant Center guidance excludes whole categories from agent checkout, among them:

• subscriptions and installment or financing plans;
• personalized goods, refurbished, used and final-sale items, and pre-orders;
• bundled services such as installation or extended warranties, freight and premium delivery, and in-store activation;
• age-restricted and prohibited products, services, rentals and virtual items.

Leave those out, and opt in the rest product by product.

A high-priced product that many shoppers buy on a financing plan may sell worse through a wallet checkout that doesn’t offer the plan. Measure how many orders for that product use financing before you switch agent checkout on for it. A store can also publish its catalog to agents and keep checkout on its own site, which is a legitimate UCP configuration and often the right first stage.

Step 4: Prepare Merchant Center

Google’s implementation guide starts with Merchant Center: the account has to be in good standing, with products approved for free listings.

• Return policy. Set the return cost, the return window and a link to the full policy, at account level or per product with the returns attribute. Google shows it on the checkout screen.
• Customer support. Add at least one contact method: a support page, an email address or a phone number. It powers the “Contact Merchant” link on the order confirmation.
• Opt products in. Set native_commerce(checkout_eligibility) to TRUE for each eligible product. Google recommends a supplemental data source, so the opt-in doesn’t disturb your main feed.
• Regulatory notices. Products that carry a legal disclaimer, a safety warning or a Proposition 65 warning need a consumer_notice, with its type and a message of up to 1,000 characters.
• Matching IDs. The feed’s id has to match the product ID your checkout expects. Where they differ, send merchant_item_id.

Step 5: Join Google’s waitlist

Google says an integration “must be approved by Google before you can go live” in AI Mode and Gemini. The way in is the UCP integration interest form in Merchant Center Help, which puts your store on the waitlist. Embedded checkout, where your own checkout runs inside Google’s surface, is limited to approved merchants. Submit the form while you build, since approval is the step you can’t speed up yourself.

Step 6: Build the profile and the endpoints

A store either uses UCP support built into its commerce platform or builds it. Where we build, we put a thin service in front of the store that speaks UCP to agents and the platform’s own API to the store, mounted under the store’s domain so the profile and the endpoints share one origin. UCP is revised often, and keeping it out of the platform means a new version doesn’t wait on a platform release.

• Publish only what works. An agent that finds checkout in your profile will try to use it. A first release can advertise catalog search and lookup alone, and add checkout when it’s ready.
• Use real signing keys. The profile’s public keys verify your signed order updates, so generate a key pair and keep the private half on the server.
• Make retries safe. Accept an idempotency key on checkout calls, so a repeated request doesn’t charge twice.
• Serve it over HTTPS. The REST specification requires TLS 1.3 at minimum.
• Validate addresses. Return an undeliverable address as a recoverable error, so the shopper can fix it instead of hitting a dead end.
• Link your policies. Your terms apply to every UCP purchase, so include links to your privacy, terms, refund and shipping policies in the checkout response.

Step 7: Connect payments

On Google’s native checkout path, your profile declares the Google Pay payment handler. You don’t need the Google Pay API on your own site, but your payment processor must accept Google’s payment tokens, and most major processors do. Google’s FAQ notes that its AI surfaces only use the PAN_ONLY authorization method and that Google Pay settings in the profile use snake_case names. Keep test and production processor credentials separate, and never log them.

Step 8: Test the way Google will

Google sends health checks with the user agent Google-UCP-Prober/1.0, and marks agent requests with a UCP-Agent header and a user agent beginning with Google/UCP. Before you apply, request your own endpoints as Google would.

• Does /.well-known/ucp reach your store? A web server rule can answer that path with its own 404 before the request ever reaches the application, even while your UCP endpoints work.
• Does your firewall let Google in? Bot protection that blocks scripted traffic will block the prober too, so allow Google’s UCP requests through by their headers rather than by address.
• Do protected endpoints behave? Checkout, payment and order endpoints should refuse requests without credentials and accept Google’s.

Step 9: Plan for the next UCP version

The 2026-08-25 specification adds standard return and warranty policies that 2026-04-08 doesn’t have, and Google documents 2026-04-08. Until Google’s guides adopt a newer version, your Merchant Center return policy carries that information. When you adopt a new version, Google recommends serving it from a separate endpoint, so it can send traffic back to the old one if something breaks.

WISLR sets up UCP for brands and for agencies’ clients

Every step above is part of WISLR’s Agentic Commerce Optimization service. We audit the catalog against Google’s requirements, fix and complete the product data, prepare Merchant Center and the opt-in feed, and build and test the UCP profile and endpoints until the integration is ready for Google’s approval. Brands bring us in directly, and agencies bring us in under their own name to set it up for their clients. See how we set up UCP and request an assessment of your catalog.