HTTP 402 erklärt: Warum AI-Agents den vergessenen Payment-Code relevant machen

Was bedeutet HTTP 402 Payment Required?

HTTP 402 Payment Required ist ein offizieller HTTP-Statuscode mit unvollständiger Semantik. Er erschien im Januar 1997 in RFC 2068. Der aktuelle Standard RFC 9110 widmet ihm weiterhin nur einen Satz: Der Statuscode ist für zukünftige Nutzung reserviert.

Ein Server kann mit 402 ausdrücken, dass eine Zahlung Voraussetzung für den Zugriff auf eine Ressource ist. Der Code legt aber nicht fest, wie diese Zahlung aussehen muss.

HTTP 402 definiert allein nicht:

• Preis und Währung
• Zahlungsempfänger und Zahlungsweg
• Zahlungsautorisierung und kryptografischen Nachweis
• Settlement und Rückerstattung
• Budget, Identität oder Mandat eines Agents
• Cache-, Replay- oder Race-Condition-Schutz
• Verhalten von Browsern, Crawlern oder anderen Clients

Laut MDN existiert keine allgemeine Nutzungskonvention. Browser unterstützen keinen standardisierten 402-Flow und zeigen typischerweise nur einen generischen 4xx-Fehler. Für Menschen brauchst du deshalb weiterhin eine sichtbare Paywall oder einen normalen Checkout.

Die saubere Trennung lautet: HTTP 402 ist das Signal. x402, MPP oder ein proprietäres System definieren den eigentlichen Zahlungsablauf.

Warum blieb HTTP 402 fast 30 Jahre ungenutzt?

Der Statuscode löste keines der Probleme, die ein Bezahlsystem in der Praxis lösen muss.

1. Keine gemeinsame Zahlungssemantik: Server und Clients wussten nicht, welche Daten eine 402-Antwort enthalten und wie der nächste Request aussehen sollte.
2. Hohe Fixkosten: Karten- und Bankzahlungen waren für Beträge im Cent- oder Sub-Cent-Bereich wirtschaftlich ungeeignet.
3. Schlechte Human UX: Registrierung, Checkout, TAN oder Wallet-Bestätigung für jeden einzelnen Abruf erzeugen mehr Reibung als Nutzen.
4. Keine Browser-Unterstützung: Es entstand kein universelles Verhalten wie bei 301, 401 oder 404.
5. Etablierte Alternativen: Abonnements, Werbung, API-Keys und Prepaid-Credits waren einfacher zu implementieren und abzurechnen.
6. Recht und Betrieb: Umsatzsteuer, Belege, Refunds, Betrug und Verbraucherrechte verschwinden nicht durch einen HTTP-Code.

Micropayments scheiterten für Menschen deshalb nicht an einer fehlenden dreistelligen Zahl, sondern am gesamten Prozess rund um die Zahlung.

Warum machen AI-Agents den Statuscode plötzlich relevant?

AI-Agents können Zahlungsentscheidungen automatisieren. Sie müssen keinen Checkout verstehen, wenn Preis und Bedingungen maschinenlesbar vorliegen.

Ein zahlungsfähiger Agent kann:

• einen 402-Response erkennen,
• Zahlungsbedingungen aus Headern lesen,
• Preis und erwarteten Nutzen vergleichen,
• Wallet, Guthaben und akzeptierte Währung prüfen,
• ein Budget oder Mandat anwenden,
• die Zahlung signieren,
• den Request mit Zahlungsnachweis wiederholen,
• Beleg und Ergebnis protokollieren.

Der entscheidende Unterschied ist nicht Krypto, sondern Automatisierbarkeit. Ein Mensch wird kaum tausend einzelne Checkouts für Datenpunkte oder API-Aufrufe abschließen. Ein Agent kann tausend kleine Entscheidungen innerhalb klarer Regeln treffen.

