Universal Commerce Protocol (UCP): What Merchants Need in Their Data

The Universal Commerce Protocol (UCP) is an open-source standard that lets AI agents, shopping platforms, retailers and payment providers handle a purchase in one shared format: finding products, building a cart, checking out, linking a shopper's account and tracking the order. Google announced it on January 11, 2026, co-developed with Shopify, Etsy, Wayfair, Target and Walmart and endorsed by more than 20 companies including Visa, Mastercard, Stripe, Adyen, Best Buy and Zalando. Instead of building a separate integration for every AI surface, a business publishes what it supports once and any UCP-capable agent can use it.

Google's first implementation is checkout inside AI Mode in Search and the Gemini app, where the retailer stays the merchant of record. To take part, a merchant needs a Merchant Center account with approved products, return and support settings, a checkout eligibility flag on each product, and clean product data: stable IDs, variants with their options, barcodes, prices, availability and categories. This post covers what UCP is, how it relates to ACP, AP2 and MCP, and exactly which product fields it relies on. Our earlier post on Google's Universal Cart covers the shopper-facing side and the strategic case; this one is the technical and data checklist.

UCP timeline: January announcement to the August 2026 spec

UCP changed quickly in its first nine months. The milestones that matter for merchants:

The protocol is versioned by date, so an agent and a business agree on a version when they connect. Expect your platform or payment provider to handle most of that negotiation for you.

How UCP works: the /.well-known/ucp profile, capabilities and transports

A business publishes a JSON profile at /.well-known/ucp on its own domain. The profile lists the protocol versions it supports, its service endpoints, the capabilities it offers and its payment configuration. An agent reads that file first and then knows what it can do with this store without a hard-coded integration. Google's developer walkthrough shows the full exchange, from reading the profile to applying a discount code at checkout.

• Capabilities are the building blocks: checkout, cart, catalog, identity linking and order management. A business picks the ones it supports.
• Extensions add features to a capability. Discounts, for example, extend checkout and cart.
• Transports: the same capability can be exposed as a REST API, through an MCP binding or through Agent2Agent (A2A). A checkout capability, for example, can have a REST binding or an MCP binding depending on the business's stack.
• Payments separate the instrument (what the shopper pays with, such as Google Pay) from the handler (the processor that takes the payment), so UCP can work with the payment providers merchants already use. UCP is compatible with AP2 for proving that the shopper authorized the purchase.
• Merchant of record: the retailer remains the merchant of record and keeps its own business logic.

For Google's surfaces, a merchant can use native checkout, built on its own checkout API, or an embedded option that keeps a fully customized checkout experience inside the agent.

UCP, ACP, AP2 and MCP: which protocol does what

Four acronyms appear in every agentic commerce article. They work at different layers, and only two of them compete:

ACP and UCP overlap most at checkout: one powers buying inside ChatGPT, the other inside Google's surfaces, and Stripe, which co-developed ACP, said in March 2026 that it would implement UCP too. A merchant does not choose one forever. What both require is the same input: a product catalog that a machine can read without guessing. If your feed works for one, most of the work for the other is already done. Our ecommerce dictionary entry on agentic commerce explains the wider shift.

The product fields a UCP catalog response carries

The UCP catalog capability defines what a product looks like when an agent asks for it. The schemas in the 2026-08-25 release are a practical checklist, because every required field must come from your product data and every optional field is a chance to answer the shopper's question.

Product level. Required: id, title, description, price_range and variants. Optional: handle, canonical url, categories with a taxonomy identifier, list_price_range for strikethrough prices, media (images, video, 3D; the first item is the featured one), options such as Size and Color, rating, tags and business-defined metadata.

Variant level. Required: id, title (such as "Blue / Large"), description and price. Optional: sku, barcodes (with types UPC, EAN, ISBN, GTIN or JAN), list_price, unit_price for per-kilo or per-liter comparison, availability with a status of in_stock, backorder, preorder, out_of_stock or discontinued, the options that define the variant, its own media, categories and seller.

Two details are easy to miss. Descriptions can be sent as plain text, HTML or Markdown, and the spec tells platforms to sanitize HTML, so a clean plain-text description is the safest version to maintain. And categories carry a taxonomy name: google_product_category, shopify or merchant. If your products are already mapped to the Google product taxonomy for Shopping, you can pass that ID straight through.

Worked example: one hiking boot in UCP terms

Take a fictional mid-cut waterproof hiking boot sold in four sizes and two colors. This is what each UCP field needs from the catalog:

