Skip to main content
X402 ist ein von Coinbase vorgeschlagenes „HTTP 402-basiertes“ On-Chain-Zahlungsprotokoll: Der Server gibt bei Anfragen ohne Token 402 Payment Required zurück und fügt das Feld accepts: [...] hinzu, um akzeptierte Chains / Assets / Preise aufzulisten; der Client signiert lokal eine Autorisierung (auf EVM ist das Permit2 / EIP-712, auf Solana ist es die SPL-Token-Transfer-Autorisierung), packt das base64-kodierte Envelope in den PAYMENT-SIGNATURE-Header und sendet die Anfrage erneut. Der Server validiert und führt die tatsächliche Abrechnung on-chain durch und gibt das Geschäftsergebnis zurück.
Der X402-Client von Ace Data Cloud ruft direkt die Ziel-API auf und verwendet die in dieser Anfrage in Echtzeit zurückgegebene 402 Payment Required und accepts als Preis- und Signaturbasis. Die Zahlungsfähigkeit des Facilitators kann unter /.well-known/x402 überprüft werden.
@acedatacloud/sdk und acedatacloud bieten beide einen paymentHandler-Hook an: Wenn eine vom SDK selbst gesendete Anfrage 402 erhält, wird der von Ihnen injizierte Handler aufgerufen, um den PAYMENT-SIGNATURE-Header zu erhalten und die ursprüngliche Anfrage erneut zu senden. Die Kombination von @acedatacloud/x402-client / acedatacloud-x402 mit dem SDK macht den gesamten Prozess für den Geschäftscode völlig transparent – Sie verwenden einfach client.openai.chat.completions.create(...), es sieht genau wie das Token-Modell aus, aber im Hintergrund wird nach Nutzung abgerechnet, ohne dass eine vorherige Aufladung erforderlich ist. Dieser Artikel:
  • Hat die TS-Seite der „ohne Token + X402-Handler-Injektion“-Verbindung (siehe T12-Überprüfung) durchlaufen
  • Hat die Unterschiede zwischen den beiden Signaturverbindungen EVM / Solana aufgelistet
  • Bietet drei Anpassungen für viem-Privatschlüsselmodus, Browser-Wallet-Modus, Python EVMAccountSigner-Modus
  • Klärt das leicht missverständliche Feld preferScheme / prefer_scheme

I. Protokollübersicht (unbedingt lesen)

Ein erfolgreicher X402-Aufruf umfasst 3 HTTP RTT:
Das X402-Envelope ist ein JSON-Dokument, das base64-kodiert im PAYMENT-SIGNATURE-Header enthalten ist. Struktur (Auszug):
Das Envelope hat an oberster Stelle x402Version: 2 und erklärt mit dem accepted-Objekt das gewählte scheme und network (CAIP-2 Kennung). preferScheme / prefer_scheme wird verwendet, um bei gleichzeitiger Bereitstellung mehrerer Schemes auf dem Server eine Präferenz auszuwählen. Wenn der Server nur exact bereitstellt, wird dieses Feld ignoriert; wenn upto gesetzt ist, aber der Server es nicht bereitstellt, wird auf den ersten Übereinstimmungspunkt zurückgegriffen.

II. TypeScript: Browser-Wallet + Server viem zwei Anwendungsarten

Installation

Getestete Versionsnummern:

createX402PaymentHandler vollständige Signatur

Der Rückgabewert ist ein (ctx) => Promise&lt;{ headers: Record<string, string> }> und passt genau zur Signatur des paymentHandler-Hooks des SDK.

Anwendung 1: Browser (MetaMask / WalletConnect)

Bei der ersten Anfrage wird der Browser zweimal eine Signaturaufforderung anzeigen: Das erste Mal ist es eine einmalige Genehmigung (approve) für USDC durch Permit2 (Betrag ist MaxUint256, wird in die Chain geschrieben); das zweite Mal ist es die EIP-712-Signatur des X402-Envelopes (nicht on-chain, nur zur Validierung durch den Facilitator). Bei nachfolgenden Aufrufen ist nur die zweite Signatur erforderlich, die Erfahrung ist „einmal auf Signieren klicken → Ergebnis erhalten“.

Anwendung 2: Node-Server + viem-Privatschlüssel (geeignet für Backend / CLI)

@acedatacloud/x402-client akzeptiert auf der TS-Seite nur EIP-1193-Provider – es verwaltet die Privatschlüssel nicht direkt. Im Node-/CLI-Szenario ist es üblich, viem zu verwenden, um den Privatschlüssel in einen WalletClient zu verpacken und dann @ethereumjs/util oder die interne EIP-1193-Anpassung von viem zu verwenden.
Wenn die EIP-1193 Anpassung von viem nicht stabil genug erscheint, kann man auch den tieferliegenden signEVMUptoPayment verwenden, um selbst den Weg accepts → signed envelope → PAYMENT-SIGNATURE header zu verbinden und die SDK-Hooks zu überspringen; jedoch wird empfohlen, weiterhin createX402PaymentHandler zu verwenden, um die Wartung von Protokoll-Upgrades zu vermeiden.

Verwendung 3: Solana

Auf der Solana-Kette wird derzeit nur das exact scheme bereitgestellt, daher hat preferScheme auf Solana keine Wirkung.

Drei, Python: Private-Key-Modus

Das Python-Paket acedatacloud-x402 verwendet den direkten Ansatz mit privatem Schlüssel zur Signatur (keine EIP-1193 Abstraktion), was es besser für Server / Task-Executor geeignet macht.

Installation

Getestete Versionsnummern:

EVM (Base / Skale)

Solana

Einmalige Genehmigung (nur EVM beim ersten Mal)

EVM Base verwendet für X402 Permit2, was bedeutet, dass die Wallet einmal eine Genehmigung von MaxUint256 für den Permit2-Vertrag für USDC erteilen muss. acedatacloud-x402 enthält die Funktion approve_permit2:
Diese Transaktion muss nur einmal gesendet werden, danach wird diese Genehmigung für alle X402 EVM-Zahlungen verwendet. Solana benötigt dies nicht.

Vier, echte Ausführungsvalidierung

Testziel: TS SDK ohne Token übergeben, X402-Handler injizieren, um Anfragen korrekt zu konstruieren und zu initiieren (leichte Validierung, die keine echten USDC auf der Kette verbraucht).
Ausgabe:
Ergebnisbeschreibung:
  • Es wurde kein apiToken übergeben, das SDK wurde ohne Fehler konstruiert, was beweist, dass der X402-Modus tatsächlich eine legale Alternative zum Token ist.
  • createX402PaymentHandler gibt eine Funktion (Hook) zurück, die das SDK nur aufruft, wenn es 402 erhält.
  • End-to-End-Tests für Zahlungen auf der echten Kette wurden nicht in dieses Tutorial aufgenommen, da sie echte USDC-Abzüge betreffen; siehe X402 Integrationsleitfaden für e2e-Beispiele.
Der Python-Seite create_x402_payment_handler hat ebenfalls die gleiche Validierung durchgeführt - der Rückgabewert ist callable, und beim Injizieren von payment_handler=... gibt es beim Konstruktor AceDataCloud(...) keine Fehler. Die Semantik ist auf beiden Seiten abgestimmt.

Fünf, Vergleich mit dem „Bearer-Token-Modus“