Das bedeutet nicht, dass jeder Agent heute automatisch zahlen kann. Er braucht Protokollunterstützung, eine kompatible Zahlungsart, Guthaben, Ausgabenlimits und eine Richtlinie, welche Ressource welchen Preis wert ist. Autorisierungsschichten wie Googles Agent Payments Protocol (AP2) können Mandate und Freigabegrenzen ergänzen. Sie ersetzen aber nicht den Zahlungsweg selbst.

Wie funktioniert eine Zahlung über HTTP 402 technisch?

Der generische Ablauf besteht aus sieben Schritten:

1. Ein Client fordert eine Ressource an.
2. Der Server antwortet mit `402 Payment Required` und maschinenlesbaren Zahlungsbedingungen.
3. Der Client prüft Methode, Preis, Empfänger, Ressource und Budget.
4. Er erstellt eine signierte Zahlungsautorisierung oder erfüllt eine andere Challenge.
5. Er wiederholt den ursprünglichen Request mit einem Payment Credential.
6. Server oder Facilitator verifizieren den Nachweis und führen das Settlement aus.
7. Der Server liefert die Ressource mit `200 OK` und einem Zahlungsbeleg aus.

Ein vereinfachter x402-V2-Flow beginnt so:

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64-kodiertes-PaymentRequired-Objekt>
Content-Type: application/json

Der Agent wiederholt anschließend den Request:

GET /premium-research HTTP/1.1
Host: example.com
PAYMENT-SIGNATURE: <base64-kodierter-Zahlungsnachweis>

Nach erfolgreicher Prüfung antwortet der Server:

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64-kodierter-Settlement-Beleg>
Cache-Control: private, no-store
Content-Type: text/markdown

MPP nutzt für denselben Grundgedanken die HTTP-Authentifizierungsmechanik:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="...", method="...", intent="charge", request="..."
Cache-Control: no-store

Der nächste Request enthält das Credential:

GET /premium-research HTTP/1.1
Authorization: Payment <credential>

Die erfolgreiche Antwort kann einen `Payment-Receipt`-Header mitführen. Die Beispiele zeigen zugleich, warum HTTP 402 allein nicht genügt: Erst die zusätzlichen Header legen fest, wie Client und Server die Zahlung aushandeln.

Was ist x402?

x402 ist ein offenes Zahlungsprotokoll, das HTTP 402 mit Datenstrukturen, Headern, Zahlungsautorisierung und Settlement verbindet. Coinbase stellte es am 6. Mai 2025 öffentlich vor. Seit dem 2. April 2026 liegt das Projekt als x402 Foundation unter dem Dach der Linux Foundation.

Die Linux Foundation nennt unter anderem AWS, American Express, Cloudflare, Coinbase, Google, Mastercard, Microsoft, Shopify, Stripe und Visa als Organisationen mit anfänglicher Unterstützungs- oder Beitrittsabsicht. Das belegt Interesse an der Governance, aber nicht, dass alle Unternehmen x402 produktiv ausgerollt haben.

Welche Komponenten gehören zu x402?

Die x402-V2-Spezifikation beschreibt drei zentrale Rollen:

• Resource Server: bietet eine kostenpflichtige API, Datei, Webseite oder andere Ressource an.
• Client oder Agent: fordert die Ressource an und autorisiert die Zahlung.
• Facilitator: verifiziert die Zahlungsdaten und unterstützt oder übernimmt das Settlement.

V2 trennt Zahlungslogik und Transport. Das Protokoll kann damit nicht nur über HTTP, sondern auch über MCP oder Agent-to-Agent-Kommunikation eingesetzt werden. Schemes wie `exact`, `upto` und `batch-settlement` bilden Exaktbeträge, Maximalbeträge und gebündelte Abrechnung ab.

Clientseitige Budgets und Sessions gehören laut Spezifikation nicht zum Kern. x402 kann eine Zahlung transportieren, entscheidet aber nicht, ob dein Agent 0,01 oder 100 Euro ausgeben darf.

