x402 ist ein Protokoll, um Web-Ressourcen über HTTP zu bezahlen. Ein Server gibt Zahlungsanforderungen mit HTTP 402 zurück; ein kompatibler Client autorisiert die Zahlung und versucht es erneut mit einer Payment-Payload.
Für einen KI-Agenten kann das eine bezahlte API-Anfrage in einen Teil der Aufgabe verwandeln. Die Wallet benötigt immer noch die Erlaubnis zum Ausgeben, und der Dienst muss das Ergebnis immer noch liefern.
HTTP 402 wird zu einem Preisangebot
HTTP 402 ist der Statuscode „Payment Required“. x402 fügt einen definierten Zahlungs-Austausch darum hinzu; gewöhnliche Browser werden nicht automatisch zu autonomen Käufern, nur weil eine Website diesen Status zurückgibt.
Im aktuellen V2-Flow kommuniziert der Server die Anforderungen über PAYMENT-REQUIRED. Der Client antwortet mit einer Payment-Payload in PAYMENT-SIGNATURE. Der Server meldet das Abwicklungsergebnis über PAYMENT-RESPONSE. Die Header-Namen beschreiben separate Schritte, nicht drei Zahlungen. HTTP 402 und V2-Header.
Stell dir einen Forschungs-Agenten vor, der eine Wetterbeobachtung für eine Routenplanungsaufgabe kauft. Ein fiktives Angebot verlangt $0.001 in USDC, nennt die Empfangsadresse des Verkäufers und gibt ein unterstütztes Netzwerk sowie ein exaktes Zahlungsschema an. Der Zahlungsclient muss diese Bedingungen erkennen, bevor er fortfahren kann. Dieser Preis ist beispielhaft und kein tatsächliches Service-Angebot.
Ein Preisangebot ist keine Erlaubnis zum Ausgeben. Die Wallet- oder Anwendungsrichtlinie sollte prüfen, ob der Betrag, der Händler und die angeforderte Ressource zur Aufgabe passen. Ein Server kann einen unvernünftigen Preis nennen, genau wie ein menschlicher Verkäufer.
Von einer unbezahlten Anfrage zu einer bezahlten Antwort
Der Agent autorisiert eine Zahlung, während der Verkäufer kontrolliert, wann er die Ressource freigibt.
Verfolgung einer bezahlten Anfrage
Der Client fordert die Ressource an. Der Server antwortet mit den Zahlungsanforderungen. Der Client wählt eine unterstützte Option und erstellt eine Autorisierungs- oder Zahlungs-Payload für diese Option. Er wiederholt die Ressourcenanfrage mit der angehängten Payload.
Der Server prüft die Zahlung und wickelt sie unter dem ausgewählten Schema und Zahlungsfluss ab. Die Standard-Autorisierung wird vor dem Ressourcen-Handler verifiziert und danach abgewickelt; ein Upfront-Flow wird vor dem Ausführen des Handlers abgewickelt. Escrow-basierte Flows führen finanzierte Guthaben ein und führen später eine Einziehung oder Rückgabe durch. Ein exakter Preis allein verrät dir nicht, wann die Berechnung im Verhältnis zur Abwicklung beginnt. Schema- und Zahlungsfluss-Übersicht.
Die Trennung ist nützlich, um einen Fehler zu verstehen. Eine abgelehnte Autorisierung bedeutet, dass der Dienst die vorgeschlagene Zahlung nicht akzeptiert hat. Eine gesendete Transaktion, die auf eine Bestätigung wartet, bedeutet, dass das Geld noch bewegt werden kann. Eine abgeschlossene Zahlung mit einer fehlenden Ressource ist ein Auslieferungsproblem.
Eine Schnittstelle, die diese Zustände zu „Zahlung fehlgeschlagen“ zusammenfasst, begünstigt teure Wiederholungsversuche. Der Client sollte die Identität der Anfrage beibehalten und den vorherigen Versuch abgleichen, bevor er einen weiteren Kauf autorisiert. Software kann einen fehlerhaften Checkout viel schneller wiederholen als ein Mensch.
Der Facilitator übernimmt die Zahlungs-Infrastruktur
Ein Facilitator kann Zahlungs-Payloads verifizieren, Abwicklungs-Transaktionen einreichen und deren Status melden. Ein Resource-Server kann einen verwalteten Produktionsanbieter nutzen, seinen eigenen Dienst betreiben oder diese Funktionen selbst übernehmen. Gehe nicht davon aus, dass der öffentliche Quickstart-Facilitator die Produktionsroute für jedes Netzwerk ist. Facilitator-Dokumentation.
Der gewählte Facilitator beeinflusst die Betriebsabhängigkeiten des Dienstes. Der Verkäufer benötigt Unterstützung für sein Netzwerk, seinen Token und sein Zahlungsschema. Er benötigt zudem eine praktikable Reaktion, wenn der Anbieter langsam oder nicht verfügbar ist.
Eine Non-Custodial-Verifizierung macht nicht jeden Teil des Geschäfts unabhängig. Ein Anbieter kann unfähig sein, Transaktionen einzureichen, ohne die Mittel des Kunden zu halten. Ein API-Gateway kann die Bereitstellung von Ressourcen stoppen, ohne die Wallet zu kontrollieren. Diese Fehler gehören in unterschiedliche Teile des Incident-Plans.
Bevor ich einen kostenpflichtigen Endpunkt launche, würde ich die Route mit dem Produktionsanbieter und der realen Contract-Konfiguration testen. Eine erfolgreiche Testnet-Zahlung stellt fest, dass die Integration in dieser Umgebung funktionieren kann. Sie stellt keine Produktions-Liquidität, Preisgestaltung oder Zuverlässigkeit fest.
Das Schema ändert sich, wenn Geld bewegt wird
Eine exakte Zahlung spezifiziert einen definierten Betrag. Eine Up-to-Zahlung autorisiert eine Obergrenze für die Nutzung, deren Endkosten niedriger ausfallen können. Batch-Abwicklungen sammeln Gebühren für eine spätere Onchain-Einlösung, während Auth-Capture ein hinterlegtes, erstattungsfähiges Muster unterstützt. Dies sind unterschiedliche Entscheidungen für einen Verkäufer, der pro Anfrage oder pro Arbeitseinheit abrechnet. Zahlungsschemata.
Eine Datensuche zu einem Festpreis passt zu einem anderen Abrechnungsproblem als die Erzeugung einer Antwort, deren Rechenkosten von der Ausgabelänge abhängen. Letzteres benötigt ein klares Maximum und eine messbare Endgebühr. Der Käufer sollte wissen, wie der Verkäufer diese Gebühr berechnet.
Im dokumentierten EVM-Batch-Muster finanziert der Käufer das Escrow und unterzeichnet kumulative Gutscheine. Der Verkäufer kann später Ansprüche geltend machen und die Erlöse durch eine separate Abwicklungsoperation abheben. Das erklärt, wie verzögerte Gebühren einziehbar bleiben können, während gleichzeitig Finanzierungs- und Einlösungsregeln zur Überprüfung hinzugefügt werden. Batch-Abwicklungsmechanismus.
Aus diesem Grund sollten eine Million bezahlte Anfragen nicht automatisch als eine Million Blockchain-Transaktionen beschrieben werden. Der Artikel über Mikrozahlungs-Ökonomie folgt den Kosten auf jeder Ebene, anstatt die Anzahl der Anfragen als Proxy für die Chain-Einnahmen zu verwenden.
Ein KI-Modell ist nicht der Zahlungs-Signierer
Das Modell kann entscheiden, dass eine Ressource nützlich ist, und eine Kaufanfrage an ein Tool weiterleiten. Ein Wallet-Service oder eine Signatur-Komponente erstellt die autorisierte Finanzaktion. Diese Rollen sollten im Systemdesign sichtbar sein.
Dem Modell eine Aufgabenanweisung wie „verständig ausgeben“ zu geben, bietet einen schwächeren Schutz als ein erzwungenes Transaktionslimit. Ein stärkeres Setup prüft den Händler, die Währung, den Maximalbetrag und das verbleibende Budget, bevor der Signierer die Anfrage genehmigt.
Es gibt auch einen Unterschied zwischen einem einzelnen Kauf und einer fortlaufenden Berechtigung. Eine Zahlung für eine Ressource sollte einem Verkäufer nicht stillschweigend Zugang zu einem uneingeschränkten Guthaben gewähren. Unser Agent-Wallet-Artikel erklärt, wie Verwahrung und Ausgabeberechtigungen diese Grenze definieren.
Die Identität des Agenten ist eine weitere separate Frage. Eine Zahlung beweist eine Finanzaktion unter dem relevanten Mechanismus. Sie beweist nicht, dass der Käufer ein einzigartiger, kompetenter oder ehrlicher KI-Agent ist. ERC-8004 befasst sich mit der Identifizierung und Vertrauenssignalen rund um Agenten, anstatt den Zahlungswechsel zu ersetzen.
Zahlung und nützliche Lieferung benötigen Belege
Der Service sollte die Ressource und die Preiseinheit klar identifizieren. „Eine Antwort“ kann ein Suchergebnis, ein vollständiger Datensatz oder eine Seite mit Datensätzen bedeuten. Eine mehrdeutige Abrechnung erschwert den Vergleich sowohl für Menschen als auch für Agenten.
Signierte Angebote und Belege können helfen, einen Kauf an die erklärten Bedingungen und ein aufgezeichnetes Ergebnis zu binden. Sie beweisen immer noch nicht, dass jeder Fakt in einem gelieferten Datensatz korrekt ist. Ein Käufer benötigt eine Möglichkeit, die Aktualität, Herkunft und die Frage zu bewerten, ob die Antwort der Aufgabe dient. Signierte Angebote und Belege.
Definiere bei teurer oder variabler Arbeit, was als abrechenbarer Erfolg gilt. Ein leeres Ergebnis könnte eine gültige Antwort auf eine Suchanfrage sein, aber diese Regel sollte vor dem Kauf festgelegt werden. Das Gleiche gilt für eine fehlgeschlagene Berechnung oder eine nicht verfügbare Upstream-Quelle.
Das Distributionsproblem des Verkäufers bleibt bestehen. Die Aktivierung von x402 macht einen Endpunkt nicht automatisch auffindbar oder bezahlenswert. Der Verkauf von Daten an Agenten deckt diese Seite des Geschäfts ab.
Was man in einer x402-Demo prüfen sollte
Achte auf ein sichtbares Angebot, eine eingeschränkte Autorisierung und ein eindeutiges Abrechnungsergebnis. Bitte das Team, eine Anfrage nach einem simulierten Timeout zu wiederholen, und zeige, dass der ursprüngliche Kauf nicht doppelt abgerechnet wird. Frage dann, was passiert, wenn die Zahlung erfolgreich ist, aber die Antwort verloren geht.
Eine nützliche Demo schließt die Aufgabe des Kunden unter diesen Bedingungen ab. Ein Screenshot eines Transfer-Explorers beweist weit weniger. Software, die eine Ressource kauft, benötigt einen zuverlässigen kommerziellen Austausch rund um die Transaktion.
Für einen alternativen Protokoll- und Merchant-Integrationsansatz lies x402 vs MPP. Die Wahl beginnt beim Abrechnungsmodell des Dienstes und den Zahlungsmethoden, die seine Kunden nutzen können.
Ein Timeout benötigt zwei separate Antworten
Angenommen, ein Verkäufer hat eine Zahlung für eine Wetterbeobachtung akzeptiert, aber der Client hat die Antwort nie erhalten. Der nächste Schritt hängt von zwei Datensätzen ab: Wurde der Kauf abgerechnet und wurde diese Beobachtung geliefert?
Ein abgerechneter Kauf mit einer fehlenden Antwort benötigt einen Pfad zur Liefer-Wiederherstellung. Eine vor der Annahme abgelehnte Autorisierung benötigt eine Erklärung des Zahlungsfehlers. Eine Zahlung, deren Ergebnis noch unbekannt ist, benötigt eine Abstimmung vor einer erneuten Autorisierung.
Der Zahlungsidentifikator kann helfen, einen Retry mit dem ursprünglichen Kauf zu verknüpfen, wenn die Erweiterung implementiert ist. Der Verkäufer benötigt immer noch eine Regel für die Rückgabe oder Wiederherstellung der gekauften Ressource. Payment-Identifier-Erweiterung.