Agentischer Commerce für Shop-Entwickler: UCP, ACP und AP2 im Vergleich

Agentischer Commerce ist der Versuch, ein Sprachmodell Dinge im Auftrag eines Nutzers kaufen zu lassen, und dafür braucht es eine Maschinenschnittstelle für den Kauf: ein Protokoll, keine Webseite. Ab September 2026 sind drei davon relevant. Das Universal Commerce Protocol (UCP) deckt den gesamten Commerce-Lebenszyklus ab, das Agentic Commerce Protocol (ACP) Bestellungen und Zahlung innerhalb eines Assistenten, und das Agent Payments Protocol (AP2) den Nachweis, dass ein Mensch das, was der Agent getan hat, tatsächlich autorisiert hat.

Dieser Artikel vergleicht sie Mechanismus für Mechanismus und endet damit, was ein mittelgroßer EU-Shop jetzt tatsächlich bauen sollte. Die Kurzfassung: Alle drei lassen den Händler als Merchant of Record, und keines verlangt, deinen Checkout neu zu bauen.

Warum Shopping-Agenten überhaupt Protokolle brauchen

Ein Browser-Agent, der deine Checkout-Seite steuert, ist für alle Beteiligten eine schlechte Idee. Er klickt daneben, er sieht eine versteckte Gebühr nicht, er rät ein Versandfeld aus, und der Audit-Trail ist ein Video eines wandernden Cursors. Die Zahlung ist schlimmer: Ein Agent, der Kartennummern eintippt, ist ein Agent, der Kartennummern verarbeitet.

Ein Protokoll ersetzt das Klicken durch signierte, strukturierte Nachrichten. Der Agent fragt das System eines Händlers nach einem Produkt, baut einen Warenkorb, startet eine Checkout-Session und bekommt etwas zurück, das er einem Menschen zeigen kann; der Händler rechnet Preise, Steuern, Fulfillment und Erstattungen weiterhin aus seinem eigenen System ab. Stripes Einordnung des Problems ist die schärfste Fassung: Der klassische E-Commerce nahm an, dass ein Mensch auf einer Seite, die das Unternehmen kontrolliert, auf „Kaufen“ klickt, und „in AI-geführtem Commerce handeln Agenten für den Käufer und bringen dessen Identität, Zahlungsmittel und Kaufkontext in die Transaktion ein“.

Die Konsequenz für Entwickler ist der Teil, der wirtschaftlich zählt: Eine Oberfläche für Agenten ist ein zweites Frontend. Du hast schon zwei (deinen Shop und deinen Checkout); ein drittes ist kein Rewrite, aber echte Arbeit – und dort sollten die meisten Teams anfangen.

Was UCP tatsächlich abdeckt

Das Universal Commerce Protocol ist das breiteste der drei. Es beschreibt fünf Kernfähigkeiten: Katalogsuche und -abruf, Warenkorbaufbau, Identity Linking, Checkout und Bestellverwaltung; für Unterkünfte läuft ein Entwurf, für Gastronomie ist er angekündigt. Es läuft über REST und JSON-RPC, und AP2, A2A und MCP werden daneben unterstützt – das heißt, derselbe Händler kann einen Assistenten, einen Agent-zu-Agent-Ablauf und einen MCP-Client bedienen.

Zwei Design-Entscheidungen in UCP lohnt es sich zu übernehmen, unabhängig davon, ob du es einsetzt. Erstens bleibt das Unternehmen Merchant of Record: Die Dokumentation sagt ausdrücklich, dass das Unternehmen die Kontrolle, seine eigene Geschäftslogik und die Kundenbeziehung behält. Zweitens ist es Identity Linking über OAuth 2.0, sodass ein Agent eine autorisierte Beziehung mit engem Scope zum Händler hält statt einer Kopie der Kundenzugangsdaten. Das Beispiel-Dokument eines Authorization Servers kündigt einen Scope wie dev.ucp.shopping.checkout über ein Standarddokument /.well-known/oauth-authorization-server an – eine ganz gewöhnliche OAuth-Integration, mit der du arbeiten kannst, ohne zu raten.

