Agentic-Commerce-Protokolle: ACP, AP2 und UCP und was Ihr Katalog braucht

TL;DR

• Die drei offenen Agentic-Commerce-Protokolle, die im Oktober 2026 zählen, sind ACP (OpenAI und Stripe), UCP (Google und Handelspartner) und AP2 (von Google entwickelt, heute bei der FIDO Alliance). Sie decken verschiedene Ebenen desselben Kaufs ab.
• ACP und UCP standardisieren den Produktkatalog und den Checkout zwischen Agent und Händler. AP2 standardisiert den signierten Nachweis, dass ein Nutzer einen bestimmten Kauf und eine bestimmte Zahlung autorisiert hat. Visa und Mastercard betreiben eigene Programme zur Verifizierung von Agenten und Zahlungsdaten.
• Alle drei akzeptieren eine GTIN in den Produktdaten, aber keines verlangt sie, und keines erwähnt GS1 Digital Link. Der Checkout läuft über die eigenen Artikel-IDs des Händlers, und genau dort kann die Produktidentität verrutschen.

Agentic-Commerce-Protokolle sind die offenen Spezifikationen, mit denen ein KI-Agent im Auftrag eines Menschen ein Produkt finden, in einen Warenkorb legen und bezahlen kann, ohne eine Website auszulesen. Stand Oktober 2026 tragen drei davon den größten Teil der Branche: das Agentic Commerce Protocol (ACP), das Universal Commerce Protocol (UCP) und das Agent Payments Protocol (AP2). Sie funktionieren als Ebenen: ACP und UCP beschreiben, wie ein Agent mit einem Händler über Produkte, Warenkörbe und Bestellungen kommuniziert, und AP2 beschreibt, wie alle Beteiligten im Nachhinein nachweisen können, was der Nutzer tatsächlich autorisiert hat.

Für eine Marke oder einen Einführer ist die praktische Frage enger. Egal welches Protokoll ein Agent nutzt, er stellt Ihrem Katalog dieselben Fragen: Was ist dieser Artikel, was kostet er, kann ich ihn kaufen, und welche ID übergebe ich an den Checkout? Dieser Leitfaden zeigt, wem welches Protokoll gehört, was es standardisiert, was ein Händler bereitstellen muss und wo die Produktidentität ins Spiel kommt, Stand Oktober 2026.

Welche Agentic-Commerce-Protokolle gibt es, und wann sind sie gestartet?

Was ist das Agentic Commerce Protocol (ACP)?

ACP ist eine offene Spezifikation für den Handel zwischen Käufern, ihren KI-Agenten und Unternehmen. OpenAI und Stripe haben sie am 29. September 2025 zusammen mit Instant Checkout in ChatGPT unter der Apache-2.0-Lizenz veröffentlicht. Das offizielle Repository beschreibt sie als Beta, gepflegt von OpenAI und Stripe als Gründungs-Maintainern; seit April 2026 führt die Maintainer-Datei außerdem Meta als Lead-Maintainer. Die neueste stabile Version ist 2026-04-17.

ACP standardisiert vier Dinge:

• Checkout. Der Händler stellt eine Checkout-Session-API bereit: Der Agent erstellt eine Session aus Artikeln, ergänzt sie um Adresse und Versandoption und schließt sie ab oder bricht sie ab. Die Spezifikation stellt ausdrücklich klar, dass der Händler das führende System für Bestellungen, Zahlungen, Steuern und Compliance bleibt und dass die Zahlung über den eigenen Zahlungsdienstleister des Händlers läuft.
• Delegierte Zahlung. Ein Zahlungsanbieter gibt ein Einmal-Token aus, dessen Nutzung durch eine „Allowance" begrenzt ist: einen Höchstbetrag, eine Währung, eine bestimmte Checkout-Session, einen bestimmten Händler und einen Ablaufzeitpunkt. Stripes Shared Payment Token war die erste kompatible Implementierung. Eine separate API für delegierte Authentifizierung deckt Prüfungen nach 3-D Secure 2 ab.
• Produkt-Feed. Version 2026-04-17 hat eine Feed-API ergänzt. Sie folgt einem Push-Modell: Der Händler sendet seinen Katalog an einen Feed, den die Agenten-Plattform hostet, entweder als vollständige Datei oder als Teilaktualisierungen.
• Warenkorb und Bestellungen, dazu ein Binding für das Model Context Protocol (MCP).

Was ist aus Instant Checkout geworden?

