Agent Payments Protocol (AP2)

Agent Payments Protocol (AP2) ist ein offenes Protokoll, mit dem KI-Agenten im Auftrag eines Menschen sicher und nachvollziehbar bezahlen können. Google hat es am 16. September 2025 vorgestellt, gemeinsam mit mehr als 60 Partnern aus der Zahlungs- und Handelsbranche. Kern des Protokolls sind sogenannte Mandate: kryptografisch signierte, fälschungssichere digitale Nachweise, die festhalten, was der Nutzer wollte, was der Agent in den Warenkorb gelegt hat und womit bezahlt wird.

AP2 versteht sich als Erweiterung des Agent2Agent-Protokolls (A2A) und des Model Context Protocol (MCP). Es legt keine eigene Zahlungsart fest, sondern beschreibt, wie Shopping-Agent, Händler, Wallet-Anbieter und Zahlungsabwickler Beweise austauschen. Der Quellcode, die Spezifikation und Referenzimplementierungen liegen unter Apache-2.0-Lizenz auf GitHub. Dieser Eintrag erklärt, welches Problem AP2 löst, wie die Mandate funktionieren, welche Rollen beteiligt sind und was das für Shops bedeutet.

Welches Problem AP2 löst

Bisherige Zahlungssysteme gehen davon aus, dass ein Mensch auf „Jetzt kaufen“ klickt. Sobald ein Agent diesen Klick übernimmt, fehlen drei Dinge. Google benennt sie in der Ankündigung als Autorisierung, Authentizität und Verantwortlichkeit. Autorisierung: Wie beweist der Agent, dass der Nutzer genau diesen Kauf erlaubt hat? Authentizität: Wie weiß der Händler, dass die Anfrage dem echten Willen des Nutzers entspricht? Verantwortlichkeit: Wer haftet, wenn eine Transaktion falsch oder betrügerisch war?

Ohne eine gemeinsame Antwort darauf müsste jeder Händler, jeder Zahlungsdienstleister und jede Bank eigene Regeln für Agenten erfinden. Das Ergebnis wären Insellösungen, die sich gegenseitig nicht vertrauen. AP2 schlägt stattdessen ein zahlungsartneutrales Rahmenwerk vor, mit dem Nutzer, Händler und Zahlungsanbieter untereinander handeln können, ohne dass jede Seite die KI der anderen Seite durchschauen muss. Das ist im Kern die Idee von Agentic Commerce: Der Agent handelt, der Mensch bleibt verantwortlich.

Warum das für Shops relevant ist

Für einen Onlineshop ist die Frage nicht, ob Agenten einkaufen werden, sondern wie man ihre Bestellungen von Betrug unterscheidet. Ein Agent, der mit gestohlenen Kartendaten bestellt, sieht in den Logs zunächst aus wie ein Agent, der im Auftrag eines zufriedenen Stammkunden handelt. AP2 gibt dem Händler einen signierten Beleg, der die Bestellung an eine konkrete Nutzerentscheidung bindet. Das senkt das Risiko von Rückbuchungen und macht Streitfälle überprüfbar.

Die Mandate: Intent, Cart und Payment

Das zentrale Konzept von AP2 sind Mandate. Google beschreibt sie als fälschungssichere, kryptografisch signierte digitale Verträge, die als überprüfbarer Beweis für die Anweisungen eines Nutzers dienen. Technisch handelt es sich um Verifiable Digital Credentials, also signierte Datenobjekte, deren Echtheit jeder Beteiligte prüfen kann. Die Signatur des Nutzers entsteht laut Spezifikation über einen hardwaregestützten Schlüssel auf seinem Gerät mit Authentifizierung in der Sitzung, etwa per Passkey oder Biometrie.

Intent Mandate: Der Auftrag

Das Intent Mandate ist die signierte Fassung dessen, was der Nutzer will. Es enthält nicht nur Produktwünsche, sondern auch Leitplanken: welche Zahlungsarten erlaubt sind, wie viel ausgegeben werden darf und wie lange der Auftrag gilt. Wichtig ist das Feld, in dem der Agent seine Interpretation des Auftrags in natürlicher Sprache festhält. Der Nutzer signiert also nicht nur seine Worte, sondern auch das, was der Agent daraus gemacht hat. Missverständnisse werden damit früh sichtbar, nicht erst nach der Lieferung.