Wie ein UCP-Kauf durch das System läuft

Die Beispiel-Payloads auf der UCP-Website sind der schnellste Weg, das Design zu verstehen, weil sie die Felder zeigen, auf die ein Händler antworten können muss. Eine Katalogantwort liefert Produkte mit Varianten, SKU, Optionen, Preisbereichen in Minor Units, Kategorien aus drei Taxonomien zugleich (einer Plattform-Taxonomie, einer eigenen des Händlers und einer Google-Produktkategorie), Medien mit Alt-Texten, Bewertungen, beliebigem metadata und einem Cursor für die Paginierung. Das ist ein Produktfeed, mit dem ein Agent arbeiten kann, ohne eine Seite zu scrapen.

Ein Warenkorb ist mehr als eine Liste von Positionen. Der Beispiel-Warenkorb trägt ein context mit Land, Region, Postleitzahl, Intention, Sprache und Währung des Käufers; einen attribution-Block mit Source, Medium, Campaign, Click ID und Referrer; ein buyer; Summen; messages für Dinge, die der Agent aussprechen soll; Links zur Datenschutzrichtlinie, zu den AGB und zum FAQ; maschinenlesbare policies wie eine Rückgaberichtlinie mit JSON Pointern, die angeben, auf welche Positionen sie zutrifft; ein continue_url, das den Käufer zurück auf deine Seite bringt; und ein expires_at. Zwei dieser Felder sind wichtiger, als sie aussehen: Die Attribution sichert dir die Zuordnung des Verkaufs, und der Policy-Block ist der Weg, auf dem ein Agent deine Rückgabebedingungen lernt, statt zu raten.

Der Checkout ist ein Session-Objekt mit einem Status wie ready_for_complete, Positionen, Summen, Zahlung und Fulfillment-Gruppen mit auswählbaren Versandoptionen. Das Bestellobjekt trägt dann eine checkout_id, eine permalink_url, Erwartungen an das Fulfillment, Ereignisse wie delivered mit einer Sendungsnummer und Anpassungen für Erstattungen. Mit anderen Worten: Die Bestellung ist ein lebendiger Datensatz, keine Bestätigungsmail – und genau den braucht ein Agent, wenn der Käufer drei Wochen später nach der Lieferung fragt.

Googles Under the hood of the Universal Commerce Protocol vom Januar 2026 nannte mehr als 20 unterstützende Unternehmen, darunter Shopify, Walmart, Target, Stripe, Visa und Mastercard, quer über Handel, Reise und Gastronomie. Die Unterstützerliste ist das Signal, auf das es ankommt: Ein Protokoll zählt erst, wenn Zahlungsnetze und Plattformen mit dabei sind, denn das sind die Teile, die ein Händler nicht ersetzen kann.

Was AP2 hinzufügt: den Nachweis, dass der Mensch Ja gesagt hat

AP2 gibt es wegen einer harten Frage: Wenn ein autonomer Agent zahlt, wie belegt irgendjemand, dass der Nutzer genau diesen Kauf autorisiert hat? Die Dokumentation nennt drei Lücken, die heutige Zahlungssysteme nicht schließen können, und es sind die richtigen: Autorisierung (hat der Nutzer diesem Agenten für diesen Kauf Vollmacht gegeben), Authentizität (entspricht die Anfrage der echten Absicht statt einem Agentenfehler oder einer Halluzination) und Verantwortlichkeit (wer ist rechenschaftspflichtig, wenn es falsch war).