Am 24. März 2026 gab OpenAI bekannt, dass die erste Version von Instant Checkout nicht die gewünschte Flexibilität geboten habe und dass Händler ihren eigenen Checkout nutzen könnten, während sich OpenAI auf die Produktsuche konzentriere. In derselben Ankündigung hieß es, ACP werde erweitert, um Produkt- und Aktions-Feeds in ChatGPT zu bringen. Das Protokoll besteht also weiter, die Checkout-Spezifikation existiert noch, und in ChatGPT zählt heute der Feed mehr als der Checkout. Das Einspielen von Produkt-Feeds in ChatGPT ist auf zugelassene Partner beschränkt, die sich bei OpenAI bewerben.

Welche Produktdaten braucht ein ACP-Feed?

In der offenen ACP-Feed-API braucht ein Produkt eine stabile id und mindestens eine Variante, und jede Variante braucht eine stabile id und einen title. Alles andere ist im Schema optional: Preis und Listenpreis in kleinsten Währungseinheiten, Verfügbarkeitsstatus, Medien, Kategorien, Variantenoptionen wie Farbe und Größe, Verkäufer, Grundpreis und eine Liste von barcodes, in der jeder Eintrag einen Typ wie GTIN, UPC oder EAN und einen Wert hat.

OpenAIs eigene Feed-Spezifikation für ChatGPT ist strenger. Sie verlangt Artikel-ID, Titel, Beschreibung, Produkt-URL, Marke, Verkäufername, URL des Hauptbilds, Verfügbarkeit und Preis. Das Feld gtin ist optional, muss 8, 12, 13 oder 14 Ziffern mit gültiger Prüfziffer haben und soll weggelassen werden, wenn das Produkt keine hat. Das Feld mpn muss zusammen mit der Marke gesendet werden, und die Spezifikation weist Händler an, keine Teilenummer als Ersatz für eine fehlende GTIN zu erfinden.

Der ACP-Feed-Vorschlag klärt außerdem einen wichtigen Punkt: Feed-Daten sind informativ, und die Checkout-Antwort ist maßgeblich für Preis, Bestand, Steuer und Versand. Wenn die Varianten-ID im Feed nicht die ID ist, die der Checkout des Händlers akzeptiert, muss der Händler eine Zuordnung bereitstellen.

Was ist das Universal Commerce Protocol (UCP)?

UCP ist ein offener Standard für die gesamte Customer Journey beim Kauf: Produktsuche, Warenkorb, Checkout, Kontoverknüpfung und Bestellungen. Google hat ihn am 11. Januar 2026 gestartet, entwickelt in Zusammenarbeit mit Shopify, Etsy, Wayfair, Target und Walmart und veröffentlicht unter ucp.dev unter der Apache-2.0-Lizenz. Die Governance ist seither gewachsen: Im April 2026 kam Stripe zu Google und Shopify als ständiges Mitglied des Governing Council hinzu, und im Laufe des Sommers wurden technische Komitees für Zahlungen, Unterkünfte und Lebensmittel gebildet. Das aktuelle Release ist v2026-08-25.

Ein Unternehmen, das UCP unterstützt, veröffentlicht unter /.well-known/ucp ein Profil mit den angebotenen Funktionen, sodass ein Agent sie ohne individuelle Integration erkennen kann. Zu den Funktionen gehören:

• Katalogsuche und -abfrage, ergänzt in v2026-04-08.
• Warenkorb und Checkout, mit Steuern und Preisen, die das Unternehmen berechnet.
• Identitätsverknüpfung über OAuth 2.0, sodass ein Agent im Konto eines Kunden handeln kann, ohne dessen Passwort zu kennen.
• Bestellungen, mit Status-, Versand- und Rücksendeaktualisierungen per Webhook.
• Payment Handler, die das Zahlungsmittel vom Anbieter trennen, der es abwickelt, und die AP2 für Zahlungsmandate nutzen.

UCP kann über REST, MCP oder Agent2Agent (A2A) angeboten werden. Googles erste Implementierung ermöglicht den Kauf bei teilnahmeberechtigten Händlern im KI-Modus der Google Suche und in der Gemini-App. Sie läuft über ein Google-Merchant-Center-Konto und bestehende Shopping-Feeds, der Zugang erfolgt über eine Warteliste, und der Händler bleibt Merchant of Record.

Welche Produktdaten braucht UCP?

Eine UCP-Variante muss eine id, einen title, eine description und einen price haben. Die Varianten-id ist die, die beim Checkout als Artikel-ID verwendet wird. Zu den optionalen Feldern gehören die sku des Händlers, eine kanonische URL, Verfügbarkeit, Medien, Grundpreis und barcodes, deren bekannte Typen UPC, EAN, ISBN, GTIN und JAN sind.

