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ückgegebene402 Payment Requiredundacceptsals 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, PythonEVMAccountSigner-Modus - Klärt das leicht missverständliche Feld
preferScheme/prefer_scheme
I. Protokollübersicht (unbedingt lesen)
Ein erfolgreicher X402-Aufruf umfasst 3 HTTP RTT:PAYMENT-SIGNATURE-Header enthalten ist. Struktur (Auszug):
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
createX402PaymentHandler vollständige Signatur
(ctx) => Promise<{ headers: Record<string, string> }> und passt genau zur Signatur des paymentHandler-Hooks des SDK.
Anwendung 1: Browser (MetaMask / WalletConnect)
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 tieferliegendensignEVMUptoPaymentverwenden, um selbst den Wegaccepts → signed envelope → PAYMENT-SIGNATURE headerzu verbinden und die SDK-Hooks zu überspringen; jedoch wird empfohlen, weiterhincreateX402PaymentHandlerzu verwenden, um die Wartung von Protokoll-Upgrades zu vermeiden.
Verwendung 3: Solana
exact scheme bereitgestellt, daher hat preferScheme auf Solana keine Wirkung.
Drei, Python: Private-Key-Modus
Das Python-Paketacedatacloud-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
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 vonMaxUint256 für den Permit2-Vertrag für USDC erteilen muss. acedatacloud-x402 enthält die Funktion approve_permit2:
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).- 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. createX402PaymentHandlergibt 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-Seitecreate_x402_payment_handlerhat ebenfalls die gleiche Validierung durchgeführt - der Rückgabewert ist callable, und beim Injizieren vonpayment_handler=...gibt es beim KonstruktorAceDataCloud(...)keine Fehler. Die Semantik ist auf beiden Seiten abgestimmt.