Cart Mandate: Der Warenkorb

Das Cart Mandate entsteht, nachdem der Agent einen konkreten Warenkorb zusammengestellt hat. Es wird zweistufig signiert. Zuerst signiert der Händler und garantiert damit, dass er die Artikel zu diesem Preis liefern kann. Danach signiert der Nutzer, oder in delegierten Szenarien der Agent im Rahmen des Intent Mandates. Das Ergebnis ist ein unveränderlicher Datensatz aus Artikeln und Preis. Weder Agent noch Händler können ihn nachträglich anpassen, ohne dass die Signatur bricht.

Payment Mandate: Das Signal an die Bank

Das Payment Mandate richtet sich nicht an den Händler, sondern an das Zahlungssystem dahinter: Netzwerke wie Mastercard oder Visa und die kartenausgebenden Banken. Es teilt mit, dass ein Agent an der Transaktion beteiligt war und ob der Mensch im Moment der Zahlung anwesend war. Banken können diese Information in ihre Risikobewertung einfließen lassen. Bisher sind Agententransaktionen für Issuer unsichtbar; mit dem Payment Mandate bekommen sie einen eigenen, erkennbaren Typ.

Ein Hinweis zur Terminologie: Die Projektseite ap2-protocol.org beschreibt inzwischen auch ein „Checkout Mandate“ mit offener und geschlossener Phase, das Intent und Cart zu einem Objekt zusammenführt. Die Grundidee bleibt gleich: eine signierte Absicht vor dem Kauf, ein signierter Warenkorb beim Kauf, ein Zahlungsnachweis für das Netzwerk.

Rollen im Protokoll

AP2 ist bewusst rollenbasiert aufgebaut. Jede Partei sieht nur die Daten, die sie für ihre Aufgabe braucht. Die Spezifikation definiert sechs Rollen.

• Nutzer: Der Mensch, der einen Einkaufsauftrag an seinen Agenten delegiert.
• Shopping Agent: Die KI-Oberfläche, mit der der Nutzer direkt spricht. Sie versteht den Bedarf, sucht Produkte und holt die signierte Autorisierung ein. Mehr zu dieser Agentenklasse im Eintrag KI-Agenten.
• Credentials Provider: Eine spezialisierte Instanz, die Zahlungsdaten sicher verwaltet und die Zahlung ausführt, zum Beispiel eine digitale Wallet. Der Shopping Agent sieht die Kartennummer nie.
• Merchant Endpoint: Eine Weboberfläche, ein MCP-Endpunkt oder ein eigener Agent des Händlers, der eine Zahlung erwartet.
• Merchant Payment Processor: Der Zahlungsabwickler des Händlers, der die Autorisierungsnachricht für das Zahlungsnetzwerk baut. In der Praxis ist das meist der Payment Service Provider des Shops.
• Netzwerk und Issuer: Das Zahlungsnetzwerk und die Bank, die dem Nutzer die Zahlungskarte ausgestellt hat.

Diese Trennung ist der Grund, warum AP2 als datensparsam gilt. Der Händler bekommt das Cart Mandate, aber keine Rohdaten der Karte. Der Credentials Provider bekommt die Zahlungsanweisung, aber nicht die ganze Chat-Historie des Nutzers. Das Netzwerk bekommt das Payment Mandate mit Risikosignalen, aber keine Produktdetails.

Human-present und Human-not-present

AP2 unterscheidet zwei Szenarien, die sich im Ablauf deutlich unterscheiden.

Mensch anwesend

Googles Beispiel aus der Ankündigung: Du bittest einen Agenten, neue weiße Laufschuhe zu finden. Die Anfrage landet in einem Intent Mandate. Der Agent sucht, stellt einen Warenkorb zusammen und zeigt ihn dir. Deine Freigabe signiert das Cart Mandate. Erst dann fließt Geld. Der Mensch sieht also den finalen Warenkorb und bestätigt ihn aktiv, ähnlich wie heute beim Bezahlen mit einer Wallet auf dem Smartphone.

Mensch nicht anwesend

