Universal Commerce Protocol (UCP): wat je productdata nodig heeft

Het Universal Commerce Protocol (UCP) is een open-source standaard waarmee AI-agents, shoppingplatforms, retailers en betaalproviders een aankoop in één gedeeld formaat afhandelen: producten vinden, een winkelwagen vullen, afrekenen, het klantaccount koppelen en de bestelling volgen. Google kondigde het aan op 11 januari 2026, ontwikkeld samen met Shopify, Etsy, Wayfair, Target en Walmart en gesteund door ruim 20 bedrijven, waaronder Visa, Mastercard, Stripe, Adyen, Best Buy en Zalando. In plaats van een aparte koppeling voor elk AI-kanaal publiceert een bedrijf één keer wat het ondersteunt, en elke agent die UCP spreekt kan daarmee aan de slag.

De eerste toepassing van Google is afrekenen in AI Mode in Search en in de Gemini-app, waarbij de retailer de verkopende partij blijft. Om mee te doen heb je een Merchant Center-account met goedgekeurde producten nodig, retour- en supportinstellingen, een vlag voor checkout-geschiktheid op elk product en schone productdata: vaste ID's, varianten met hun opties, barcodes, prijzen, beschikbaarheid en categorieën. Deze blog legt uit wat UCP is, hoe het zich verhoudt tot ACP, AP2 en MCP, en welke productvelden het precies gebruikt. Onze eerdere blog over de Universal Cart van Google behandelt de kant van de shopper en de strategische afweging; deze gaat over techniek en data.

Tijdlijn van UCP: van de aankondiging in januari tot de specificatie van augustus 2026

UCP veranderde snel in de eerste negen maanden. De mijlpalen die voor webshops tellen:

Het protocol krijgt een datum als versienummer, zodat een agent en een webshop bij het verbinden een versie afspreken. Reken erop dat je platform of betaalprovider het meeste van die afstemming voor je doet.

Zo werkt UCP: het profiel op /.well-known/ucp, capabilities en transports

Een webshop publiceert een JSON-profiel op /.well-known/ucp op het eigen domein. Daarin staan de ondersteunde protocolversies, de service-endpoints, de functies die je aanbiedt en je betaalinstellingen. Een agent leest dat bestand eerst en weet dan wat hij met deze winkel kan, zonder vooraf ingebouwde koppeling. De technische uitleg van Google laat het hele verloop zien, van het uitlezen van het profiel tot een kortingscode in de checkout.

• Capabilities zijn de bouwstenen: checkout, winkelwagen, catalogus, accountkoppeling en orderbeheer. Een webshop kiest welke hij ondersteunt.
• Extensions voegen functies toe aan een capability. Kortingen breiden bijvoorbeeld checkout en winkelwagen uit.
• Transports: dezelfde capability kan beschikbaar zijn als REST API, via een MCP-binding of via Agent2Agent (A2A). Een checkout kan bijvoorbeeld een REST- of een MCP-binding hebben, afhankelijk van je techniek.
• Betalingen scheiden het betaalmiddel (waarmee de klant betaalt, zoals Google Pay) van de handler (de partij die de betaling verwerkt), zodat UCP kan werken met de betaalproviders die webshops al gebruiken. UCP werkt samen met AP2 om aan te tonen dat de klant de aankoop heeft goedgekeurd.
• Merchant of record: de retailer blijft de verkopende partij en houdt zijn eigen bedrijfslogica.

Voor de omgevingen van Google kan een webshop kiezen voor native checkout, gebouwd op de eigen checkout-API, of voor een embedded variant die een volledig eigen checkout binnen de agent toont.

UCP, ACP, AP2 en MCP: welk protocol wat doet

Vier afkortingen komen in elk artikel over agentic commerce terug. Ze werken op verschillende lagen, en maar twee ervan zijn concurrenten:

