Das Versprechen klingt mühelos: Sie sagen ChatGPT, was Sie wollen, tippen zur Bestätigung, und es gehört Ihnen. Keine Tabs, keine Formulare, einfach erledigt. Hinter diesem Tippen steckt in Wahrheit eine Rube-Goldberg-Maschine aus kryptografischen Verträgen, Zahlungs-Tokenisierung und Betrugserkennung, aufgesetzt auf eine Infrastruktur, die davon ausgeht, dass Menschen auf Knöpfe klicken.
OpenAI hat Instant Checkout in ChatGPT gestartet. Nutzer in den USA können damit einzelne Artikel von Etsy-Verkäufern kaufen, ohne die Unterhaltung zu verlassen. Dahinter steht das Agentic Commerce Protocol (ACP), ein neuer Standard, den OpenAI gemeinsam mit Stripe entwickelt hat, damit KI-Agenten den Handel abwickeln können. Der Start ist echt, aber eng begrenzt: Nutzer in den USA, ein Artikel pro Kauf, nur Händler aus den USA, vorerst Etsy, Shopify soll „demnächst“ folgen.
Schon davor hatte Google das Agent Payments Protocol (AP2) angekündigt, unterstützt von über 60 Unternehmen, darunter Mastercard, PayPal und Coinbase. Anders als OpenAIs live geschaltetes, aber begrenztes Angebot ist AP2 als Spezifikation fertig, ohne ein einziges Produkt für Endkunden. Es ist ein bedachteres, kryptografisch strengeres Framework, das noch monatelang keine echten Nutzer sehen wird.
Der Zeitpunkt zeigt, worum es geht. Beide Unternehmen sehen eine Zukunft, in der KI-Agenten Produkte nicht nur empfehlen, sondern in Ihrem Namen selbstständig kaufen. Die Frage ist, wessen Infrastruktur zum Standard wird und ob überhaupt eine davon das Versprechen einlösen kann, ohne das bestehende Finanzsystem zu zerlegen.
Das Problem, das beide lösen wollen
Die E-Commerce-Infrastruktur beruht auf einer Grundannahme: Ein Mensch klickt auf einer Website, der er vertraut, auf „Kaufen“. Auf dieser Annahme ruht alles: Modelle zur Betrugserkennung, Haftungsregeln, Streitbeilegung, die Einhaltung von Vorschriften.
Sobald ein KI-Agent einen Kauf auslöst, vor allem einen, den Sie gerade nicht aktiv verfolgen, bricht diese Annahme zusammen. Wie beweisen Sie, dass der Nutzer ihn autorisiert hat? Woher weiß ein Händler, dass die Anfrage des Agenten die tatsächliche Absicht wiedergibt und keine KI-Halluzination darüber, was „Laufschuhe unter 100 Dollar“ bedeutet? Und wer haftet, wenn etwas schiefgeht, also bei falscher Größe, falscher Farbe oder einer betrügerischen Abbuchung?
„Ohne ein gemeinsames Protokoll riskieren wir ein fragmentiertes Ökosystem proprietärer Zahlungslösungen“, warnt die AP2-Dokumentation von Google. Die Unterlagen von OpenAI klingen ähnlich. Beide positionieren ihre Protokolle als neutrale Open-Source-Infrastruktur, die jeder implementieren kann: ACP und AP2 stehen beide unter der Lizenz Apache 2.0.
Beide unterstützen eine ausdrückliche Bestätigung durch den Nutzer. Beide wollen über Zahlungsdienstleister hinweg funktionieren. Beide bemühen die Sprache von Nutzerkontrolle und Sicherheit.
Wer aber in die technische Architektur schaut, findet große Unterschiede. Sie zeigen grundverschiedene Wetten darauf, was am meisten zählt, was sich heute ausliefern lässt und was beim ersten Anlauf richtig gebaut sein muss.
ACP: Schnell ausliefern, in Produktion reparieren
Das Agentic Commerce Protocol ist pragmatische Infrastruktur, die Händler möglichst schnell über ChatGPT verkaufen lassen soll. Die Spezifikation deckt Produktsuche, Checkout-APIs und Zahlungsabläufe ab, mit OpenAPI-Spezifikationen, JSON-Schemas und Referenzimplementierungen.
Das Angebot an die Händler ist einfach: Sie nutzen Ihre bestehenden Systeme, behalten Ihre Kundenbeziehungen und erreichen die Nutzerbasis von ChatGPT. Wer schon bei Stripe ist, kann einfache Agentenzahlungen mit „nur einer einzigen Codezeile“ aktivieren. So formuliert es Stripe selbst für bestehende Händler, die die Funktion einschalten.
Technisch stimmt das für den speziellen Fall bestehender Stripe-Händler, die per Feature Flag Stripe Shared Payment Tokens (SPT) aktivieren. Für alle anderen wartet echte Arbeit: REST-Endpunkte implementieren, Webhooks für Bestellereignisse, Vorgaben für Produkt-Feeds und die Anbindung an einen Zahlungsdienstleister, der die Delegated Payment Spec unterstützt. Stripes SPT ist derzeit die einzige dokumentierte Antwort auf die konkrete Frage, wie Zahlungen über ACP laufen.
Die Spezifikation von ACP ist breit angelegt, mit Abonnements, asynchronen Käufen und Warenkörben über mehrere Händler. Der Weg in die Praxis ist dagegen schmal: heute Etsy-Käufe einzelner Artikel für Nutzer in den USA, Shopify „demnächst“, dazu Karten über Stripes Shared Payment Token. Das ist keine Kritik, genau so werden Standards real. Von „Agenten kaufen alles, überall“ ist es aber weit entfernt. Warenkörbe mit mehreren Artikeln und weitere Regionen stehen ausdrücklich als künftige Arbeit auf der Roadmap von OpenAI.
Das ist klassisches Move-fast-and-iterate: eine minimale lauffähige Version ausliefern, aus dem Produktionsverkehr lernen, die Spezifikation an dem weiterentwickeln, was kaputtgeht. Die Wette lautet, dass ein Deployment in Produktion selbst mit harten Einschränkungen Dinge lehrt, die keine Spezifikation lehren kann.
AP2: Zuerst die Vertrauensschicht bauen
Googles Agent Payments Protocol geht einen anderen Weg. Wo ACP Abkürzungen für eine schnelle Einführung bietet, baut AP2 kryptografische Infrastruktur für nachprüfbares Vertrauen.
Der zentrale Mechanismus sind die Mandates: manipulationssichere, kryptografisch signierte Verträge, die einen Prüfpfad von der ersten Absicht bis zur endgültigen Zahlung ergeben. Die Spezifikation von AP2 definiert drei Arten dieser unveränderlichen JSON-Blobs, die im Streitfall als Beweismittel dienen:
Intent Mandates halten die Bedingungen fest, unter denen ein Agent handeln darf. „Kauf Konzertkarten, sobald der Vorverkauf startet, unter 200 Dollar, Plätze nebeneinander“ wird zu einem kryptografisch signierten Vertrag mit genau festgelegten Grenzen.
Cart Mandates halten die Freigabe in Echtzeit fest. Wenn Sie einen Kauf bestätigen, signieren sowohl Sie als auch der Händler, und so entsteht ein nicht abstreitbarer Beleg dafür, was zu welchem Preis gekauft wurde.
Payment Mandates sind minimale Berechtigungsnachweise, die an Zahlungsnetzwerke gehen und den Kartenausgebern signalisieren, dass ein Agent beteiligt ist und ob der Nutzer anwesend ist.
Diese Mandatskette beantwortet Fragen nach Autorisierung, Echtheit und Verantwortlichkeit mit kryptografischen Beweisen statt mit Versprechen in Richtlinien. Sie ist ausdrücklich sowohl für Szenarien mit anwesendem Menschen gedacht (Sie kaufen gerade selbst ein) als auch für solche ohne (Ihr Agent führt selbstständig einen vorab autorisierten Kauf aus).
AP2 ist so positioniert, dass es neben Interoperabilitätsprojekten wie dem Agent-to-Agent-Protokoll von Google und dem Model Context Protocol von Anthropic steht, ohne fest von ihnen abzuhängen. Für Stablecoin-Zahlungen gibt es die Erweiterung x402, entwickelt mit Coinbase, der Ethereum Foundation und anderen.
AP2 zieht kryptografische Gewissheit der Geschwindigkeit vor: ein signiertes Mandat bei jedem Hop, das Regulierungsbehörden lieben und Entwickler verfluchen werden, bis jemand ein Latenzbudget veröffentlicht.
Der Haken? VentureBeat berichtete: „Verbraucher können AP2-basierte Zahlungen heute in keinem öffentlich bekannten, real existierenden Produkt oder Dienst nutzen.“ Die Spezifikation des Protokolls ist fertig, mit Referenzimplementierungen in Python und für Android.[^11] Produkte für Endkunden sind noch mindestens Monate entfernt.
Worauf Sie sich tatsächlich einlassen
Beide Unternehmen werben mit einfacher Integration. Die Realität ist deutlich chaotischer.
Die dokumentierte „eine Codezeile“ für ACP gibt es wirklich, sofern Sie bestehender Stripe-Händler sind und eine bestimmte Funktion einschalten. Bei neuen Implementierungen sollten Sie mit Wochen an Entwicklung rechnen: Checkout-API-Endpunkte, Verwaltung der Produkt-Feeds, Webhook-Infrastruktur, Anbindung des Zahlungsdienstleisters, Logik zur Betrugserkennung und Fehlerbehandlung für Dutzende Sonderfälle.
Bei AP2 liegt die Hürde höher. Weil es über verschiedene Zahlungswege hinweg funktionieren soll, sind Sie nicht an Stripe gebunden. Dafür sind Sie für die Infrastruktur rund um Berechtigungsnachweise und Mandate zuständig: nachprüfbare Nachweise ausstellen, Signaturen prüfen, kryptografische Schlüssel verwalten, Audit-Logs führen und die rollenbasierte Architektur betreiben, die PCI-Daten sauber getrennt hält.
Und beide Protokolle stehen vor derselben brutalen Realität: Das Schwierige ist nicht die Verdrahtung der APIs.
Identität und das Startproblem der Berechtigungsnachweise: Wie sollen Händler und Agenten den Ausstellern solcher Nachweise vertrauen? Dafür braucht es Governance-Rahmen, Audits und womöglich staatliche Aufsicht. Ein Henne-Ei-Problem, denn die ersten Anwender brauchen eine Vertrauensinfrastruktur, die es noch nicht gibt.
Abdriftende Agenten und Halluzinationen: Wie stellen Sie sicher, dass Agenten ihre Mandate nicht überschreiten? Was passiert, wenn ein Agent „Laufschuhe unter 100 Dollar“ falsch versteht und 100 Paar kaufen will? Die Protokolle definieren Grenzen, aber sie über nichtdeterministische KI-Systeme hinweg durchzusetzen ist ungelöst.
Anbindung alter Zahlungssysteme: Der Handel läuft in der Praxis auf jahrzehntealter Infrastruktur mit obskuren Regeln. Authentifizierung per 3D Secure, PCI-DSS-Konformität, netzwerkspezifische Betrugsregeln, Rückbuchungen, KYC/AML-Vorgaben: All das setzt menschliche Aufsicht voraus. Das für autonome Agenten nachzurüsten ist kein Spezifikationsproblem, sondern eine politische Verhandlung mit etablierten Finanzinstituten.
Streitbeilegung: Wenn Ihr Agent das Falsche kauft, wer trägt den Verlust? Die Protokolle erzeugen Prüfpfade, legen aber keine Haftungsregeln fest. Dafür braucht es Verträge, Versicherungen und Präzedenzfälle, die es noch nicht gibt.
Einhaltung von Vorschriften: Was passiert, wenn das Verbraucherschutzrecht der EU auf autonome Agentenkäufe trifft? Was ist mit den Anforderungen der DSGVO an automatisierte Entscheidungen? Und das Recht welcher Jurisdiktion gilt, wenn ein Agent grenzüberschreitend einkauft?
Für einen Proof of Concept mit den Referenzimplementierungen kann jedes der beiden Protokolle Wochen bis Monate dauern. Für Produktionssysteme, die echtes Geld in großem Maßstab bewegen? Branchenanalysten schätzen hunderte Entwicklermonate, und das ist nur die technische Arbeit, ohne den rechtlichen und regulatorischen Rahmen.
Die Zahlungswege im Realitätscheck
ACP ist darauf ausgelegt, über verschiedene Zahlungsdienstleister zu funktionieren, aber der heute aktive Weg ist Stripes Shared Payment Token über die klassischen Kartennetze.[^7] Ein öffentliches Krypto-Gegenstück in ACP zu x402 von AP2 gibt es derzeit nicht.[^9] AP2 unterstützt Kryptowährungen ausdrücklich über seine Erweiterung x402 und ist architektonisch auf Karten, Echtzeit-Banküberweisungen und Stablecoins ausgelegt.
Das ist kein Nebendetail. Darin zeigen sich unterschiedliche Vorstellungen davon, was jetzt ausgeliefert werden muss und was später architektonisch möglich sein soll. ACP ist auf die Zahlungswege optimiert, die heute zählen: Kredit- und Debitkarten, abgewickelt über etablierte Anbieter. AP2 ist auf eine Zukunft hin gebaut, in der Stablecoins und Echtzeit-Banküberweisungen dominieren könnten.
Wer beide „zahlungsagnostisch“ nennt, verwechselt die Flexibilität einer Spezifikation mit dem, was heute funktioniert. Zahlungsagnostisch zu sein ist eine schwere Designvorgabe, die bestimmte Architekturentscheidungen bei der Verwaltung von Berechtigungsnachweisen und im Umgang mit Risiken erzwingt. Die aktuelle Implementierung von ACP bewegt sich klar im klassischen Kartengeschäft.
Der kryptografische Mehraufwand, über den niemand spricht
Die Mandatskette von AP2 verlangt bei jedem Schritt kryptografische Operationen: Intent Mandates signieren, Cart Mandates prüfen, Payment Mandates erzeugen und die gesamte Kette validieren. In Handelssystemen mit hohem Volumen, die tausende Transaktionen pro Sekunde verarbeiten, könnte dieser Mehraufwand brutal werden.
Die Dokumentation des Protokolls geht auf das Leistungsverhalten nicht ein: keine veröffentlichten Latenzbudgets, keine Durchsatz-Benchmarks, kein Wort zu Strategien für kryptografische Beschleunigung. Wie groß ist der Latenzaufschlag für die Prüfung der Mandate? Wie cachen Sie Prüfergebnisse, ohne die Sicherheit zu gefährden? Was passiert, wenn kryptografische Operationen mitten in einer Transaktion fehlschlagen?
Das sind keine hypothetischen Bedenken. Zahlungssysteme bauen auf Latenzbudgets im Millisekundenbereich. Kryptografische Prüfungen bei jedem Schritt könnten diese Budgets leicht sprengen und Architekturkompromisse zwischen Sicherheit und Leistung erzwingen, die in den Spezifikationen nicht vorkommen. Das ist redaktionelle Analyse, denn keines der beiden Protokolle hat Leistungszahlen veröffentlicht. Aber genau dieser Realitätscheck wird zählen, wenn diese Systeme unter Produktionslast geraten.
Das Minenfeld der Haftung
Beide Protokolle erzeugen Prüfpfade. Keines legt fest, wer tatsächlich das Risiko trägt, wenn etwas schiefgeht.
Googles Ankündigung stellt AP2 unter die Begriffe „Autorisierung, Echtheit, Verantwortlichkeit“, weist die Haftung aber niemandem zu. Auch die Unterlagen von ACP und Stripe drehen sich um die Mechanik der Integration, nicht um Haftungsregeln. Wenn ein Agent etwas Illegales kauft oder gegen Plattformregeln verstößt, wer haftet dann: der Nutzer mit den vagen Anweisungen, das KI-Unternehmen, dessen Modell sie falsch verstanden hat, der Händler, der die Bestellung angenommen hat, oder der Zahlungsdienstleister, der sie abgewickelt hat?
Wenn die Berechtigungsnachweise eines Agenten kompromittiert und für Betrug genutzt werden, wie läuft dann die Streitbeilegung? Beim klassischen Zahlungsbetrug gibt es jahrzehntelange Rechtsprechung und Rückbuchungsverfahren. Betrug mit Agenten ist völliges Neuland.
Die Protokolle behandeln Haftung als das Problem anderer, als Vertragsschicht, die man später klärt. Dabei ist Haftung der eigentlich schwierige Teil. Finanzinstitute werden Agentenzahlungen ohne klare Haftungsregeln nicht in großem Maßstab abwickeln. Händler werden Agentenbestellungen ohne einen Betrugsschutz, der nichtdeterministisches KI-Verhalten berücksichtigt, nicht annehmen. Und Nutzer werden Agenten keine Kaufbefugnis anvertrauen, wenn sie für jede Halluzination geradestehen müssen.
Warum das Etikett „offener Standard“ in die Irre führt
Beide Protokolle gelten als Open Source und neutral. Das GitHub-Repository von ACP steht unter der Lizenz Apache 2.0. AP2 ist ähnlich offen lizenziert. Technisch stimmt das: Die Spezifikationen sind öffentlich, und jeder kann sie implementieren.
Aber „offener Standard“ verwechselt die Transparenz einer Spezifikation mit praktischer Zugänglichkeit.
Der Implementierungsweg von ACP hängt stark an Stripe. Der vorrangig unterstützte Integrationspfad, die Referenzimplementierung, die Infrastruktur für den Shared Payment Token: alles Stripe. Theoretisch können Sie ACP auch mit anderen Zahlungsdienstleistern umsetzen, aber bei der Verwaltung der Berechtigungsnachweise und beim Onboarding der Händler sind Sie dann auf sich allein gestellt.
Die Offenheit von AP2 ist echter, bringt aber eine andere Einschränkung mit sich: Sie müssen eine Infrastruktur für Berechtigungsnachweise bauen oder anbinden, die es noch nicht gibt. Das Protokoll ist offen, die Vertrauensnetzwerke, die es zum Funktionieren braucht, sind es nicht.
In der Praxis heißt „offener Standard“ oft „offene Spezifikation mit proprietären Engpässen bei der Implementierung“.
Netzwerkeffekte und die Winner-take-most-Dynamik
Bei Zahlungen gilt Winner-take-most. Händler werden nicht liebevoll zwei Agentenprotokolle pflegen. Entweder verfestigt sich der Vorsprung von ACP oder die Koalition von AP2 zum Standard, und das andere bleibt als Legacy-Flickwerk zurück.
Sobald ein Protokoll bei Händlern, Agenten und Kartennetzwerken dominiert, werden die Wechselkosten untragbar. Händler sind ohnehin erschöpft davon, mehrere Zahlungsarten zu unterstützen, und wenig begeistert von der Aussicht auf mehrere Zahlungsprotokolle für Agenten. Kartennetzwerke wollen ein einziges Regelwerk für Agententransaktionen. KI-Plattformen wollen einmal integrieren und nicht parallele Implementierungen pflegen.
Zahlungsstandards zeigen eine stärkere Winner-take-most-Dynamik als die meisten Protokollbereiche. Hier werden nicht beide Protokolle friedlich nebeneinander verschiedene Nischen bedienen. Wahrscheinlicher ist, dass eines klar gewinnt und das andere verblasst, oder, schlimmer, dass sie das Ökosystem spalten und einen mühsamen Integrationsaufwand schaffen, der die Einführung des agentischen Handels insgesamt bremst.
Was passiert, wenn das in großem Maßstab live geht
Keines der Protokolle musste sich bisher unter realen, feindlichen Bedingungen bewähren. Die Etsy-Integration von ACP läuft, ist aber winzig: einzelne Artikel, begrenzt viele Händler, nur USA. AP2 hat kein einziges Deployment in Produktion.
Warten Sie, bis Betrügerringe das Verhalten der Agenten ausnutzen. Warten Sie, bis Agenten über Jurisdiktionen hinweg Rechtsverstöße auslösen. Warten Sie, bis prominente Pannen (Agenten, die Artikel mit Verkaufsbeschränkungen kaufen, betrügerische Transaktionen ausführen oder Käufe tätigen, die gegen Sanktionen verstoßen) PR-Albträume und Anhörungen im Kongress nach sich ziehen.
Die Protokolle sind optimistische Infrastruktur für eine Welt, die es so noch nicht ganz gibt. Sie setzen voraus, dass sich Agenten vernünftig verhalten, dass Händler neue Risikomodelle übernehmen, dass Regulierungsbehörden autonomen Handel akzeptieren und dass Nutzer der KI eine Kaufbefugnis anvertrauen.
Das sind gewaltige Annahmen.
Der ehrliche Zeitplan
OpenAI hat eine Live-Integration mit harten Einschränkungen. Die Ausweitung auf Warenkörbe mit mehreren Artikeln, internationale Händler und mehrere Zahlungsdienstleister wird Quartale dauern, nicht Wochen. Jede Ausweitung bringt neue Sonderfälle ans Licht, die Überarbeitungen des Protokolls verlangen.
Google hat eine fertige Spezifikation und kein einziges Produkt. Eine AP2-Integration für Endkunden braucht nicht nur Code, sondern auch Vertrauensinfrastruktur, Händler-Onboarding, Vereinbarungen mit den Zahlungsnetzwerken und regulatorische Klarheit. Ein nennenswerter Einsatz ist damit frühestens 2026 zu erwarten.
Das „demnächst“ für die Shopify-Integration ist Marketing, bis es tatsächlich läuft. Mehrere Medien wiederholen die Ankündigung, aber die Zeitpläne bleiben vage.
Was das tatsächlich bedeutet
Beide Protokolle sind ehrgeizige Wetten darauf, dass die Infrastruktur für autonomen Handel jetzt gebaut werden muss, bevor sich die Anwendungsfälle klar abzeichnen. Das ist entweder visionär oder verfrüht, je nachdem, wie schnell KI-Agenten Kaufentscheidungen zuverlässig bewältigen können.
Der optimistische Fall: Ein Protokoll gewinnt, setzt sich breit durch und ermöglicht wirklich neue Formen des Handels, in denen Agenten Großeinkäufe aushandeln, Warenkörbe über mehrere Anbieter zusammenstellen und komplexe delegierte Transaktionen ausführen. Der Handel wird effizienter, persönlicher und reibungsärmer.
Der realistische Fall: Beide Protokolle kommen schwer in Gang, weil Vertrauensinfrastruktur, Haftungsregeln und regulatorische Klarheit noch fehlen. Händler warten auf einen ROI-Nachweis, bevor sie in die Integration investieren. Zahlungsnetzwerke gehen vorsichtig vor, weil die Betrugsrisiken unbekannt sind. Regulierungsbehörden verschleppen die Genehmigung, bis der Verbraucherschutz geklärt ist.
Der pessimistische Fall: Fragmentierung. ACP und AP2 spalten das Ökosystem, was den Händlern Integrationsaufwand und den Nutzern Verwirrung beschert. Die Protokolle entwickeln sich inkompatibel weiter. KI-Plattformen bauen proprietäre Erweiterungen. Am Ende stehen wir genau vor der fragmentierten Landschaft, die beide Protokolle angeblich verhindern wollen.
Die Agenten kommen, irgendwann. Ob sie über standardisierte Protokolle kaufen oder über proprietäre Systeme von dem, der sich am schnellsten bewegt, ist noch völlig offen.
Und die technischen Schulden, die in der Eile des Auslieferns entstehen? Die werden so oder so fällig.
Jargon-Decoder
Intent Mandate: Kryptografisch signierter Vertrag, der die ursprüngliche Anfrage des Nutzers und die Bedingungen für das Handeln des Agenten festhält (AP2)
Cart Mandate: Nicht abstreitbarer Beleg über die konkreten Artikel und Preise, die zum Kauf freigegeben wurden (AP2)
Payment Mandate: Minimaler Berechtigungsnachweis, der an Zahlungsnetzwerke geht und die Beteiligung eines Agenten signalisiert (AP2)
Shared Payment Token (SPT): Stripes Mechanismus, um Zahlungsdaten sicher über KI-Agenten weiterzugeben (ACP)
Delegated Payment Spec: Die Spezifikation von ACP dafür, wie Zahlungsdienstleister von Agenten ausgelöste Zahlungen ermöglichen können
Aus dem Englischen übersetzt: zum Originalbeitrag