Zweites Beispiel: „Kauf die Konzerttickets, sobald der Vorverkauf startet.“ Hier signierst du vorab ein ausführliches Intent Mandate mit Preislimit, Zeitfenster und weiteren Bedingungen. Sobald die Bedingungen eintreten, darf der Agent selbst ein Cart Mandate erzeugen und den Kauf abschließen. Die Spezifikation sieht vor, dass der Händler eine Bestätigung des Menschen erzwingen kann, wenn er unsicher ist, ob der Warenkorb den Auftrag erfüllt. Delegation ist also möglich, aber nicht grenzenlos.

Zahlungsarten und die x402-Erweiterung

AP2 ist zahlungsartneutral angelegt. Die Roadmap der Spezifikation beginnt in Version 0.1 mit Pull-Verfahren, also Kredit- und Debitkarten, und soll in Version 1.x Push-Verfahren wie Banküberweisungen und E-Wallets ergänzen. Als Beispiele für spätere Erweiterungen nennt die Projektseite Echtzeit-Überweisungen wie UPI und PIX sowie digitale Währungen.

Parallel zur Ankündigung hat Google gemeinsam mit Coinbase, der Ethereum Foundation, MetaMask und weiteren Organisationen die A2A x402-Erweiterung veröffentlicht. Sie überträgt die AP2-Konstrukte auf Krypto-Zahlungen und Stablecoins und wird von Google als produktionsreife Lösung für agentenbasierte Krypto-Zahlungen bezeichnet. Der Name verweist auf den HTTP-Statuscode 402 „Payment Required“, der seit Jahrzehnten reserviert, aber nie standardisiert genutzt wurde.

Partner und Lizenz

Google nennt in der Ankündigung über 60 Organisationen, darunter Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, Mysten Labs, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International und Worldpay. Die Mischung ist bezeichnend: Kartennetzwerke, Zahlungsabwickler, Marktplätze, Betrugsprävention und Web3-Anbieter sitzen am selben Tisch. Für ein Protokoll, dessen Nutzen von Netzwerkeffekten abhängt, ist das die wichtigste Voraussetzung.

Das Protokoll steht unter Apache License 2.0 auf GitHub. Dort liegen Spezifikation, Ablaufdiagramme, FAQ, ein Python-SDK mit Pydantic-Modellen und JSON-Schemas sowie Beispielszenarien, etwa für Kartenzahlungen mit anwesendem Nutzer. Laut Projektseite läuft die weitere Standardisierung in Arbeitsgruppen der FIDO Alliance, die auch hinter Passkeys steht.

AP2 im Protokoll-Stack: A2A, MCP und UCP

AP2 ist kein Konkurrent zu A2A oder MCP, sondern setzt darauf auf. A2A regelt, wie Agenten miteinander sprechen, MCP, wie ein Agent Werkzeuge und Datenquellen anbindet. AP2 ergänzt beide um die Frage, wie ein Agent verbindlich bezahlt. Die Spezifikation bezeichnet sich selbst als nicht-proprietäre, offene Erweiterung für bestehende und künftige A2A- und MCP-Protokolle.

Besonders interessant ist das Zusammenspiel mit dem Universal Commerce Protocol (UCP). UCP beschreibt den gesamten Einkaufsprozess zwischen Agent und Händler, von der Produktsuche bis zum Checkout. Für den Zahlungsschritt verweist UCP ausdrücklich auf AP2: Die Projektseite ucp.dev nennt eingebaute Unterstützung für AP2, A2A und MCP und beschreibt sichere Zahlungen über AP2-Zahlungsmandate und Verifiable Credentials als Sicherheitsmuster. Wer UCP für seinen Shop plant, landet beim Bezahlen also fast zwangsläufig bei AP2.

Realbeispiel: AP2 in Gemini Spark

Lange war AP2 ein Spezifikationsprojekt ohne Endkundenprodukt. Das änderte sich auf der Google I/O am 19. Mai 2026. In einem Beitrag zum neuen Universal Cart kündigte Google an, AP2 in den kommenden Monaten in eigene Produkte zu bringen, beginnend mit Gemini Spark.