Die Regeln für die Abfrage sind aufschlussreich. Ein UCP-Katalog muss die Abfrage nach Produkt-ID und Varianten-ID unterstützen. Er kann sekundäre Kennungen wie die SKU unterstützen. Auf eine Abfrage per GTIN kann sich ein Agent nicht verlassen.

Für Googles eigene Implementierung gelten weiterhin die Feed-Regeln des Merchant Center. Google empfiehlt eine GTIN für alle Produkte, denen der Hersteller eine zugewiesen hat, und warnt, dass das Weglassen einer zugewiesenen GTIN zur Ablehnung des Produkts führen kann.

Was ist das Agent Payments Protocol (AP2)?

AP2 löst ein anderes Problem. Wenn ein Agent bezahlt, haben Händler, kartenausgebende Bank und Zahlungsnetzwerk nicht gesehen, wie der Nutzer auf „Kaufen" geklickt hat. AP2 gibt ihnen einen signierten Nachweis dessen, was der Nutzer autorisiert hat, damit sie die Transaktion annehmen und Streitfälle klären können. Google hat AP2 am 16. September 2025 angekündigt. Am 28. April 2026 veröffentlichte Google Version 0.2 und kündigte an, AP2 an die FIDO Alliance zu übergeben, wo die Standardisierung in den Arbeitsgruppen der FIDO weitergeht. Die AP2-Spezifikationsseite und das Repository sind unter der Apache-2.0-Lizenz veröffentlicht.

Die beiden Versionen beschreiben dieselbe Idee unterschiedlich:

• Version 0.1 (September 2025) nutzte drei Mandate: ein Intent Mandate, das festhält, worum der Nutzer gebeten hat, ein Cart Mandate, das die genauen Artikel und den Preis dokumentiert, die der Nutzer freigegeben hat, und ein Payment Mandate.
• Version 0.2 (April 2026) nutzt ein Checkout Mandate, das absichert, was gekauft wird, und ein damit verknüpftes Payment Mandate, das die Zahlung absichert. Beide gibt es in einer offenen Form, die die Vorgaben des Nutzers enthält, bevor ein Warenkorb feststeht, und in einer geschlossenen Form, die an einen abgeschlossenen Checkout gebunden ist. Mandate sind signierte Nachweise mit selektiver Offenlegung, sodass jede Partei nur sieht, was sie braucht.

AP2 definiert fünf Rollen (Shopping-Agent, Credential Provider, Händler, Zahlungsabwickler des Händlers und eine vertrauenswürdige Oberfläche, auf der der Nutzer zustimmt) und zwei Modi. Bei Käufen mit „human present" gibt der Nutzer den endgültigen Warenkorb frei. Bei Käufen mit „human not present", der wichtigsten Neuerung in v0.2, signiert der Nutzer Vorgaben im Voraus, und der Agent schließt einen Kauf ab, der sie erfüllt.

AP2 klammert die Katalog- und Checkout-APIs bewusst aus. Es ist für das Zusammenspiel mit UCP ausgelegt: Bei Nutzung mit UCP muss der vom Händler signierte Checkout in einem Checkout Mandate das UCP-Checkout-Objekt sein. Sein Artikeltyp enthält nur eine id (beschrieben als häufig die SKU), einen title, einen price und eine optionale Bild-URL.

Wo stehen Visa und Mastercard?

Beide Kartennetzwerke haben Programme, die neben diesen Protokollen stehen, statt sie zu ersetzen. Sie befassen sich mit der Identität von Agenten und mit Zahlungsdaten, nicht mit Produktdaten.

• Visa Trusted Agent Protocol (14. Oktober 2025, entwickelt mit Cloudflare) erlaubt einem zugelassenen Agenten, seine Anfragen an einen Händler zu signieren, damit der Händler einen legitimen Shopping-Agenten von einem bösartigen Bot unterscheiden kann. Es kann die Absicht des Agenten, die Wiedererkennung des Verbrauchers und optional Zahlungsinformationen übermitteln und ist im Visa Developer Center und auf GitHub veröffentlicht.
• Mastercard Agent Pay (29. April 2025) hat Agentic Tokens eingeführt und verlangt, dass Agenten registriert und verifiziert sind, bevor sie Transaktionen ausführen. Verifiable Intent, von Mastercard und Google am 5. März 2026 vorgestellt, ist eine offene Spezifikation für einen manipulationssicheren Nachweis dessen, was ein Nutzer autorisiert hat, abgestimmt auf AP2 und UCP. Laut Googles Ankündigung vom April 2026 wird auch Verifiable Intent an die FIDO Alliance übergeben.