Der Mechanismus ist ein Mandat, das als verifizierbarer digitaler Nachweis mitgeführt wird: ein manipulationsgeschütztes, kryptografisch signiertes Objekt. Es gibt zwei Mandate, jedes mit einer offenen und einer geschlossenen Stufe. Die offene Stufe des Checkout-Mandats hält die Vorgaben und Ziele des Nutzers fest, bevor ein Warenkorb endgültig ist; die geschlossene Stufe ist die Autorisierung für ein konkretes, abgeschlossenes Checkout. Die offene Stufe des Payment-Mandats hält Vorgaben für die Zahlung fest, etwa ein Budget und erlaubte Zahlungsmittel, und die geschlossene Stufe autorisiert einen konkreten Betrag, der an dieses Checkout gebunden ist.

Zwei Details aus der Dokumentation sind für die Umsetzung wichtig. AP2 ist eine herstellerneutrale Erweiterung von A2A und MCP statt eines geschlossenen Kreislaufs, und die Standardisierung läuft in Arbeitsgruppen der FIDO Alliance weiter: Die Spezifikation steht bei Version 0.2, und die erste Version deckt „Pull“-Zahlungsmethoden wie Kredit- und Debitkarten ab, Push-Zahlungen und Wallets stehen auf der Roadmap. Wenn dein Unternehmen B2B ist und Rechnungen statt Karten abrechnet, ist AP2 für dich vor allem über UCP relevant, nicht direkt.

Wohin ACP passt: Bestellungen aus einem Assistenten heraus

ACP ist das engste der drei und das konkreteste. Stripe und OpenAI haben es am 29. September 2025 als „einen neuen, händlerfreundlichen offenen Standard, den Stripe und OpenAI gemeinsam entwickelt haben“ angekündigt, zusammen mit Instant Checkout in ChatGPT, wo US-Käufer bei Etsy-Händlern und kurz darauf bei einer großen Gruppe von Shopify-Händlern einkaufen konnten.

Der Mechanismus lohnt sich, weil er das Credential-Problem ohne ein eigenes Protokoll für Credentials löst. Nachdem der Käufer im Chat bezahlt hat, stellt Stripe ein Shared Payment Token mit engem Scope auf einen bestimmten Händler und eine Warenkorbsumme aus. Damit kann der Assistent eine Zahlung anstoßen, ohne die Zahlungs-Credentials des Käufers jemals offenzulegen. Das Token geht über die API an den Händler, der es über Stripe oder einen anderen Anbieter verarbeiten kann, weiterhin mit Stripes Risikoscores. Die Bestellungen selbst fließen über ACP vom Assistenten an das Backend des Händlers, wo dieser wie immer annimmt oder ablehnt, abrechnet, die Steuer behandelt und das Fulfillment macht.

Zwei Einschränkungen. ACP ist eine Geschichte für Assistenten und Plattformen, kein allgemeiner Agentenstandard, und Berichte aus März 2026 beschreiben Instant Checkout als Umstieg auf Apps – das ist eine Verschiebung der Ausrichtung, kein Auslaufen. Ebenfalls relevant: Stripe liefert ein Agent Toolkit und einen Stripe MCP Server aus, also ist ein großer Teil des „agentischen Commerce“ in der Praxis ein MCP-Client, der mit einer Zahlungs-API spricht, und kein Protokoll-Rollout.

Die drei Protokolle im Vergleich

Die drei überlappen sich, und keines ersetzt die anderen. UCP ist der Lebenszyklus, AP2 ist der Zahlungsnachweis, ACP ist der assistentennahe Bestellweg, und WebMCP ist die Alternative vor Ort, bei der der Agent im Browser bleibt.

Die vierte Option ist kein Protokoll und oft die günstigste. Wenn der Agent auf deiner eigenen Seite läuft, brauchst du nichts davon: Deklarierte Tools beim Browser registrieren und den Agenten deinen Katalog, deinen Bestand und deinen Warenkorb direkt aufrufen lassen, wie es die WebMCP-Implementierung dieser Seite macht. Das funktioniert heute in einem Browser mit Origin-Trial, braucht keine Partnerintegration und hält den Käufer auf deinem Checkout.

Was ein mittelgroßer EU-Shop jetzt tun sollte

