← Meterdoor · Artikel · Stand Oktober 2026

Menschen und KI-Agenten am selben Endpunkt abrechnen

Wie eine API Euro per Karte und USDC per x402 an derselben Adresse annimmt – und was man dabei beachten sollte.

Wer heute eine kostenpflichtige API oder einen bezahlten Datenabruf anbietet, hat zwei Arten von Kunden: Menschen, die im Browser mit Karte zahlen wollen, und zunehmend Software, die selbst zahlt. Für die zweite Gruppe gibt es das offene Protokoll x402: Der Server antwortet mit dem HTTP-Status 402 Payment Required und einer maschinenlesbaren Zahlungsanforderung, der Agent signiert eine Zahlung in USDC und schickt die Anfrage erneut. Seit Juli 2026 liegt das Protokoll bei der x402 Foundation unter dem Dach der Linux Foundation [1].

Die beiden Wege passen technisch schlecht zusammen. Dieser Artikel zeigt, wie sie sich an einem Endpunkt verbinden lassen.

Das Problem: zwei Kassen, zwei Codepfade

Karte über Stripe Checkout braucht eine Weiterleitung, eine Rückkehrseite und danach einen Nachweis, dass bezahlt wurde (Sitzung, Cookie oder Token).
x402 braucht keine Weiterleitung: Die Zahlung steckt im Header X-PAYMENT der Anfrage selbst. Ein Facilitator prüft sie (/verify) und rechnet sie ab (/settle).

Die offiziellen x402-Beispiele für Express, Hono oder Next.js decken nur den Kryptoweg ab. Stripes eigene Beispiele zu Machine Payments zeigen x402 und Karte getrennt [2]. Stripes x402-Annahme ist außerhalb der USA bisher nur auf Antrag zu haben [3].

Die Lösung: an der Anfrage erkennen, wer fragt

Eine Middleware vor der Route entscheidet in dieser Reihenfolge:

Header X-PAYMENT vorhanden? Dann ist es ein Agent mit Zahlung: prüfen, Route ausführen, abrechnen, ausliefern.
Gültiges Zugangstoken? Dann hat ein Mensch schon bezahlt: Daten ausliefern.
Rückkehr aus Stripe Checkout? Sitzung bei Stripe prüfen (bezahlt, richtige Ressource, richtiger Betrag), Token ausgeben.
Browser (Accept: text/html)? Weiterleitung zu Stripe Checkout.
Sonst: 402 mit der x402-Anforderung und einem Link zum Checkout.

GET /api/bericht
Accept: application/json

HTTP/1.1 402 Payment Required
{
  "x402Version": 1,
  "accepts": [{ "scheme": "exact", "network": "base-sepolia",
                "maxAmountRequired": "500000", "payTo": "0x…", "asset": "0x036C…" }],
  "checkout": "https://api.example.com/api/bericht?pw_checkout=1"
}

Der Agent liest accepts, der Mensch (oder ein Agent ohne Wallet) folgt checkout. (Beispieldaten im Testnetz Base Sepolia.)

Sechs Stellen, an denen es schiefgeht

Gleitkomma bei Beträgen. 0.1 + 0.2 ist in JavaScript nicht 0.3. USDC hat 6 Nachkommastellen, Euro-Cent 2. Beträge als String annehmen und ganzzahlig umrechnen ("0.50" → 500000 bzw. 50).
Ausliefern und Abrechnen in falscher Reihenfolge. Wer erst die Daten schickt und dann /settle aufruft, liefert bei fehlgeschlagener Abrechnung gratis; wer zuerst abrechnet, kassiert, auch wenn die Route danach scheitert. Besser: Antwort puffern (mit Größengrenze), dann abrechnen, dann ausliefern – und die Antwort speichern, damit ein Agent nach einem Verbindungsabbruch mit demselben Nachweis noch einmal abrufen kann.
Wiederholung nur an der Nonce erkennen. Wer die gespeicherte Antwort an network:from:nonce knüpft, gibt sie auch an einen Nachweis mit denselben Kennungen, aber ohne gültige Signatur heraus. Beim ersten erfolgreichen Durchlauf einen Fingerabdruck des vollständigen Nachweises (inklusive Signatur, Betrag, Empfänger, Gültigkeit) speichern und vor jeder Wiederholung zeitkonstant vergleichen.
Versehentlich im Hauptnetz. Testnetz (base-sepolia) und Hauptnetz (base) unterscheiden sich nur in einem String. Das Hauptnetz sollte eine bewusste Einstellung sein.
Kauf ohne Bindung. Ein Zugangstoken nach dem Stripe-Kauf muss an Methode und vollen Pfad (in Express req.baseUrl + req.path) und an ein festes Ende ab Zahlung gebunden sein. Und die Checkout-Sitzung selbst muss gegen Betrag, Währung und eine eigene Kennung geprüft werden – payment_status === "paid" allein schaltet auch mit einem fremden Ein-Cent-Checkout frei.
http hinter dem Proxy. Hinter einem Load Balancer meldet Express ohne trust proxy die Ressource als http://… – die Zahlungsanforderung zeigt dann auf die falsche Adresse.

Was das für die Buchhaltung heißt

Euro landen im Stripe-Konto, USDC in der eigenen Wallet. Für jede USDC-Zahlung braucht die Buchhaltung den Transaktions-Hash, den Betrag, das Netzwerk und den Euro-Gegenwert zum Zeitpunkt des Eingangs samt Kursquelle. Ob und wie Umsatzsteuer anfällt und wie die Bestände zu bewerten sind, klären Sie bitte mit Ihrer Steuerberatung; dieser Artikel ist keine Rechts- oder Steuerberatung.

Ehrlich zum Markt

x402.org meldete Mitte Oktober 2026 für 30 Tage über 75 Millionen Transaktionen [4]. Das ist eine unbereinigte Eigenangabe; unabhängige Auswertungen kommen zu dem Ergebnis, dass der weit überwiegende Teil davon Protokoll-Signalisierung und Tests sind, kein echter Zahlungsumsatz. Wer heute einen Agenten-Bezahlweg einbaut, baut für einen Markt, der gerade entsteht. Genau deshalb lohnt es sich, den Kartenweg für Menschen nicht aufzugeben.

Zum Ausprobieren

Wir bauen diese Middleware als Open-Source-Kern (Apache 2.0) für Express. Der Prototyp läuft im Testnetz Base Sepolia und im Stripe-Testmodus. Zur Produktseite · Das Repository wird in Kürze öffentlich.

Quellen (abgerufen 19.10.2026)

Meterdoor ist kein offizielles Produkt von x402, Coinbase oder Stripe.