Universal Commerce Protocol (UCP) einfach erklärt

Google hat UCP am 11. Januar 2026 auf der Handelsmesse NRF in New York vorgestellt, gemeinsam entwickelt mit Shopify, Etsy, Wayfair, Target und Walmart und zum Start unterstützt von mehr als 20 weiteren Unternehmen wie Adyen, American Express, Mastercard, Stripe, Visa und Zalando. Inzwischen führt die offizielle Seite ucp.dev im Bereich Shopping außerdem Amazon, Microsoft, Meta und Salesforce als Mitentwickler. Neben dem Einzelhandel wächst UCP in weitere Branchen: Für Unterkünfte gibt es einen Entwurf, Essensbestellung ist angekündigt.

Die Spezifikation liegt quelloffen unter der Apache-2.0-Lizenz auf GitHub. Neue Versionen gibt ein Gremium frei, das die Spezifikation „Tech Council“ nennt. Wenn du zuerst verstehen willst, warum Agenten überhaupt einkaufen und welche anderen Standards es gibt, lies vorher Agentic Commerce: Wenn KI-Agenten einkaufen.

Alles beginnt mit einer einzigen Adresse. Ein Shop veröffentlicht sein Profil als JSON-Datei unter /.well-known/ucp auf seiner Domain, also etwa https://dein-shop.de/.well-known/ucp. Ein Agent, der wissen will, ob und wie er bei dir einkaufen kann, ruft genau diese Datei ab.

Das Profil enthält laut Spezifikation ein Objekt „ucp“ mit der Protokollversion, den angebotenen Diensten, den Fähigkeiten und den Zahlungswegen („payment_handlers“). Dazu kann eine Liste öffentlicher Schlüssel kommen, mit denen der Agent Signaturen des Shops prüfen kann.

Auch die Gegenseite hat ein Profil. Ein Agent, die Spezifikation spricht von „Plattform“, muss bei jeder Anfrage mitteilen, wo sein eigenes Profil liegt. Über HTTP geschieht das im Header „UCP-Agent“. So weiß der Shop, mit wem er spricht und was dieser Agent kann.

UCP ist in drei Ebenen gegliedert. Die Namen folgen einem umgekehrten Domain-Schema, ähnlich wie Java-Pakete.

• Dienste beschreiben eine Schnittstelle für eine Branche, zum Beispiel „dev.ucp.shopping“ für den Einkauf. Jeder Eintrag nennt eine Version und einen Transportweg.
• Fähigkeiten sind die eigentlichen Funktionen innerhalb eines Dienstes. Die Spezifikation nennt unter anderem Katalogsuche und Produktabfrage, Warenkorb („dev.ucp.shopping.cart“), Kasse („dev.ucp.shopping.checkout“), Bestellung („dev.ucp.shopping.order“) und die Verknüpfung von Kundenkonten per OAuth 2.0 („dev.ucp.common.identity_linking“).
• Erweiterungen ergänzen eine bestehende Fähigkeit. Die Fulfillment-Erweiterung bringt Versandarten, Lieferadressen und Abholung in die Kasse, die Discount-Erweiterung Rabattcodes in Kasse und Warenkorb. Mit dem Release 2026-08-25 kamen unter anderem Standorte mit Öffnungszeiten, Mengen in Bruchteilen (etwa Ware nach Gewicht), Teil- und Ratenzahlungen sowie eine Treueprogramm-Erweiterung hinzu.

Der Namensraum „dev.ucp.*“ ist dem Gremium hinter UCP vorbehalten. Eigene Erweiterungen veröffentlichen Anbieter unter ihrer eigenen Domain, etwa „com.example.installments“. Wer einen Namen nutzt, muss auch die Domain kontrollieren, unter der das zugehörige Schema liegt.

Damit unterschiedliche Agenten mit demselben Shop sprechen können, trennt UCP Inhalt und Transport. Die Spezifikation definiert vier Anbindungen:

• REST mit OpenAPI-Beschreibung, der Kerntransport.
• MCP (Model Context Protocol), über das KI-Modelle Werkzeuge aufrufen.
• A2A (Agent2Agent), bei dem der Shop selbst als Agent mit einer „Agent Card“ auftritt.
• Embedded, bei dem die Kasse des Händlers eingebettet in der Oberfläche des Agenten läuft.

Die Transportbeschreibungen verweisen nur auf gemeinsame Schemas, die Datenfelder sind überall gleich. Ein Warenkorb sieht über REST also genauso aus wie über MCP.