Wie groß ist die x402-Adoption?

Das GitHub-Repository stand beim Abruf am 11. Juli 2026 um 00:16 Uhr CEST bei 6.291 Stars und 1.802 Forks. Gegenüber dem eigenen Snapshot vom 3. Juli mit 6.235 Stars waren das 56 zusätzliche Stars beziehungsweise 0,9 Prozent Wachstum. Der Snapshot-Vergleich kann durch spätere Unstars oder neue Stars abweichen. Er ist ein Early-Signal für Entwicklerinteresse, kein Nachweis für Umsatz oder produktive Nutzung.

Auch die Live-Dashboards von x402.org und x402scan widersprechen sich deutlich:

30-Tage-Kennzahl, Abruf 11.07.2026, 00:16 CEST	x402.org	x402scan
Transaktionen	75,41 Mio.	16,24 Mio.
Volumen	24,24 Mio. USD	845.640 USD
Käufer	94.060	68.140
Verkäufer	22.000	39.000

Die Werte dürfen weder addiert noch gemittelt werden. Die Dashboards veröffentlichen auf den sichtbaren Seiten keine ausreichend vergleichbare Methodik für Chain-Abdeckung, Schemes, Filterung und die Definition von Käufern oder Verkäufern. Deshalb sind es dashboardspezifische Momentaufnahmen, keine unabhängig bestätigten Gesamtmarktzahlen.

Was ist MPP und wie unterscheidet es sich von x402?

Das Machine Payments Protocol (MPP) wurde von Stripe und Tempo entwickelt und am 18. März 2026 vorgestellt. Es nutzt ebenfalls HTTP 402, setzt aber auf die bestehenden HTTP-Authentifizierungsheader `WWW-Authenticate`, `Authorization` und `Payment-Receipt`.

MPP ist zahlungsmethodenagnostisch positioniert. Laut Stripe und Cloudflare-Dokumentation können Implementierungen Stablecoins, Stripe-basierte Karten und Wallets, Bitcoin Lightning sowie eigene Methoden anbieten. MPP unterscheidet zudem zwischen `charge` für Einzelzahlungen und `session` für laufende oder gestreamte Nutzung.

Kriterium	x402	MPP
Ursprung	Coinbase, seit April 2026 Linux Foundation	Stripe und Tempo
HTTP-Mechanik	`PAYMENT-REQUIRED`, `PAYMENT-SIGNATURE`, `PAYMENT-RESPONSE`	`WWW-Authenticate: Payment`, `Authorization: Payment`, `Payment-Receipt`
Heutiger Schwerpunkt	Stablecoins und Onchain-Settlement	Stablecoins plus Stripe- und weitere Zahlungswege
Abrechnung	`exact`, `upto`, `batch-settlement`	`charge`, `session`
Budgetsteuerung	nicht Teil des Kerns	separate Client- und Governance-Regeln nötig
Standardstatus	offenes Foundation-Projekt	offenes Protokoll mit aktivem Internet-Draft

Der aktuelle Entwurf für das Payment-Authentifizierungsschema ist seit dem 19. Juni 2026 als `draft-httpauth-payment-00` im IETF Datatracker gelistet. Er ist ein individueller Internet-Draft, nicht von der IETF gebilligt und kein verabschiedeter Internetstandard. Er kann jederzeit aktualisiert, ersetzt oder verworfen werden.

Stripe führt MPP-Zahlungen nach eigener Darstellung über bestehende PaymentIntents, Reporting-, Refund- und Auszahlungsprozesse. Die Stripe-Dokumentation kennzeichnet MPP derzeit als Frontier: Die Kernfunktionen sind verfügbar, Änderungen an den APIs aber wahrscheinlicher als bei allgemein verfügbaren Produkten. Fiat-Zahlungen über Shared Payment Tokens setzen laut aktueller Dokumentation eine US-amerikanische juristische Person voraus. Auch Stablecoin-Funktionen sind regional eingeschränkt und in der Dokumentation nicht durchgehend einheitlich beschrieben. Für ein deutsches Unternehmen muss die konkrete Verfügbarkeit deshalb vor der Integration im Stripe-Konto geprüft werden.

