Eine KI kann eine kostenpflichtige API nicht allein deshalb „bezahlen“, weil ein Server mit HTTP 402 antwortet. Sie muss Preis und Zahlungsanforderung verstehen, die Zahlung innerhalb klarer Grenzen signieren und das Ergebnis mit Ressourcenzugriff, Logs und Buchhaltung verbinden. Für diese technische Schicht nahm die x402 Foundation am 14. Juli 2026 ihre Arbeit auf.
Das Wichtigste in 30 Sekunden
- Neu: Die x402 Foundation hat am 14. Juli 2026 ihre Arbeit aufgenommen. Coinbase übertrug das Protokoll vollständig in die offene Governance; die Foundation nennt 40 Mitglieder.
- Technik: HTTP 402 bleibt ein reservierter Statuscode. x402 ergänzt einen maschinenlesbaren Ablauf für Zahlungsanforderung, Signatur, Prüfung, Settlement und Ressourcenzugriff.
- Grenze: Offene Governance schafft weder allgemeinen Browser-Support noch automatisch Marktreife oder Rechtskonformität.
- Praxis: Ein Pilot braucht Budgetgrenzen, freigegebene Empfänger, Idempotenz, Logs und eine fallbezogene Rechts-, Steuer- und Buchhaltungsprüfung.
Was sich am 14. Juli geändert hat
Neu ist nicht der Statuscode 402, sondern die Organisation hinter x402. Die Linux Foundation teilte am 14. Juli 2026 mit, dass die x402 Foundation ihre Arbeit aufgenommen hat. Coinbase hat das Protokoll vollständig in die offene Governance eingebracht; die Foundation nennt 40 Mitglieder und will Internetzahlungen für Anwendungen und KI-Agenten herstellerneutral weiterentwickeln.
Entwicklerteams bekommen damit eine gemeinsame Grundlage für Implementierungen. Das heißt noch nicht, dass jedes Mitglied bereits ein fertiges Produkt anbietet. Wie sicher, teuer oder verbreitet x402 im Betrieb ist, bleibt offen.
HTTP 402 ist die Tür, x402 beschreibt den Ablauf dahinter
RFC 9110 führt 402 Payment Required als reservierten Statuscode für künftige Nutzung. Mehr legt der Standard an dieser Stelle nicht fest: keine Zahlungsdaten, keine Wallet, keine API für einen Dienstleister und kein Settlement.
x402 füllt diese Lücke. Die Protokollschicht beschreibt, wie ein Server Zahlungsanforderungen maschinenlesbar sendet und ein Client mit einer signierten Zahlungsnutzlast erneut anfragt. Allgemeiner Browser-Support oder eine IETF-Standardisierung folgen daraus nicht.
Eine Zahlung in sechs Schritten
Der Basisfluss bleibt nah an der HTTP-Ressource und kommt ohne separaten Checkout aus:
- Ein Client fordert eine Ressource an. Das kann eine App, ein Agent oder ein anderer programmatischer Dienst sein; auf der anderen Seite steht etwa eine API.
- Der Server antwortet mit 402 und Zahlungsanforderungen. Die Antwort enthält maschinenlesbare Zahlungsbedingungen. Cloudflare verwendet in seiner eigenen Implementierung zusätzlich einen
PAYMENT-REQUIRED-Header. - Der Client prüft die Anforderung. Hier fällt die Produktentscheidung: Darf dieser Client diesen Betrag, diesen Empfänger und dieses Scheme verwenden?
- Der Client signiert einen Payment Payload und wiederholt die Anfrage. Die Nutzlast wird im
PAYMENT-SIGNATURE-Header übertragen. - Der Server verifiziert und stößt das Settlement an. Er kann die Prüfung lokal durchführen oder einen Facilitator einbinden.
- Der Client erhält die Ressource oder eine Fehlermeldung. Das Ergebnis kann im
PAYMENT-RESPONSE-Header mitgegeben werden.
x402 entscheidet nicht, ob ein Client zahlen darf. Das Protokoll transportiert eine signierte Zahlungsanforderung; Limits, freigegebene Empfänger und Regeln für Fehlversuche gehören in die Anwendung.
Client, Scheme und Facilitator: Die Ebenen nicht vermischen
HTTP 402
- Aufgabe
- Signalisiert eine Zahlungsanforderung an einer HTTP-Ressource.
- Offen bleibt
- Payload-Format, Wallet, Settlement und Browser-Support.
x402-Protokoll
- Aufgabe
- Beschreibt Zahlungsanforderungen, Header und den Request-/Response-Ablauf.
- Offen bleibt
- Die konkrete Zahlungsmethode und die rechtliche Einordnung.
Payment Scheme
- Aufgabe
- Regelt die konkrete Zahlungslogik.
- Abhängig von der Umsetzung
- Unterstützte Assets, Netze und Rückerstattungen.
Netzwerk und Asset
- Aufgabe
- Bestimmen die konkrete technische Abwicklung.
- Je Integration verschieden
- Die Kombination aus Netzwerk und Asset.
Wallet
- Aufgabe
- Hält Schlüssel und erzeugt gegebenenfalls eine Signatur.
- Aufgabe der Anwendung
- Budgetpolitik, Empfängerprüfung und Buchungstexte.
Facilitator
- Aufgabe
- Kann Payloads prüfen und Onchain-Settlement für den Server ausführen.
- Aufgabe des Betreibers
- Sicherheit, Verfügbarkeit und rechtliche Einordnung.
Ein Facilitator ist laut x402-Dokumentation optional, aber empfohlen. Für lokale Schnellstarts und Testnetze steht ein öffentlicher Dienst bereit. Für Mainnet-Szenarien verweist die Dokumentation dagegen auf kompatible Produktionsanbieter, Self-Hosting oder Self-Facilitation. „Nicht-kustodial“ beschreibt dabei nur die technische Rolle im Protokoll, nicht die rechtliche Einordnung.
Ein Scheme ist kein Marktversprechen
Die Foundation nennt ein Zielbild von traditionellen Karten bis Stablecoins. Eine fertige Spezifikation für jede Zahlungsart ist das nicht: Konkrete Implementierungen kombinieren jeweils Scheme, Netzwerk und Asset.
Cloudflare zeigt eine eigene x402-Integration mit PAYMENT-REQUIRED, PAYMENT-SIGNATURE, lokaler oder Facilitator-Prüfung und PAYMENT-RESPONSE. Sie unterscheidet Schemes wie exact und upto sowie netz- und tokenbezogene Konfigurationen. Für exact nennt die Dokumentation als konkretes, nicht allgemeingültiges Beispiel eine ERC-20-USDC-Übertragung auf EVM.
Mit batch-settlement zeigt die x402-Dokumentation eine weitere EVM-Variante: Onchain-Escrow, signierte Offchain-Voucher und gebündelte Einlösung. Das macht die Trennung der Ebenen sichtbar, sagt aber nichts darüber aus, ob andere x402-Integrationen Karten, Stablecoins, Rückerstattungen oder Batch-Settlement gleich behandeln.
Doppelte Zahlungen sind ein Betriebsproblem, kein Detail
Für die direkte Solana-Abwicklung nennt die Protokolldokumentation ein Duplicate-Settlement-Risiko. Beim dokumentierten Batch-Settlement-Scheme verlangt sie für Produktionspfade dauerhafte Speicherung und atomar geteilte Updates im Mehrinstanzbetrieb. Für einen API-Betreiber heißt das: Ein erneut zugestellter Request darf nicht unbemerkt ein zweites Mal belastet werden.
Ebenso wichtig ist der Abgleich zwischen Zahlung und Ressourcenzugang. Ein Server muss nachvollziehen können, ob eine Ressource erst nach erfolgreicher Prüfung ausgeliefert wurde, ob Settlement fehlgeschlagen ist und welcher Versuch zu welchem Logeintrag gehört. Diese technische Nachvollziehbarkeit ersetzt weder Betrugsprüfung noch Buchhaltung, Steuerlogik oder einen Prozess für Rückerstattungen.
Pilot-Checkliste für kontrollierte Maschinenzahlungen
- Budget: Pro Agent, Service und Zeitraum feste Obergrenzen definieren.
- Empfänger: Nur freigegebene Server, Schemes, Netzwerke und Zieladressen zulassen.
- Freigabe: Vor einer Signatur klären, wann ein Mensch, eine Policy oder ein zusätzlicher Dienst zustimmen muss.
- Idempotenz: Request- und Settlement-IDs dauerhaft speichern und doppelte Einlösungen abfangen.
- Abgleich: Ressourcenzugang, Zahlungsstatus, Gebühren und Belegdaten zusammenführen.
- Ausfälle und Schlüssel: Facilitator-, Netzwerk- und Wallet-Ausfälle ebenso behandeln wie Schlüsselwechsel oder kompromittierte Zugänge.
- Prüfung: Den konkreten Wallet-, Token-, Kunden- und Datenfluss rechtlich, steuerlich und buchhalterisch bewerten lassen.
Was ein Pilot in Deutschland und Europa klären muss
Für bestimmte Transfers von Electronic Money Tokens durch Crypto-Asset-Service-Provider im Auftrag von Kunden beschreibt die EBA eine komplexe Überschneidung von Zahlungsdiensterecht und MiCA. Sie nennt unter anderem starke Kundenauthentifizierung, Betrugsreporting und Eigenmittelanforderungen. Diese Einordnung bewertet x402 nicht als Ganzes; wie ein Pilot rechtlich einzuordnen ist, hängt vom konkreten Zahlungs- und Datenfluss ab.
Vor einem Pilot müssen Teams deshalb klären: Wer handelt, welches Zahlungsinstrument und Netzwerk werden genutzt, wer ist Kunde, wer kontrolliert die Wallet und welche Daten fließen? Erst auf dieser Grundlage lassen sich Rechts-, Datenschutz-, Steuer- und Buchhaltungsfragen eingrenzen. Ein technisches Protokoll ersetzt diesen Rahmen nicht.
Meine Einschätzung: x402 standardisiert den Ablauf, nicht das Vertrauen
x402 löst ein klar umrissenes Protokollproblem: Automatisierte Clients können Preis, Signatur und Ressourcenzugriff in einen gemeinsamen Ablauf bringen. Das kann die Entwicklungsarbeit vereinfachen, wenn nicht jeder API-Anbieter eine eigene Zahlungsintegration bauen muss.
Vertrauen entsteht dadurch noch nicht. Wer darf signieren, wer trägt Gebühren, wie werden doppelte Requests erkannt, wie lässt sich ein Zugriff später belegen und wer reagiert bei einem Ausfall? Teams sollten x402 deshalb zunächst als begrenzten Pilot für kontrollierte Maschinenzahlungen behandeln – nicht als Abkürzung um Sicherheits-, Abrechnungs- und Rechtsfragen herum.
Quellen und weiterführende Informationen
- Linux Foundation: Operational Launch of x402 Foundation (14. Juli 2026)
- x402 Documentation: Client / Server
- x402 Documentation: Facilitator
- RFC 9110: 402 Payment Required
- Cloudflare Agents docs: x402
- European Banking Authority: PSD2/3 und MiCA (10. Juni 2025)
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-07-18