Welche Fähigkeiten in einem Gespräch tatsächlich gelten, wird ausgehandelt. Der Shop bildet die Schnittmenge aus seinem Profil und dem des Agenten: Erstens bleiben nur Fähigkeiten, die beide Seiten unter gleichem Namen anbieten. Zweitens wird je Fähigkeit die neueste Version gewählt, die beide kennen, gibt es keine gemeinsame, fällt sie weg. Drittens werden Erweiterungen entfernt, deren übergeordnete Fähigkeit nicht mehr dabei ist. In jeder Antwort nennt der Shop dann Version und aktive Fähigkeiten. Passt gar nichts zusammen, meldet er das als Fehler im Antwortinhalt und kann eine Webadresse mitgeben, unter der der Kunde normal im Shop weiterkaufen kann.

Eine Kasse ist in UCP ein gespeicherter Vorgang mit einem klaren Status. Die Spezifikation kennt „incomplete“ (es fehlen Angaben), „requires_escalation“ (ein Mensch muss etwas prüfen oder eingeben), „ready_for_complete“ (alles da, Abschluss möglich), „complete_in_progress“, „completed“ (Bestellung angelegt) und „canceled“.

Wichtig ist „requires_escalation“: Kann der Agent etwas nicht selbst erledigen, zum Beispiel eine Zahlungsfreigabe, muss der Shop eine „continue_url“ liefern, unter der der Käufer den Vorgang im Browser fortsetzt. Außerdem gilt: Der Händler bleibt Verkäufer, seine Summen sind maßgeblich, und der Agent darf Positionspreise nicht selbst neu berechnen. Gegen Doppelbestellungen sieht UCP Idempotenzschlüssel vor.

Bezahlt wird über Payment Handler. Das sind im Profil angemeldete Zahlungswege mit eigener Spezifikation, in den Beispielen der Spezifikation etwa Google Pay oder Shop Pay. So kann ein Käufer seinen bevorzugten Anbieter nutzen, ohne dass Agent oder Shop die Kartendaten selbst verarbeiten müssen.

Soll ein Agent eigenständig bezahlen, kommt AP2 ins Spiel, das Agent Payments Protocol von Google. Der Shop signiert den Stand der Kasse, der Agent erzeugt nach Zustimmung des Käufers zwei Nachweise: ein „CheckoutMandate“, das an genau diesen Kassenstand gebunden ist, und ein „PaymentMandate“ für die Zahlungsfreigabe. Der Shop prüft das eine, der Zahlungsdienstleister das andere. Weil das Mandat an den Kassenstand gebunden ist, lässt sich der Betrag nachträglich nicht unbemerkt ändern.

Nach dem Kauf will der Käufer wissen, wo sein Paket ist, und der Agent soll es ihm sagen können. Dafür gibt es die Fähigkeit Bestellung. Eine Bestellung enthält Positionen mit bestellter und gelieferter Menge, Liefererwartungen, ein fortlaufendes Protokoll der Sendungsereignisse mit Sendungsnummer und Versanddienstleister sowie nachträgliche Anpassungen wie Erstattungen.

Änderungen schickt der Shop aktiv per Webhook an eine Adresse, die der Agent in seinem Profil angibt. Jede Nachricht enthält die vollständige Bestellung, nicht nur die Änderung. Die Spezifikation verlangt, dass diese Nachrichten nach RFC 9421 signiert sind und der Agent die Signatur prüft. Schlägt eine Zustellung fehl, muss der Shop es erneut versuchen.

UCP-Versionen heißen nicht 1.0 oder 2.0, sondern tragen ein Datum im Format JJJJ-MM-TT. Auf GitHub veröffentlicht sind bisher die Releases 2026-01-11, 2026-01-23, 2026-04-08 und 2026-08-25. Die Protokollversion wählt der Agent aus den Versionen, die der Shop anbietet, ältere unterstützte Versionen kann der Shop zusätzlich nennen. Fähigkeiten haben eigene Versionen und werden über die beschriebene Schnittmenge ausgehandelt.

Für dich heißt das: Ein Agent und ein Shop müssen nicht gleichzeitig aktualisieren. Solange es eine gemeinsame Version gibt, funktioniert der Austausch. Wann ein Shop alte Versionen abschaltet, entscheidet er selbst.

Jeder rocc-Shop liefert automatisch ein UCP-Profil unter /.well-known/ucp aus, auf der rocc-Adresse und auf deiner eigenen Domain. Katalog, Warenkorb, Kasse und Bestellung laufen nach UCP-Release 2026-08-25. Preise und Bestand prüft rocc serverseitig, ein Agent schickt nur Produkt und Menge. Bezahlt wird derzeit über eine Übergabe an die Shop-Kasse mit Stripe, das Geld geht direkt an dein Stripe-Konto. Bezahlen direkt im Agenten sowie der Transport über MCP und A2A sind in Vorbereitung.

Alle Endpunkte und eine Live-Abfrage findest du auf UCP bei rocc. Wie Agenten in ChatGPT an deinen Shop kommen, steht in In ChatGPT verkaufen und Onlineshop mit ChatGPT verbinden. Weiter geht es mit dem KI-Assistenten, den Funktionen und den Preisen.