Ein Händler kommt mit diesen Programmen meist über seinen Zahlungsanbieter in Berührung, und sie ändern nichts daran, was Ihr Katalog enthalten muss.

Wie unterscheiden sich ACP, UCP und AP2?

Wo kommt die Produktidentität ins Spiel, und wo schweigen die Protokolle?

Nebeneinander gelesen identifizieren alle drei Spezifikationen ein Produkt beim Checkout über eine ID, die der Händler gewählt hat. ACP nutzt die Varianten-ID aus dem Feed, UCP seine Varianten-ID, und die Mandate von AP2 listen zulässige Artikel-IDs des Händlers auf. Für den Abschluss einer Bestellung in einem Shop ist das sinnvoll. Es ist aber die Schwachstelle, die Paula Rivero beim W3C/GS1-Workshop in Zürich beschrieben hat: Ein Agent kann den Checkout fehlerfrei durchlaufen und trotzdem das falsche Produkt kaufen, weil die interne ID eines Händlers außerhalb dieses Shops nichts darüber aussagt, um welches physische Produkt es sich handelt.

Die GTIN ist das Feld, das diese Grenze überwindet. ACP und UCP haben beide einen Platz dafür, und OpenAIs Feed-Spezifikation prüft ihre Prüfziffer. Keines der drei Protokolle macht sie verpflichtend, keines sagt, wie ein Agent dieselbe GTIN über Händler hinweg abgleichen soll, und keines erwähnt GS1 Digital Link, den Digitalen Produktpass oder einen anderen Weg, ein Produkt zu Informationen direkt von der Marke aufzulösen.

Unsere Lesart, wie sie zusammenpassen, die in keiner der Spezifikationen so steht:

• Die GTIN im Feed ist die Brücke zwischen Händlern. Wenn zwei Shops dasselbe Shampoo mit derselben GTIN verkaufen, kann ein Agent sie als dasselbe Produkt erkennen und Angebote vergleichen, statt anhand von Titeln zu raten. Fehlt die GTIN, greift der Agent auf den Abgleich von Namen zurück.
• Ein offenes AP2-Mandat ist nur so präzise wie seine Artikel-IDs. Ein Nutzer, der „genau dieses Produkt nachbestellen" autorisiert, autorisiert in v0.2 eine Liste von Artikel-IDs des Händlers. Erst eine GTIN hinter diesen IDs sorgt dafür, dass die Anweisung bei einem zweiten Shop dasselbe bedeutet.
• Bei GS1 Digital Link liegt die Version der Wahrheit, die von der Marke stammt. Ein GS1 Digital Link-URI wird aus derselben GTIN gebildet, sodass ein Agent, der die GTIN bereits hat, ihn konstruieren und zu Informationen auflösen kann, die die Marke kontrolliert: Spezifikationen, Anleitungen, Sicherheitsinformationen und in der EU Passdaten. Keines der Protokolle verlangt das von einem Agenten. Es steht dem in ihnen aber auch nichts entgegen.

Wo ein QR-Code nicht hilft: Er spielt bei Checkout, Zahlung und Mandaten keine Rolle, und ein protokollkonformer Feed braucht keinen. Sein Wert liegt hier in der Kennung dahinter.

Was sollten Marken und Einführer jetzt tun?

Die Protokolle werden sich weiter verändern; die Arbeit am Katalog hängt nicht davon ab, welches sich durchsetzt.