Wie nutzt Cloudflare HTTP 402 für Publisher?

Cloudflare macht aus dem Protokollthema ein konkretes Publisher-Produkt. Dabei sind drei Ebenen zu unterscheiden.

Was ist Pay Per Crawl?

Pay Per Crawl wurde am 1. Juli 2025 als Private Beta vorgestellt und befindet sich am 11. Juli 2026 weiterhin in einer geschlossenen Beta. Publisher können AI-Crawler erlauben, blockieren oder mit einem domänenweiten Preis versehen. Crawler und Server handeln über Header wie `crawler-price`, `crawler-exact-price`, `crawler-max-price` und `crawler-charged`.

Web Bot Auth soll dabei kryptografisch nachweisen, welcher Bot tatsächlich anfragt. Cloudflare beschrieb sich für dieses Modell als Merchant of Record und bündelt die Abrechnung. Das kann den operativen Aufwand reduzieren, beseitigt aber nicht automatisch alle Pflichten des Publishers.

Was ist der Monetization Gateway?

Der am 1. Juli 2026 angekündigte Monetization Gateway soll x402-Regeln direkt am Cloudflare Edge anwenden. Geplant sind bezahlte Webseiten, APIs, Datensätze, MCP-Tools sowie Regeln nach Route, HTTP-Verb und Nutzung.

Status am 11. Juli 2026: Der Gateway befindet sich auf einer Waitlist beziehungsweise im Early Access. Preise und ein allgemeines Verfügbarkeitsdatum sind nicht veröffentlicht. Der erste angekündigte Zahlungsweg nutzt Stablecoins über x402.

Was bedeutet Pay Per Use?

Cloudflare beschreibt als nächste Stufe Pay Per Use. Nicht der bloße Crawl soll bepreist werden, sondern eine wertschöpfende Nutzung, etwa eine Abfrage, ein Resultat oder ein API-Aufruf. Das ist ökonomisch genauer, aber technisch schwerer zu messen und zuzuordnen.

Was passiert, wenn ein AI-Agent deine Website besucht?

Nicht jeder 402-Response endet mit einer Zahlung. Das Ergebnis hängt von den Fähigkeiten und Regeln des Clients ab.

Situation	Reaktion
Agent kennt weder x402 noch MPP	Er behandelt 402 als Fehler und bricht ab.
Agent versteht das Protokoll, hat aber keine Wallet	Er kann den Preis lesen, aber nicht zahlen. Er fragt den Nutzer oder sucht eine Alternative.
Agent hat Wallet, Guthaben und Budget	Er prüft Ressource, Empfänger, Betrag und Mandat, signiert und wiederholt den Request.
Preis liegt über dem Freigabelimit	Er bricht ab oder fordert eine menschliche Freigabe an.
Klassischer Search- oder AI-Crawler ohne Payment-Support	Er crawlt den geschützten Inhalt nicht. Das kann Indexierung und Zitation verhindern.

Agent-Wallets allein reichen nicht. Ein produktiver Flow braucht außerdem Identität, Policy Enforcement, Audit-Logs, Fehlerbehandlung und Schutz vor manipulierten Discovery-Daten. Das Vertrauensproblem hinter Agentenidentität vertieft der Artikel zum Agent Name Service.

Solltest du deine Website mit HTTP 402 monetarisieren?

Für einen normalen Blog ist eine vollständige 402-Paywall aktuell die falsche Strategie. Sinnvoller ist ein begrenzter Pilot mit einer Ressource, deren Wert für einen Agenten klar messbar ist.

Welche Ressourcen eignen sich?