Die beschriebene Nutzung entspricht genau dem Intent-Mandate-Gedanken: Der Nutzer legt strikte Leitplanken für agentische Zahlungen fest, nämlich welche Marken und Produkte der Agent kaufen darf und wie viel er ausgeben darf. Google spricht von fälschungssicheren digitalen Mandaten und datenschutzfreundlicher Technik, die zwischen Nutzer, Händler und Zahlungsabwickler eine transparente, überprüfbare Verbindung herstellt. Der Agent handle damit nachweislich immer im Auftrag des Nutzers.

Für Händler heißt das: Agenten mit AP2-Mandaten werden nicht nur ein Protokollentwurf bleiben, sondern über Googles Oberflächen real im Checkout auftauchen. Im selben Beitrag beschreibt Google die Ausweitung von UCP von den USA nach Kanada und Australien und später nach Großbritannien. Ein Zeitplan für den DACH-Raum wurde dort nicht genannt.

Was AP2 für Shopware-Shops bedeutet

Heute musst du in einem Shopware-Shop nichts umbauen, um AP2 zu unterstützen. Es gibt noch kein offizielles Shopware-Modul, und die meisten Zahlungsanbieter sind erst dabei, ihre Rollen als Credentials Provider oder Merchant Payment Processor umzusetzen. Drei Dinge lohnen sich trotzdem jetzt.

1. Zahlungsdienstleister befragen: Adyen, PayPal, Worldpay und Mastercard gehören zu den Erstpartnern. Wer einen dieser Anbieter nutzt, bekommt AP2-Unterstützung voraussichtlich über ein Update des bestehenden Payment-Plugins, nicht über ein eigenes Projekt.
2. Strukturierte Produktdaten pflegen: Ein Cart Mandate braucht eindeutige Artikel, Preise, Währung und Lieferbedingungen. Lücken in den Produktdaten fallen Agenten sofort auf, weil sie im Gegensatz zu Menschen nicht raten.
3. Checkout-Logik API-fähig halten: Ein Merchant Endpoint kann laut Spezifikation ein MCP-Endpunkt sein. Shops, deren Warenkorb- und Checkout-Funktionen sauber über die Store-API erreichbar sind, haben hier einen Vorsprung.

Das Protokoll ist jung, die Versionsnummer 0.1 spricht für sich. Konzepte können sich noch ändern, wie die Umbenennung Richtung Checkout Mandate zeigt. Die Richtung ist aber klar: Agenten brauchen einen Beleg, wofür sie bezahlen dürfen, und AP2 ist derzeit der einzige Vorschlag mit dieser Breite an Zahlungspartnern.

Häufige Fragen

Ist AP2 ein eigenes Zahlungsverfahren?

Nein. AP2 ersetzt weder Kartenzahlung noch PayPal noch Überweisung. Es beschreibt, wie der Nachweis einer Nutzerentscheidung an die bestehenden Verfahren angehängt wird. Die Zahlung selbst läuft weiterhin über Netzwerk, Issuer und Zahlungsabwickler.

Kann ein Agent mit AP2 ohne mein Wissen Geld ausgeben?

Nur innerhalb dessen, was du vorher signiert hast. Bei anwesendem Nutzer bestätigst du den finalen Warenkorb selbst. Bei delegierten Käufen setzt das Intent Mandate Preisgrenzen, Bedingungen und eine Gültigkeitsdauer. Der Händler kann außerdem eine Bestätigung einfordern, wenn er unsicher ist.

Was ist der Unterschied zwischen AP2 und UCP?

UCP deckt den gesamten Einkauf zwischen Agent und Händler ab, von der Suche bis zur Bestellung. AP2 konzentriert sich auf den Zahlungsschritt und die signierten Mandate. UCP verweist für sichere Zahlungen ausdrücklich auf AP2.

Unterstützt AP2 Krypto und Stablecoins?

Ja, über die A2A x402-Erweiterung, die Google zusammen mit Coinbase, der Ethereum Foundation und MetaMask veröffentlicht hat. Der Kern von AP2 startet mit Kartenzahlungen; Überweisungen und Wallets sind für spätere Versionen vorgesehen.

Wann kommt AP2 in echten Produkten an?

Google hat am 19. Mai 2026 angekündigt, AP2 in den kommenden Monaten zuerst in Gemini Spark einzuführen. Händlerseitige Unterstützung hängt vom jeweiligen Zahlungsanbieter ab.