Anfang Juni diskutierten auf der Proof of Talk im Louvre-Palast in Paris rund 2.500 Entscheider aus Web3, Stablecoins und KI-Infrastruktur genau solche Fragen: Wie bezahlen autonome Systeme im Internet, und welche Lösung wird zum Standard? Der Begriff Agentic Payments klingt erstmal nach Chatbots, die für Nutzer bspw. online einkaufen und direkt bezahlen. Während auch dieser Bereich ein Wachstumsmarkt ist, ist mit Agentic Payments etwas anderes gemeint: Agent-to-Agent- und Machine-to-Machine-Zahlungen, bei denen Server, APIs oder KI-Agenten autonom Micro-Beträge für Daten, Compute oder Content abwickeln – ohne menschlichen Checkout.
Agentic Payments meint Maschinen, die für Maschinen bezahlen
Wenn ein Nutzer ChatGPT beauftragt, etwas auf Amazon zu bestellen, spricht die Industrie von „agentic commerce“ – Stripe und OpenAI nennen das auch “Instant Checkout im Chat”. Für Infrastruktur- und Zahlungsarchitektur ist das ein Consumer-Use-Case mit Kartenrails (Kredit/Debit) und Mandatsprotokollen (etwa Googles AP2), nicht aber der Maschinen-Mikrozahlungsfall, der mit Agentic Payment beschrieben wird. Letzterer betrifft Server-zu-Server-Requests: ein Crawler bspw. zahlt pro Artikelabruf, ein KI-Agent pro API-Call, ein Modell pro Inference-Slot. Die Beträge liegen teilweise im Micro-Cent Bereich. Solche Mirco-Zahlungen sind für klassische Kartennetze wie MasterCard oder Visa, aber auch vergleichbare bisherige Zahlungslösungen, wirtschaftlich nicht tragbar.
Case-Beispiel: Daten werden knapper – und KI-Modelle brauchen sie in Billionen
Echter, authentischer Content hat wieder einen Marktpreis, weil Frontier-Modelle auf massiven Trainingsdaten beruhen. Ein Large Language Model ist im Kern eine hochdimensionale mathematische Funktion mit Milliarden bis Billionen optimierter Gewichte; per Backpropagation minimiert sie eine Fehlerfunktion, sodass Input-Output-Paare generalisierbar werden. Genau dafür braucht es riesige, qualitativ nutzbare Korpora – und die werden seltener: Laut Epoch AI könnte hochwertiger human-generierter Text zwischen 2026 und 2032 ausgeschöpft sein. Parallel dazu steigen die Restriktionen bei knapp einem Drittel der Top-Webquellen für crawling, also automatisches Suchen von bspw. KI-Agenten.
Auf den Trend des crawlen reagieren Publisher mit Pay-per-Use-Modellen: Cloudflare testet Pay Per Crawl – ein Fix-Preis pro Request, den ein Crawler machen möchte. Dieser Preis liegt ebenfalls in dem bereits angesprochen Microcent-Bereich, abgerechnet werden diese Zahlungen bei Cloudflare über HTTP 402. Zahlungen für Content sind ein sehr spezifischer Anwendungsfall für Agentic Payments. Die Really Simple Licensing (RSL)-Spezifikation definiert hierfür maschinenlesbare Lizenztypen für crawl, use und training in robots.txt und Headers. Mitgründer von RSL sind u.a. Reddit, Automattic (WordPress / Elementor) und Fastly. Bald könnten Besitzer von WordPress also vielleicht ihre individuellen Blog-Artikel mithilfe von solchen Agentic Payments monetarisieren, also jedes Mal wenn ein KI-Agent den Blog durchsucht, um die Inhalte zu verwenden. Indirekt würde eine KI so den Menschen für seine menschliche Originalität seiner Inhalte bezahlen. Grundsätzlich gilt für alle agenten- und maschinenbasierten Systeme in der Zukunft: Sie brauchen autonome Kleinstzahlungen. Nicht nur bei Content-Zahlungen liegen die Einzelkosten pro Request oft im Cent- oder Sub-Cent-Bereich. Bisherige Zahlungssysteme sind nicht auf solche Zahlungen ausgelegt und würden mehr Geld für die Abwicklung an Kosten verursachen, als der eigentliche Betrag wert ist.
Blockchain verspricht Transparenz, KI monopolisiert Rechenkapazität – Mikrozahlungen als Brücke
Schon früh war die Idee, KI und Blockchain zu koppeln: Wenn Daten, Rechenergebnisse und Zahlungen auf einer nachvollziehbaren Blockchain-Schicht laufen, ließen sich Herkunft und Rechte sauberer zuordnen – und Lizenzlogik ließe sich delegierbar strukturieren, statt sie jedes Mal manuell auszuhandeln. Genau darauf zielen Forschungsrahmen wie IBis (Dataset-Provenance, bilaterale Lizenzen) oder Content ARCs (Authenticity → Rights → Compensation via Distributed-Ledger-Technologie) ab. Sie zeigen bereits, dass genau diese Fusion der beiden Zukunftstechnologien funktionieren kann.
KI selbst bewegt sich jedoch in eine andere Richtung. Frontier-Modelle laufen in zentralisierten Rechenclustern und proprietären Stacks; Blockchain setzt dagegen auf offene Protokolle und verifizierbare Zustände. In Klartext bedeutet das: Beide Technologien versprechen Transparenz, skalieren aber entlang gegensätzlicher Logiken – monopolisierte Interferenz auf der einen, dezentralisierte Settlement-Schicht auf der anderen Seite.
Genau hier können x402 und Stablecoin-Mikrozahlungen eine Brücke schlagen: Sie ermöglichen HTTP-native Abrechnung für agentische Workloads und ein on-Chai” verifizierbares Settlement -ohne dass das Training selbst on-Chain laufen müsste. Dabei löst x402 insbesondere das Grundproblem bei Micropayments, das auch eine Blockchain betrifft: Die Transaktionskosten sind höher als der Transaktionsbetrag selbst.
x402 macht aus HTTP 402 einen Zahlungskanal – offen für jedes Payment Model
Der HTTP-Statuscode 402 Payment Required existiert länger, als die meisten Webentwickler denken: Er wurde bereits 1997 in RFC 2068 eingeführt – einem offiziellen Standarddokument, in dem festgelegt ist, wie Webserver und Clients miteinander kommunizieren. Seitdem hat die IETF (das Gremium, das Internet-Protokolle standardisiert) den Code in RFC 2616, RFC 7231 und RFC 9110 durchgehend nur als „reserved for future use“ geführt – also reserviert, aber ohne implementierten Micropayment-Standard. Reserviert haben ihn die HTTP/1.1-Autoren um Roy Fielding und Tim Berners-Lee. Einzelne Dienste nutzten 402 später sporadisch und proprietär, etwa für API-Quota-Hinweise; webweit normiert wurde der Statuscode nie.
Statuscodes sind die dreistelligen Kennzahlen, mit denen ein Server jede Anfrage einordnet: 200 bedeutet „erfolgreich, hier sind die Daten“, 404 „Ressource nicht gefunden“. Der Code 402 war von Anfang an als Paywall-Signal gedacht – „Zugang nur gegen Bezahlung“.
x402 setzt nun genau auf diesen Mechanismus auf. Grundsätzlich funktioniert das Web als Request/Response – also Frage und Antwort: Der Client (Browser, App oder KI-Agent) stellt eine HTTP-Anfrage an einen Server. Mit GET werden Daten abgerufen, mit POST typischerweise Daten zur Verarbeitung gesendet. Der Server antwortet mit einem Statuscode, Headern (Metadaten zur Anfrage) und einem Body (den eigentlichen Inhalten).
Wenn für eine Ressource bezahlt werden muss, antwortet der Server mit 402 und liefert im Header PAYMENT-REQUIRED die Zahlungsbedingungen – als Base64-kodiertes JSON, also ein maschinenlesbares Datenformat in codierter Textform. Der Client signiert ein Payment Payload (die konkrete Zahlungsautorisierung) und wiederholt die Anfrage mit dem Header PAYMENT-SIGNATURE. Erst nach Verify (Prüfung der Zahlung) und Settle (finale Abwicklung) folgt 200 – zusammen mit der Resource und dem Header PAYMENT-RESPONSE. Der Statuscode 402 ist damit nur das Signal „Zahlung nötig“. Welches Zahlungsmodell greift, steckt im Payload.
Damit der Standard nicht bei einer Firma hängenbleibt, hat die Coinbase Developer Platform das Protokoll im Mai 2025 als Open Standard veröffentlicht (Whitepaper, Apache-2.0); Launch-Partner sind u.a. AWS, Anthropic und Circle. Im September 2025 kündigten Cloudflare und Coinbase eine gemeinsame Foundation an; im April 2026 startete die Linux Foundation die x402 Foundation mit Governance von Coinbase, Cloudflare und Stripe – unter Beiträgen von Google, Visa, Mastercard und AWS.
Spezifikation und Dokumentation liegen unter x402.org und docs.x402.org vor. SDKs (Software Development Kits – vorgefertigte Code-Bibliotheken, mit denen Entwickler das Protokoll einbinden) erleichtern die Integration. Der Referenzcode steht im GitHub-Repo x402-foundation/x402 – einem öffentlich einsehbaren Code-Archiv auf GitHub. Version 2 unterstützt CAIP-2-Netzwerk-IDs zur einheitlichen Benennung von Blockchains und eine Facilitator-API mit den Endpunkten /verify und /settle – also den URLs, unter denen ein Vermittlungsdienst Zahlungen prüft und abschließt.
Was x402 offen lässt, ist das eigentliche Payment Model. Im Protokoll sind das Scheme-Definitionen im JSON – theoretisch kann jede internetfähige Middleware andocken: Dummy-Schemes für Tests, Kartenstrecken oder interne Bilanzsysteme in geschlossenen Ökosystemen. Konzeptionell wären auch abstrahierte Bankrails denkbar (SEPA, TARGET2, SWIFT-MT). Praktisch dominieren heute Stablecoin-Schemes auf EVM (Ethereum Virtual Machine – die gemeinsame Ausführungsumgebung für Smart Contracts auf Ethereum und kompatiblen Netzwerken), weil programmatische Signatur und Sub-Cent-Settlement dort bereits implementiert sind. In einem geschlossenen Ökosystem lassen sich eigene x402-Models definieren, solange Server und Client dasselbe Scheme verwenden. Der Vorteil der offenen Foundation-Arbeit: Interoperabilität über Anbietergrenzen hinweg.
EVM-L2s und Stablecoins gewinnen durch Gebühren, nicht durch Vision
Dass Stablecoins grundsätzlich relevant werden, lässt sich in Zahlen fassen. Chainalysis beziffert das adjustierte Stablecoin-Volumen 2025 auf 28 Billionen Dollar realwirtschaftlicher Aktivität; die BIS nennt eine Marktkapitalisierung von über 300 Milliarden Dollar, rund 98 Prozent davon USD-denominiert. Beide beobachten zugleich wachsende Nutzung für Treasury und grenzüberschreitende Zahlungen – ein Trend, der sich auch in Schwellenmärkten zeigt (vgl. Stablecoin-Einsatz in Afrika).
Für agentische Micropayments kommt ein zweiter Punkt hinzu: Settlement – die endgültige Geldübertragung – muss maschinell prüfbar sein. Öffentlich verifizierbare Onchain-Events (in der Blockchain gespeicherte, für jeden einsehbare Transaktionsnachweise) passen deshalb gut zu Open-Source-Protokollen, offenen APIs (programmierbare Schnittstellen, über die Software Dienste ansprechen) und autonomen Clients. Sie erlauben einen Audit-Trail pro Request, ohne dass ein Mensch jeden Cent manuell abrechnet.
Technisch ist Ethereum / EVM dafür längst die Kompatibilitätsschicht – die gemeinsame Basis, auf der viele Blockchains und Zahlungsprotokolle aufsetzen. x402 v2 nutzt CAIP-2-IDs zur Netzwerkbenennung, etwa eip155:8453 für Base oder eip155:137 für Polygon; das Präfix eip155 steht hierbei für Ethereum-kompatible Chains. Für gaslose USDC-Zahlungen, also ohne eine Transaktionsgebühr kommt EIP-3009 zum Einsatz – ein Ethereum-Improvement-Proposal, das signierte Off-Chain-Autorisierungen erlaubt, ohne dass der Zahler selbst Gas (die Transaktionsgebühr auf der Blockchain) zahlen muss. Permit2 ergänzt das für beliebige ERC-20-Tokens, den Standard für fungible Kryptowährungen auf EVM.
Coinbases CDP-Facilitator (Vermittlungsdienst für Verify und Settle) arbeitet auf Base, Polygon, Arbitrum, World und Solana; das Whitepaper nennt Sub-Sekunden-Settlement und Gas unter 0,0001 Dollar. Zum Vergleich: Kreditkartennetze haben oft Gebühren um 0,30 Dollar pro Transaktion – damit werden Cent- oder Sub-Cent-Zahlungen dort schlicht unökonomisch.
Wer zuerst Produktionsvolumen, SDK-Verbreitung (also fertige Entwickler-Werkzeuge zur schnellen Integration) und Enterprise-Anbindung hat, setzt den De-facto-Standard – aktuell mit Vorsprung auf Base/EVM durch Coinbase-Infrastruktur. Eine zwei-Cent-Transaktion darf nicht fünf Cent Fees kosten; die L2-Ökonomie – also günstige Transaktionen auf Layer-2-Netzwerken, die auf Ethereum aufsetzen – ist deshalb Voraussetzung, nicht Nice-to-have.
Fazit
Für agentische Micropayments ist das EVM-Ökosystem – insbesondere USDC auf L2s wie Base und Polygon – derzeit das pragmatischste Blockchain-Ökosystem: offene Spec, niedrige Fees, bestehende Stablecoin-Liquidität. Die nächste Reife-Stufe ist aber nicht Technik allein, sondern Governance: Custody-Modelle, Mandats- und Haftungsfragen bei autonomen Agenten und interoperable Verwahrung. Darüber entscheidet, ob x402 ein Nischenprotokoll bleibt oder zur Infrastruktur wird.
Viel wird neu gebaut – gleichzeitig setzt der Markt auf Schichten, die es schon gibt: HTTP, EVM, Stablecoins. TokenPay arbeitet in genau dieser Schnittstelle – grenzüberschreitende Fiat- und Stablecoin-Flows – und baut Partner-Infrastruktur auf bestehenden Rails statt parallelen Insellösungen.
Weitere Informationen zu TokenPay Infrastruktur findest Du hier
Quellen
- RFC 9110 HTTP 402 Payment Required
- Coinbase Introducing x402
- x402 Whitepaper
- Linux Foundation x402 Foundation Launch
- Cloudflare Blog x402
- Stanford AI Index 2025
- Epoch AI Will we run out of data?
- Longpre et al. Consent in Crisis
- Cloudflare Introducing Pay Per Crawl
- RSL Standard 1.0
- Tiger Research Payments 3.0: The AI Agent Payments Engine
- Google Cloud AP2 Agent Payments Protocol
- IMF Notes 2026/004
- Chainalysis Stablecoin utility & future of payments
- BIS Papers No. 170
- Coinbase CDP x402 Documentation
- Circle Agent Nanopayments
- Content ARCs (arXiv 2025) / IBis (arXiv 2024)
- Proof of Talk 2026
- RFC 2068 HTTP/1.1 (Jan. 1997)
- MDN HTTP 402 Payment Required
- OpenAI Buy it in ChatGPT
- docs.x402.org
- Fastly Control and Monetize Your Content with RSL
- RSL Collective Press Release
- UK Government Report on Copyright and Artificial Intelligence
- Automattic x402-Pay
- EIP-3009
- USDC.org
- Stripe
- Cloudflare Press Release
- Markets Insider
- IBis
- Content ARCs
- Square Credit Card Processing Fees Explained
- NanoTrans Agent Paywall