ACP en UCP overlappen vooral bij het afrekenen: het ene maakt kopen in ChatGPT mogelijk, het andere in de omgevingen van Google, en Stripe, dat ACP mede ontwikkelde, zei in maart 2026 dat het ook UCP gaat ondersteunen. Je kiest als webshop niet voorgoed voor één van de twee. Beide vragen dezelfde input: een productcatalogus die een machine kan lezen zonder te gokken. Werkt je feed voor het ene, dan is het meeste werk voor het andere al gedaan. Ons woordenboekartikel over agentic commerce legt de bredere verschuiving uit.

De productvelden in een UCP-catalogusantwoord

De catalogusfunctie van UCP legt vast hoe een product eruitziet als een agent erom vraagt. De schema's in versie 2026-08-25 zijn een bruikbare checklist: elk verplicht veld moet uit je productdata komen, en elk optioneel veld is een kans om de vraag van de klant te beantwoorden.

Productniveau. Verplicht: id, title, description, price_range en variants. Optioneel: handle, canonieke url, categories met een taxonomie-aanduiding, list_price_range voor doorgestreepte prijzen, media (foto's, video, 3D; het eerste item is de hoofdafbeelding), options zoals Maat en Kleur, rating, tags en eigen metadata.

Variantniveau. Verplicht: id, title (bijvoorbeeld "Blauw / Large"), description en price. Optioneel: sku, barcodes (met type UPC, EAN, ISBN, GTIN of JAN), list_price, unit_price voor vergelijking per kilo of liter, availability met de status in_stock, backorder, preorder, out_of_stock of discontinued, de options die de variant bepalen, eigen media, categorieën en verkoper.

Twee details mis je snel. Omschrijvingen kunnen als platte tekst, HTML of Markdown worden meegestuurd, en de specificatie draagt platforms op HTML op te schonen. Een nette omschrijving in platte tekst is dus de veiligste versie om te onderhouden. En categorieën dragen de naam van een taxonomie: google_product_category, shopify of merchant. Heb je je producten al gekoppeld aan de Google-producttaxonomie voor Shopping, dan kun je dat ID direct doorgeven.

Uitgewerkt voorbeeld: één wandelschoen in UCP-velden

Neem een fictieve halfhoge waterdichte wandelschoen in vier maten en twee kleuren. Dit vraagt elk UCP-veld van je catalogus:

• Product-id en titel: een vast ID dat niet verandert als het product een andere naam krijgt; titel "Trailmark Ridge Mid GTX wandelschoen heren".
• Omschrijving: een versie in platte tekst zonder HTML, met waarvoor de schoen is, het membraan, de zool en de pasvorm.
• Categorieën: Google-productcategorie 187 (Kleding en accessoires > Schoenen) met taxonomie google_product_category, plus je eigen categoriepad met taxonomie merchant.
• Opties: Kleur (Slate, Olive) en Maat (EU 42, 43, 44, 45).
• Varianten: acht in totaal, elk met eigen ID, SKU (TRM-RDG-SLT-43), een EAN-barcode van het type EAN, prijs en adviesprijs in EUR, beschikbaarheidsstatus en de waarden voor Kleur en Maat. De varianttitel volgt de optiewaarden: "Slate / EU 43".
• Media: één hoofdafbeelding per kleur, daarna zool- en detailfoto's.
• Metadata: feiten die niet in de standaardvelden passen, zoals membraan, gewicht per schoen in grammen en leestbreedte, uit je attributenset.

Elk gat in die lijst levert een zwakker antwoord op. Een variant zonder barcode is lastiger te matchen tussen verkopers; een variant zonder beschikbaarheidsstatus kan niet met zekerheid gekocht worden; een product zonder opties kan niet op maat gefilterd worden. Controleer je codes met onze gids over GTIN, UPC en EAN als er verschillende barcodetypen door je catalogus lopen.

Merchant Center-instellingen en feedattributen voor afrekenen bij Google

Voor de implementatie van Google noemt de voorbereidingsgids voor Merchant Center wat er klaar moet staan voordat je aan de API-kant begint:

1. Een Merchant Center-account zonder problemen met producten die zijn goedgekeurd voor gratis vermeldingen.
2. Retourbeleid met retourkosten, retourtermijn en een link naar het volledige beleid, ingesteld in de retourinstellingen van het account of per product met het attribuut returns (return_policy_label beperkt een beleid tot een deel van de producten). Geavanceerde accounts stellen dit per subaccount in. Het beleid verschijnt in het afrekenscherm.
3. Klantenservicegegevens in Merchant Center, voor de link Contact Merchant op de orderbevestigingspagina.
4. native_commerce (checkout_eligibility): per product true of false. Ontbreekt de waarde, dan is het product niet geschikt, dus elk product dat je via agentic checkout wilt verkopen moet hem expliciet krijgen.
5. consumer_notice: verplicht voor producten met een wettelijke waarschuwing, met een notice_type legal_disclaimer, safety_warning of prop_65 en een notice_message van maximaal 1.000 tekens.
6. Overeenkomende product-ID's: de id in je feed moet gelijk zijn aan het ID dat je checkout-API verwacht; zo niet, dan koppelt het attribuut merchant_item_id ze en gaat dat voor.

Google raadt aan deze attributen via een aanvullende gegevensbron te sturen in plaats van de primaire feed aan te passen, zodat een opmaakfout de gewone productverwerking niet breekt. Sommige producten zijn hoe dan ook uitgesloten: abonnementen en betalingen in termijnen, gepersonaliseerde producten, gebruikte, refurbished en final-sale-artikelen, pre-orders, producten met vracht- of andere speciale verzending, producten met leeftijdsgrens, diensten en verhuur. Zet native_commerce daarvoor op false.

Onze gids voor Google Shopping-feeds behandelt de attributen van de primaire feed die eerst op orde moeten zijn.

Conversational attributes: question_and_answer en related_product

Naast UCP kondigde Google nieuwe optionele Merchant Center-velden aan voor conversationele omgevingen zoals AI Mode, Gemini en Business Agent. Het overzicht van conversational attributes noemt er zes:

• question_and_answer: vraag-en-antwoordparen over het product. Google merkt op dat je details die je al in de attributen description, product_highlight of product_detail meestuurt niet hoeft te herhalen.
• related_product: verwijzingen naar accessoires, benodigde onderdelen of artikelen die vaak samen gekocht worden, met de subattributen relationship_type, identifier_type en identifier.
• document_link: pdf's zoals handleidingen en specificatiebladen.
• item_group_title en variant_option: een titel voor de productfamilie en de naam-waardeparen (Maat: 43, Kleur: Slate) die elke variant bepalen, samen met item_group_id.
• popularity_rank: hoe populair een product is, als percentage binnen je totale assortiment.

Deze velden veranderen de goedkeuringsstatus van bestaande producten niet, en ze sluiten logisch aan op de UCP-data: variant_option spiegelt de UCP-variantopties, related_product spiegelt de cross-sell- en accessoirekoppelingen die veel catalogi al bijhouden, en question_and_answer geeft een agent de antwoorden die hij anders uit een marketingalinea probeert te halen.

Negen catalogusklussen voordat UCP-checkout jouw markt bereikt

Het meeste integratiewerk voor UCP ligt bij je platform, developers of betaalprovider. Het datawerk ligt bij wie de catalogus beheert, en dat kan nu al beginnen. Voor varianten met expliciete opties helpt onze gids over attribuutmodellering.

UCP-checkout startte in de VS, met Canada en Australië als volgende en het Verenigd Koninkrijk later. Webshops in Nederland en België hebben dus tijd. Die tijd besteed je het best aan deze lijst, want dezelfde velden verbeteren nu al je Shopping-vermeldingen, marktplaatsfeeds en AI-antwoorden. Wil je breder bekijken wat je AI-agents voorschotelt, dan behandelt onze blog over llms.txt voor je webshop de kant van het indexbestand en waarom dat minder zwaar weegt dan de data.

WISEPIM beheert de cataloguslaag waar deze checklist op leunt: AI vult ontbrekende attributen, omschrijvingen en Google-categorieën aan, Quality Guard toetst producten aan kanaalregels en de koppeling met Google Merchant Center zet het resultaat door. De pagina over agentic commerce laat zien hoe de onderdelen samenkomen.