1. Stellen Sie sicher, dass jedes Produkt mit GTIN diese auch trägt, in Ihren eigenen Systemen, in Ihrem Google-Merchant-Center-Feed und in jedem ACP-Feed, und dass die Prüfziffer gültig ist. Erfinden Sie keine Kennungen für Produkte, die keine haben.
2. Führen Sie eine stabile ID pro Variante, und prüfen Sie, ob die ID in Ihrem Feed die ist, die Ihr Checkout akzeptiert. ACP und UCP hängen beide davon ab.
3. Ordnen Sie GTIN und Varianten-ID ausdrücklich einander zu. Eine GTIN sollte auf genau eine verkaufsfähige Variante in Ihrem Katalog verweisen, einschließlich Packungsgröße und Rezeptur.
4. Senden Sie die Felder, nach denen Agenten auswählen: Titel, Beschreibung, Marke, Preis, Verfügbarkeit, Bilder und eine kanonische Produkt-URL. In ACP und UCP sind das die Daten, die ein Agent vor dem Checkout sieht.
5. Halten Sie Preis und Bestand aktuell. Beide Spezifikationen behandeln den Feed als informativ und den Checkout als maßgeblich, ein veralteter Feed schickt Agenten also in fehlschlagende Checkouts.
6. Fragen Sie Ihren Zahlungsanbieter, welche agentischen Abläufe er unterstützt: Stripes Shared Payment Token für ACP, UCP Payment Handler, AP2-Mandate, die Agenten-Programme von Visa und Mastercard. Selbst implementieren müssen Sie diese selten.
7. Geben Sie der GTIN ein auflösbares Zuhause. Ein GS1 Digital Link Resolver unter Ihrer eigenen Domain erlaubt jedem Agenten, mit jedem Protokoll, das Produkt mit Ihren eigenen Daten abzugleichen. Es ist auch der Weg, auf den sich der Digitale Produktpass der EU stützen wird.

Digital Link ist GS1-Lösungspartner, und unsere Plattform gibt jedem Produkt einen GS1 Digital Link auf Basis seiner GTIN, mit von der Marke kontrollierten Seiten und strukturierten Daten dahinter, die Menschen und Maschinen lesen können. Für Agentic Commerce ist das die Identitätsebene, die die Protokolle offenlassen: eine Kennung pro Produkt, die zu Ihren Daten auflöst, egal welcher Agent oder welches Protokoll fragt. Wenn Sie prüfen möchten, wie gut Ihr Katalog auf agentengesteuertes Einkaufen vorbereitet ist, nehmen Sie Kontakt auf, und unser Team prüft Ihre Produktdaten gemeinsam mit Ihnen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen ACP und AP2?

ACP ist ein Commerce-Protokoll: Es standardisiert den Produkt-Feed, die Checkout-Session und ein delegiertes Zahlungs-Token zwischen einem KI-Agenten und einem Händler. AP2 ist ein Protokoll für Vertrauen im Zahlungsverkehr: Es standardisiert signierte Mandate, die nachweisen, was ein Nutzer autorisiert hat, und überlässt Katalog und Checkout anderen Protokollen. Die AP2-Spezifikation nennt UCP als das Commerce-Protokoll, für das es ausgelegt ist.

Ist ACP dasselbe wie Instant Checkout in ChatGPT?

Nein. Instant Checkout war das Produkt von OpenAI, das auf ACP aufbaute. Im März 2026 rückte OpenAI vom eigenständigen Instant Checkout ab, damit Händler ihren eigenen Checkout nutzen können, und erweiterte ACP um Produkt- und Aktions-Feeds für die Produktsuche in ChatGPT. Die ACP-Spezifikation selbst bleibt offen und im Beta-Status.

Verlangen Agentic-Commerce-Protokolle eine GTIN?

Nein. ACP und UCP bieten beide ein optionales Barcode-Feld, das eine GTIN akzeptiert, und OpenAIs Feed-Spezifikation für ChatGPT führt gtin als optional. Das Google Merchant Center empfiehlt eine GTIN für jedes Produkt, das eine hat, und kann Produkte ablehnen, bei denen eine zugewiesene GTIN fehlt.

Nutzt eines dieser Protokolle GS1 Digital Link?

Nicht Stand Oktober 2026. Keine der Spezifikationen von ACP, UCP oder AP2 erwähnt GS1 Digital Link. Da ein GS1 Digital Link-URI aus der GTIN gebildet wird, kann jeder Agent, der über diese Protokolle eine GTIN erhält, ihn auflösen, aber das ist unsere Lesart, wie sie zusammenspielen, keine Anforderung der Protokolle.

Wem gehört AP2 heute?

Google hat AP2 entwickelt und am 28. April 2026 zusammen mit der Veröffentlichung von Version 0.2 die Übergabe an die FIDO Alliance angekündigt. Spezifikation und SDK bleiben auf GitHub öffentlich, und die weitere Standardisierung findet in den Arbeitsgruppen der FIDO statt.

Können Händler in der EU diese Protokolle nutzen?

Die Spezifikationen sind offen und können überall implementiert werden. Die ersten Verbraucherprodukte auf ihrer Basis starteten in den Vereinigten Staaten, und die Plattformen entscheiden Land für Land, wo Händler teilnehmen können. Prüfen Sie daher die aktuelle Teilnahmeberechtigung jeder Plattform, bevor Sie damit planen.