• strukturierte Datensätze und aktuelle Marktinformationen
• Research-APIs und vollständige Reports
• spezialisierte MCP-Tools
• rechenintensive Analysen oder Inference
• Rohdaten als CSV, JSON oder Markdown
• High-Frequency-Zugriffe mit klarem wirtschaftlichem Nutzen

Welche Ressourcen eignen sich nicht?

• Startseite, Navigation, Sitemap und `robots.txt`
• Titel, Meta-Informationen und Autorenprofile
• frei indexierbare Kurzfassungen
• der öffentliche Kern eines Evergreen-Artikels
• Inhalte ohne exklusiven oder aktuellen Mehrwert

Für florian-gahn.de wäre ein Test mit einer separaten Research-API oder einer vollständigen Datenmatrix plausibler als eine Paywall vor allen Artikeln. Der öffentliche Beitrag schafft Reichweite und Vertrauen. Die maschinenlesbare Premium-Ressource verkauft zusätzlichen Nutzwert.

Wie verhinderst du SEO- und GEO-Verluste?

Eine 402-Paywall kann Suchmaschinen und Answer Engines die Grundlage zum Indexieren und Zitieren entziehen. Google behandelt 4xx-Responses mit Ausnahme von 429 grundsätzlich als nicht indexierbar und ignoriert den empfangenen Inhalt. Deshalb braucht die Architektur zwei klar getrennte Ebenen.

Was gehört in die kostenlose Discovery-Schicht?

Diese Inhalte sollten mit `HTTP 200` erreichbar bleiben:

• Titel und Meta-Description
• Kurzfassung und zentrale Definitionen
• Inhaltsstruktur und zitierfähige Kernaussagen
• Autor, Datum und Quellenkategorien
• strukturierte Daten
• Sitemap, Navigation und Crawler-Hinweise

Was darf in die bezahlte Premium-Schicht?

Dort können `HTTP 402`, x402 oder MPP eingesetzt werden:

• vollständige Datensätze und Exporte
• laufend aktualisierte Zahlen
• umfangreiche Benchmark-Tabellen
• personalisierte oder rechenintensive Analysen
• APIs und MCP-Tools

Crawler solltest du außerdem nach Zweck unterscheiden, soweit Identität und Infrastruktur das zuverlässig erlauben: Search-Indexierung, Training, Retrieval und agentische Nutzung sind nicht dasselbe. Der GEO-Technik Deep Dive erklärt die technische Crawler-Steuerung. Warum maschinenlesbare Schnittstellen über klassisches Screen-Scraping hinausgehen, zeigt der Beitrag zu WebMCP.

Welche Sicherheitsrisiken bestehen?

Zahlungsprotokolle verbinden synchrone HTTP-Requests mit einem teilweise asynchronen Settlement. Genau an dieser Grenze entstehen neue Fehlerklassen.

Ein arXiv-Preprint vom 12. Mai 2026 untersuchte x402 mit mehr als 25.000 Testrequests in 48 Konfigurationen. Die Autoren berichten von elf Schwachstellen in drei Open-Source-SDKs und vier Live-Endpunkten. In ihrem Versuchsaufbau erhielten sie unter anderem bis zu 248 HTTP-Freigaben mit einem Zahlungsnachweis. Ein durch manipulierte Metadaten präparierter Server erreichte eine Auswahlrate von bis zu 71,8 Prozent; fünf Sybil-Server kamen auf 60,2 Prozent.

Wichtig: Das Paper ist ein Preprint und keine abschließend peer-reviewte Studie. Die Ergebnisse zeigen konkrete Implementierungsrisiken in den untersuchten Systemen, nicht die Unsicherheit jeder x402- oder MPP-Installation.

Welche Angriffe musst du verhindern?

