Zahlungen, die von Software-Agenten initiiert werden, sind in weniger als einem Jahr von der Demo zum Protokoll geworden. Google kündigte am 16. September 2025 das Agent Payments Protocol (AP2) an, ein offenes Protokoll für die sichere Initiierung agentengeführter Zahlungen über Plattformen hinweg, als Erweiterung der Agent2Agent-Arbeit und des Model Context Protocol. Am 28. April 2026 gab Google die Übergabe von AP2 an die FIDO Alliance bekannt und veröffentlichte Version 0.2, die Human-Not-Present-Zahlungen ergänzt: autonome Ausführung gegen vorab autorisierte Nutzeranweisungen. Parallel deckt der Agentic-Checkout-Pfad von OpenAI und Stripe (ACP) die Ausführung in chatartigen Flows ab, und Googles UCP übernimmt Discovery und Warenkörbe.
Für Risikoteams ist das nützliche Framing: Agentic Commerce 2026 ist ein Stack, kein Protokoll. Discovery und Warenkorb-Orchestrierung sitzen in einer Schicht, Autorisierung und Vertrauen in einer zweiten, die Zahlungsausführung in einer dritten. Das Risiko konzentriert sich in der Mitte. Klassischer Card-not-present-Betrug dreht sich um gestohlene Zugangsdaten; agentischer Betrug dreht sich um Autoritätsambiguität: Hat der Nutzer genau diesen Warenkorb autorisiert, zu diesem Betrag, bei diesem Händler, zu diesem Zeitpunkt. Ein Agent, der behauptet “mein Nutzer wollte das”, ist als Beweis wertlos. Die gesamte Designfrage lautet, was diese Behauptung ersetzt.
Mandate sind die Beweiskette
Die Antwort von AP2 sind manipulationsresistente Mandate, transportiert als W3C Verifiable Credentials. Drei davon bilden eine Kette: ein Intent Mandate, das festhält, was der Nutzer verlangt hat und unter welchen Einschränkungen, ein Cart Mandate, das festhält, was der Agent tatsächlich ausgewählt hat, und ein Payment Mandate, das festhält, was Händler und Netzwerk abgebucht haben. Zusammen bilden sie einen kryptografisch verifizierbaren Nachweis der Autorität hinter der Transaktion, entworfen, um Händlern und Zahlungsdienstleistern einen Beleg der Nutzerautorisierung zu geben statt der Selbstauskunft eines Agenten.
Das operativ entscheidende Designdetail ist, dass Mandate Umfang, Absicht und Einschränkung kodieren. Ein Händler kann verifizieren, dass der Agent innerhalb des vom Nutzer freigegebenen Rahmens geblieben ist: Budget, Produktkategorie, Marke, Timing. AP2 ist zahlungsagnostisch, ausgerichtet auf Karten, Überweisungen, Stablecoins und andere Schienen, und es ist bewusst weder der Warenkorb noch die Checkout-UX. Es ist die Schicht für Autorisierung und Haftungsbeweise darunter, und genau auf dieser Schicht werden Streitfälle ausgetragen.
Die vier relevanten Betrugsszenarien
Die Szenarien, gegen die es sich zu bauen lohnt, unterscheiden sich vom Standard-CNP-Katalog:
- Nicht autorisierte Autonomie. Der Agent schließt einen Kauf ab, den der Nutzer in dieser konkreten Form nicht wollte. Das ist der Basisgenerator für Streitfälle, und die Mandatskette existiert vor allem, um ihn aufzulösen.
- Scope Drift und Warenkorb-Manipulation. Der Agent stellt, ob durch Fehler, Prompt-Manipulation oder eine feindliche Händleroberfläche, einen Warenkorb zusammen, der Budget-, Kategorie- oder Markengrenzen überschreitet. Die Erkennung ist ein Vergleichsproblem: Cart Mandate gegen Intent Mandate.
- Replay und Substitution. Eine früher gültige Autorisierung, wiederverwendet oder verändert für einen anderen Warenkorb oder Händler. Signierte Mandate binden den Beweis an den Transaktionskontext, und genau das macht dies materiell schwerer als das Replay einer gespeicherten Credential.
- Missbrauch von Human-Not-Present. Version 0.2 macht autonome Ausführung zum Feature, und das Feature ist das Risiko. Ist zum Ausführungszeitpunkt kein Mensch in der Schleife, tragen vorab autorisierte Limits und nachgelagerte Auditierbarkeit die gesamte Kontrolllast.
Kontrollen für Händler und Issuer
Auf Händlerseite besteht der Kontroll-Stack aus Mandatsverifikation, Policy-Prüfungen und Beweisaufbewahrung. Vor dem Capture wird bestätigt, dass der Warenkorb dem signierten Intent entspricht und das Payment Mandate konsistent mit dem Cart Mandate ist; bei Abweichung wird abgelehnt oder ein Step-up für eine frische Nutzerbestätigung ausgelöst. Aufbewahrte Mandatsbeweise adressieren den Streitfall “Agent hat übergriffen” direkt, denn der Händler kann zeigen, dass der Kauf innerhalb der erklärten Einschränkungen des Nutzers lag.
Auf Issuer-Seite ist der Gewinn die Attribution. Heute entscheidet ein Issuer auf Basis von Händler-Deskriptordaten und eigenen Verhaltensmodellen; eine Kette im AP2-Stil ergänzt kryptografische Belege für Nutzerabsicht, Agentenauswahl und Zahlungsautorisierung. Das stützt schärfere Autorisierungsentscheidungen, bessere Betrugstriage und sauberere Dispute-Bearbeitung, wenn ein Karteninhaber behauptet, der Agent habe außerhalb der Anweisungen gehandelt. Das realistische Adoptionsmuster ist asymmetrisch: Mandatsbeweise werden, wo vorhanden, als Signal höheren Vertrauens behandelt, und wo sie fehlen, greifen die bestehenden Authentifizierungs- und Betrugsmodelle. Nichts am Protokoll macht diese Modelle überflüssig; es liefert ihnen ein stärkeres Signal.
Bauen, während die Standards sich setzen
Der Stack hat zwei konkurrierende Routen, Googles UCP plus AP2 unter FIDO-Governance und den Ausführungspfad von OpenAI und Stripe, und für Händler und Issuer gewinnt die Kombination, die Autorisierungsbeweise, Betrugskontrolle und Conversion zusammen liefert. Um mit dem Bauen zu beginnen, muss man keinen Gewinner wählen. Die dauerhaften Investitionen sind protokolltolerant: ein Verifikationsservice, der Credential-Ketten validieren und die Konsistenz von Warenkorb und Intent prüfen kann; eine Policy-Engine, die Limits pro Agent für Betrag, Kategorie und Frequenz ausdrückt, verdrahtet mit der bestehenden Velocity- und Limit-Infrastruktur; Telemetrie, die agenteninitiierten von menschlich initiiertem Traffic trennt, damit die Betrugsmodelle den Unterschied lernen können, statt über ihn zu mitteln; und Dispute-Workflows, die Verifiable Credentials als Beweismittel aufnehmen können statt Screenshots.
Die zu vermeidenden Fehlermodi sind ebenso konkret. Agenten-Traffic als Bot-Traffic zu behandeln und zu blockieren wirft die beweistragende Kohorte weg und drängt Agenten dazu, sich als Menschen auszugeben. Agentenbehauptungen ohne Mandatsverifikation zu akzeptieren stellt genau das Autoritätsambiguitätsproblem wieder her, zu dessen Lösung die Protokolle gebaut wurden. Und die Human-Not-Present-Kategorie zu ignorieren, bis die Volumina das Thema erzwingen, bedeutet, Limits und Audit Trail unter Incident-Druck zu entwerfen. Die Protokolle sind jung; die Disziplin, die sie verlangen, beweisbare Autorisierung und Beweise, die einen Streitfall überstehen, ist dieselbe, die Payment-Risikoteams bereits kennen. Wer für die Beweise baut, für den wird die Protokollwahl zum Detail.
Häufige Fragen
Sollten wir agenteninitiierten Traffic blockieren, bis die Standards reifen?
Blockieren ist verlockend und weitgehend zwecklos, denn blockierte Agenten treten schlicht als gewöhnliche Kunden über den normalen Checkout auf, und das Signal, dass es überhaupt Agenten sind, geht verloren. Die bessere Position ist, Agenten-Traffic zu unterscheiden, zu scoren und Transaktionen mit Beweismaterial als die sicherere Kohorte zu behandeln. Ein Kauf, der mit einer verifizierbaren Mandatskette eintrifft, bietet mehr Arbeitsmaterial als eine typische Card-not-present-Bestellung, nicht weniger.
Wer haftet, wenn ein Agent sein Mandat überschreitet?
Die formale Haftung folgt weiterhin den Netzwerkregeln und der anwendbaren Zahlungsregulierung; die Protokolle schreiben diese nicht um. Was die Mandatskette ändert, ist, wer was beweisen kann. Stimmt der Warenkorb mit dem signierten Intent Mandate überein, ist die Nutzerautorisierung belegbar und der Einwand 'mein Agent ist entgleist' bricht zusammen. Hat ein Händler einen Warenkorb akzeptiert, der dem Intent Mandate widerspricht, ist seine Dispute-Position schwach, und er sollte damit rechnen, den Verlust zu tragen. Die Beweisqualität wird diese Fälle lange vor der Rechtsprechung entscheiden.
Was bedeutet die Übergabe an die FIDO Alliance für die Adoptionsplanung?
Der Wechsel von AP2 aus einem Ein-Anbieter-Projekt in die FIDO-Governance im April 2026 signalisiert, dass die Vertrauensschicht als gemeinsame Infrastruktur gedacht ist, nicht als Google-Produkt, was das strategische Risiko eines Builds dagegen senkt. Eine Garantie, dass AP2 den Stack gewinnt, ist es nicht, und der Ausführungspfad von OpenAI und Stripe entwickelt sich parallel. Der kluge Build ist protokolltolerant: eine Fähigkeit zur Mandatsverifikation und Beweisverarbeitung, die sich auf die Credential-Formate richten lässt, die in den eigenen Kanälen Volumen erreichen.