Nach einem Jahrzehnt in B2B-Commerce und PIM-Plattformen ist mein Rat für einen Shop in dieser Lage bewusst langweilig. Mache den Katalog maschinenlesbar und korrekt, bevor du dich irgendwo anschließt: einen Produktfeed mit Varianten, SKUs, Steuerklassen, Bestandsstatus und Einzelpreisen, denn alle diese Protokolle starten von derselben Annahme, dass du Fragen zu einem Produkt beantworten kannst. Das ist dieselbe Disziplin wie Markdown an Agenten ausliefern statt HTML zu scrapen, auf Daten statt auf Seiten angewandt. Baue dann die UCP-Struktur für Katalog, Warenkorb und Bestellung um, wenn deine Kunden Endkonsumenten sind, weil es die breiteste Spezifikation ist und diejenige, die eine Plattform am ehesten verlangen wird, mit der du nicht verhandeln kannst.

Bau den Checkout nicht neu. Jedes dieser Designs behält ausdrücklich die eigenen Systeme des Händlers als Merchant of Record, und ein Checkout-Rewrite ist ein Risiko über mehrere Quartale ohne nachgewiesenen Nutzen. Für B2B bringt mehr ein MCP Server über deine eigenen Domänen-APIs, mit Tools, die Verfügbarkeit, Lieferzeiten und Bestellstatus ausgeben, damit die internen Agenten deiner Kunden direkt mit dir arbeiten können. Das ist ein kleineres Projekt als eine Protokoll-Zertifizierung und bringt sofort Wert; es zahlt sich auch dann aus, was die Protokolle als Nächstes tun, solange die Tools wenige und gut beschrieben sind.

Der ehrliche Zielkonflikt: Alle drei Spezifikationen sind jung und können sich noch ändern, AP2 ist noch nicht relevant, wenn du keine Kartenzahlungen für autonome Käufe annimmst, und wer zu früh ist, zahlt mit Integrationsarbeit ohne garantierten Traffic. Warte auf die Teile, die dein größter Plattformpartner verlangt, und investiere die Zeit in die Datenqualität, die jedes Protokoll braucht.

Checkliste für agentischen Commerce

1. Mache den Katalog abfragbar: Varianten, SKUs, Preise in Minor Units, Steuerklasse, Bestandsstatus, Bilder mit Alt-Texten.
2. Veröffentliche maschinenlesbare Richtlinien, Rückgaben und Versand eingeschlossen, damit ein Agent deine Bedingungen nennen kann, statt zu raten.
3. Halte die Attribution im Warenkorb-Payload, sonst verlierst du die Zuordnung aller Verkäufe, zu denen man dich geschickt hat.
4. Bleib Merchant of Record und halte Preise, Steuern, Fulfillment und Erstattungen in deinem eigenen System.
5. Nutze OAuth mit engem Scope für den Agentenzugriff, niemals ein geteiltes Konto oder ein langlebiges Token.
6. Lass einen Agenten nie rohe Kartendaten sehen; wenn du ACP beitrittst, ist genau dafür das Shared Payment Token da.
7. Ergänze WebMCP Tools auf deiner eigenen Seite für lesende Aktionen, damit In-Page-Agenten nicht scrapen müssen.
8. Rechne damit, dass sich die Spezifikation bewegt. Versioniere deine Integration und halte den Adapter dünn.

Wenn du so eine Integration baust: Auf der Seite zum B2B-E-Commerce-Entwickler steht, wie ich solche Arbeit strukturiere, und die B2B-E-Commerce-Seite behandelt die PIM- und Katalogseite, auf die alle diese Protokolle angewiesen sind.

Quellen

1. Universal Commerce Protocol: capabilities, core concepts and specification
2. Google Developers Blog: Under the hood of the Universal Commerce Protocol (Januar 2026)
3. AP2: Agent Payments Protocol documentation, mandates and verifiable credentials
4. Stripe and OpenAI: Instant Checkout and the Agentic Commerce Protocol (29. September 2025)
5. Digital Commerce 360: OpenAI shifts its checkout plans for agentic commerce (6. März 2026)