• Replay und fehlende Idempotenz: Ein Zahlungsnachweis darf nicht mehrere Leistungen freischalten. Payment-ID und Ressource müssen atomar gebunden werden.
• Fehlendes Resource Binding: Domain, Pfad, Methode, Body, Betrag und Empfänger müssen Teil der geprüften Autorisierung sein.
• Settlement-Races: Der Server darf eine Leistung nicht mehrfach oder dauerhaft ausliefern, wenn das Settlement später scheitert.
• Cache-Leaks: Bezahlte oder nutzerspezifische Responses dürfen nicht in öffentliche CDN- oder Proxy-Caches gelangen. `Cache-Control: private, no-store` ist dafür der sichere Standard. Abweichende Cache-Strategien erfordern eine verifizierte Trennung nach Autorisierung und Ressource.
• Manipulierte Discovery: Agents dürfen Verzeichnissen, Metadaten und angeblichen Facilitators nicht blind vertrauen.
• Header- und Log-Leaks: Zahlungsnachweise und sensible Payment-Daten gehören weder in öffentliche Logs noch in gemeinsam genutzte Caches.

Zusätzlich brauchst du TLS, strikte Betrags- und Asset-Prüfung, definierte Refund- und Fehlerpfade sowie Monitoring für doppelte oder widersprüchliche Settlements.

Welche Rechts- und Steuerfragen gelten in Deutschland?

Die EU-Verordnung Markets in Crypto-Assets (MiCA) schafft einheitliche Regeln für Kryptoassets, Emittenten und Crypto-Asset Service Provider (CASPs). Artikel 3 der Verordnung (EU) 2023/1114 definiert einen CASP als Unternehmen, dessen Beruf oder Geschäft darin besteht, Kryptowerte-Dienstleistungen für Kunden professionell anzubieten. Die bloße Annahme eines Stablecoins als Gegenleistung für eigene Inhalte macht einen Publisher daher nicht automatisch zu einem CASP. Entscheidend ist, welche Rolle du tatsächlich übernimmst, etwa Verwahrung, Umtausch, Vermittlung oder das Ausführen von Kryptodienstleistungen für Kunden.

Trotzdem bleibt eine Stablecoin-Zahlung ein buchhalterischer und steuerlicher Vorgang. Vor einem produktiven Einsatz musst du mindestens klären:

• Bewertung in Euro zum Leistungszeitpunkt
• Rechnung, Umsatzsteuer und Belegführung
• Auszahlung und Wechselkursdifferenzen
• Refunds und Verbraucherrechte
• KYC-, KYT- und AML-Aufgaben des Providers
• Datenschutz bei Agentenidentität und Zahlungsdaten
• Buchhaltungsintegration und Sammelabrechnung
• Verfügbarkeit des Providers für deutsche Unternehmen

Ein Payment Provider oder Merchant of Record kann Teile von Abrechnung, Reporting und Auszahlung bündeln. Er ersetzt weder die Prüfung deines Geschäftsmodells noch eine deutsche Steuer- und Rechtsberatung.

Praktische Empfehlung: Starte nicht mit einer selbst verwalteten Stablecoin-Wallet für tausende Sub-Cent-Zahlungen. Prüfe zuerst ein Provider-Modell mit EUR-Auszahlung, konsolidierten Belegen und klar geregelten Refunds.

FAQ: Häufig gestellte Fragen zu HTTP 402 und AI-Agent-Payments

Was ist der Unterschied zwischen HTTP 402 und x402?

HTTP 402 ist nur der Statuscode für eine Zahlungsbarriere. x402 ergänzt Datenstrukturen, eigene Header, Zahlungsautorisierung, Facilitator-Schnittstellen und Settlement. Ohne ein solches Zusatzprotokoll weiß ein Client nicht, wie er auf 402 reagieren soll.

Was ist der Unterschied zwischen x402 und MPP?

Beide nutzen HTTP 402. x402 verwendet eigene Payment-Header und ist in der heutigen Praxis stark durch Stablecoins und Onchain-Settlement geprägt. MPP von Stripe und Tempo nutzt die HTTP-Authentifizierungsheader und unterstützt laut Anbietern zusätzlich Karten, Wallets, Lightning und eigene Methoden.