• Product id and title: a stable ID that never changes when the product is renamed; title "Trailmark Ridge Mid GTX Hiking Boot, Men's".
• Description: a plain-text version without HTML, stating what the boot is for, the membrane, the sole and the fit.
• Categories: Google product category 187 (Apparel & Accessories > Shoes) with taxonomy google_product_category, plus your own category path with taxonomy merchant.
• Options: Color (Slate, Olive) and Size (EU 42, 43, 44, 45).
• Variants: eight in total, each with its own ID, SKU (TRM-RDG-SLT-43), an EAN barcode of type EAN, price and list_price in EUR, availability status and the Color and Size values. The variant title follows the option values: "Slate / EU 43".
• Media: one featured image per color, then sole and detail shots.
• Metadata: facts the standard fields do not hold, such as membrane, weight per boot in grams and last width, from your attribute set.

Every gap in that list shows up as a weaker answer. A variant without a barcode is harder to match across sellers; a variant without availability status cannot be bought with confidence; a product without options cannot be filtered by size. Check your identifiers with our guide to GTIN, UPC and EAN if barcode types in your catalog are mixed.

Merchant Center settings and feed attributes for checkout on Google

For Google's implementation, the Merchant Center preparation guide lists what must be in place before you build the API side:

1. A Merchant Center account in good standing with products approved for free listings.
2. Return policies with return cost, return window and a link to the full policy, set in the account's returns settings or per product with the returns attribute (return_policy_label restricts a policy to a subset of products). Advanced accounts configure this per sub-account. The policy is shown on the checkout screen.
3. Customer support information set in Merchant Center, used for the Contact Merchant link on the order confirmation page.
4. native_commerce (checkout_eligibility): a true or false value per product. Missing means not eligible, so every product you want to sell through agentic checkout must carry it explicitly.
5. consumer_notice: required for products with regulatory warnings, with a notice_type of legal_disclaimer, safety_warning or prop_65 and a notice_message of up to 1,000 characters.
6. Matching product IDs: the id in your feed must match the ID your checkout API expects; if it does not, the merchant_item_id attribute maps them and takes precedence.

Google recommends sending these attributes through a supplemental data source rather than editing the primary feed, so a formatting mistake does not break regular product ingestion. Some products are ineligible regardless of the flag: subscriptions and installment plans, personalized goods, used, refurbished and final-sale items, pre-orders, products that need freight or other special shipping, age-restricted items, services and rentals. Set native_commerce to false for those.

Our Google Shopping feed guide covers the primary feed attributes that need to be right before any of this applies.

Conversational attributes: question_and_answer and related_product

Alongside UCP, Google announced new optional Merchant Center fields for conversational surfaces such as AI Mode, Gemini and Business Agent. The conversational attributes overview lists six:

• question_and_answer: FAQ pairs about the product. Google notes that you do not need to repeat details already sent in the description, product highlight or product detail attributes.
• related_product: links to accessories, required parts or items often bought together, with sub-attributes relationship_type, identifier_type and identifier.
• document_link: PDFs such as manuals and spec sheets.
• item_group_title and variant_option: a title for the product family and the name and value pairs (Size: 43, Color: Slate) that define each variant, used with item_group_id.
• popularity_rank: how popular a product is, as a percentage ranking within your total inventory.

These fields do not change the approval status of existing products, and they sit naturally next to the UCP data: variant_option mirrors the UCP variant options, related_product mirrors the cross-sell and accessory links many catalogs already keep, and question_and_answer gives an agent the answers it would otherwise try to extract from a marketing paragraph.

Nine catalog fixes to make before UCP checkout reaches your market

Most of the UCP integration work belongs to your platform, developers or payment provider. The data work belongs to whoever owns the catalog, and it can start now:

UCP checkout launched in the US, with Canada and Australia next and the UK later, so merchants in the Netherlands and the rest of Europe have time. That time is best spent on this list, because the same fields also improve Shopping listings, marketplace feeds and AI answers today. If you are deciding what to put in front of AI agents more broadly, our post on llms.txt for ecommerce covers the index-file side and why it matters less than the data.

WISEPIM manages the catalog layer this checklist depends on: AI fills missing attributes, descriptions and Google categories, Quality Guard checks products against channel rules, and the Google Merchant Center connection pushes the result. Teams building their own agent integrations can read product data through the WISEPIM public API on the Pro plan. The agentic commerce feature page shows how the pieces fit.