Unterstützen Browser HTTP-402-Zahlungen?

Nein, nicht nativ. Normale Browser behandeln 402 typischerweise wie einen generischen 4xx-Fehler. Für menschliche Nutzer brauchst du weiterhin eine sichtbare Paywall, einen Checkout oder eine Client-Erweiterung.

Braucht ein AI-Agent eine Wallet und ein Budget?

Ja. Protokollunterstützung allein reicht nicht. Der Agent braucht eine kompatible Zahlungsart, Guthaben, Freigabegrenzen, eine Identitäts- oder Mandatsebene und Regeln zur Bewertung der Ressource.

Schadet HTTP 402 der SEO- und GEO-Sichtbarkeit?

Ja, wenn du den gesamten Artikelbestand sperrst. Search-Crawler und Answer Engines ohne Payment-Support können die geschützten Inhalte nicht indexieren oder zitieren. Eine offene Discovery-Schicht mit HTTP 200 reduziert dieses Risiko.

Sind x402 und MPP sicher?

Sie können sicher implementiert werden, nehmen dir die Web-Sicherheitsarbeit aber nicht ab. Replay-Schutz, Idempotenz, Resource Binding, Settlement-Finalität und private Cache-Regeln sind zwingend. Das zitierte Angriffspapier untersucht konkret x402 und ist als Preprint einzuordnen.

Ist x402 nur für Krypto geeignet?

Die x402-Spezifikation ist erweiterbar und nicht auf ein einzelnes Netzwerk festgelegt. Die aktuelle Praxis ist dennoch stark stablecoin- und blockchaingeprägt. MPP positioniert sich breiter und bindet auch klassische Zahlungswege ein.

Fazit

HTTP 402 wird durch AI-Agents erstmals praktisch interessant, ist aber weiterhin nur ein Signal und kein universelles Bezahlsystem. x402, MPP und Cloudflare zeigen, wie daraus ein maschinenlesbarer Payment-Flow entstehen kann, doch Browser-Support, Client-Adoption, Sicherheit, Abrechnung und Regulierung sind noch nicht gelöst. Für Publisher ist ein hybrider Pilot sinnvoll: offene, zitierfähige Inhalte behalten und exklusive Datensätze, APIs oder MCP-Tools separat monetarisieren. Den größeren Kontext liefern die Artikel zu Agentic Commerce, WebMCP, Crawler-Management für GEO und Agent Name Service.

Verifizierte Quellen:

• RFC 9110 – HTTP Semantics, §15.5.3 – Aktuelle Definition des reservierten Statuscodes 402
• RFC 2068, §10.4.3 – Ersterwähnung von HTTP 402 (Januar 1997)
• MDN Web Docs: 402 Payment Required – Fehlende Nutzungskonvention und Browser-Verhalten
• x402 V2 Specification (GitHub) – Rollen, Header und Schemes
• Linux Foundation: Launch der x402 Foundation – Governance und unterstützende Organisationen
• Stripe: Machine Payments Protocol – MPP-Ansatz und Zahlungswege
• Cloudflare Docs: MPP – MPP-Implementierung am Edge
• IETF Datatracker: draft-httpauth-payment-00 – Internet-Draft des Payment-Authentifizierungsschemas
• Cloudflare: Introducing Pay Per Crawl – Crawler-Preise und Web Bot Auth
• Cloudflare: Monetization Gateway – x402-Regeln am Cloudflare Edge
• Google Search Central: HTTP-Statuscodes – Behandlung von 4xx bei der Indexierung
• Verordnung (EU) 2023/1114 (MiCA), Art. 3 – CASP-Definition
• Li et al.: Five Attacks on x402 (arXiv-Preprint 2605.11781v1) – Sicherheitsanalyse des x402-Protokolls