402 Payment Required på förfrågningar utan token, med accepts: [...] fältet som listar accepterade kedjor / tillgångar / priser; klienten signerar lokalt en auktorisering (på EVM är det Permit2 / EIP-712, på Solana är det SPL token transfer auktorisering), lägger den base64-kodade kuvertet i PAYMENT-SIGNATURE-huvudet och skickar om. Servern verifierar och gör den verkliga avräkningen på kedjan, och returnerar sedan affärsresultatet.
Ace Data Cloud:s X402-klient anropar direkt målet API och använder den begäran som returneras i realtid med402 Payment Requiredochacceptssom pris- och signeringsgrund. Facilitatorns betalningskapacitet kan verifieras på/.well-known/x402.
@acedatacloud/sdk och acedatacloud exponerar båda en paymentHandler hook: när SDK:n själv skickar en begäran och får 402, anropar den din injicerade handler för att få PAYMENT-SIGNATURE-huvudet och skickar om den ursprungliga begäran. Genom att kombinera @acedatacloud/x402-client / acedatacloud-x402 med SDK:n, är hela processen helt transparent för affärskoden — du behöver bara använda client.openai.chat.completions.create(...), det ser ut som token-modellen men under ytan är det betalning per anrop, utan att behöva ladda upp i förväg.
Denna artikel:
- Gick igenom TS-sidan av “ingen token + X402 handler-injektion” kedjan (se T12 verifiering)
- Listade skillnaderna mellan EVM / Solana två uppsättningar signaturkedjor
- Ger tre anpassningar för
viemprivatnyckelsläge, webbläsarplånboksläge, PythonEVMAccountSigner-läge - Klargör fältet
preferScheme/prefer_schemesom är lätt att snubbla över
I. Protokollöversikt (måste läsas)
Ett framgångsrikt X402-anrop involverar 3 HTTP RTT:PAYMENT-SIGNATURE-huvudet. Struktur (utdrag):
x402Version: 2, och använder accepted-objektet för att deklarera det valda scheme och network (CAIP-2 identifiering).
preferScheme / prefer_scheme används för att välja preferens när servern samtidigt erbjuder flera scheman. Om servern endast exponerar exact, kommer detta fält att ignoreras; om upto är inställt men servern inte exponerar det, kommer det att falla tillbaka till det första matchande alternativet.
II. TypeScript: Webbläsarplånbok + Server viem två användningssätt
Installation
createX402PaymentHandler Fullständig signatur
(ctx) => Promise<{ headers: Record<string, string> }> som exakt matchar SDK:s paymentHandler hook-signatur.
Användning 1: Webbläsare (MetaMask / WalletConnect)
MaxUint256, skrivet på kedjan); den andra är EIP-712-signaturen för X402-kuvertet (som inte går på kedjan, utan bara för verifiering av facilitatorn). Efterföljande anrop kräver bara den andra signaturen, vilket ger en upplevelse av “klicka en gång för signatur → få resultat”.
Användning 2: Node-server + viem privatnyckel (lämplig för backend / CLI)
@acedatacloud/x402-client accepterar endast EIP-1193 provider på TS-sidan — den hanterar inte privatnycklar direkt. I Node / CLI-scenarier är den standardmetoden att använda viem för att paketera privatnyckeln i en WalletClient, och sedan använda @ethereumjs/util eller viems interna EIP-1193-adapter.
Om du tycker att viems EIP-1193-anpassning inte är tillräckligt stabil kan du gå en mer grundläggande väg medsignEVMUptoPayment, och själv koppla ihopaccepts → signed envelope → PAYMENT-SIGNATURE header, hoppa över SDK-krokar; men det rekommenderas att först väljacreateX402PaymentHandlerför att slippa underhålla protokolluppgraderingar.
Användning 3: Solana
exact scheme, så preferScheme fungerar inte på Solana.
Tre, Python: privat nyckel läge
Pythonsacedatacloud-x402 går den direkta vägen att signera med privat nyckel (ingen EIP-1193-abstraktion), mer lämplig för server / uppgiftsexekverare.
Installation
EVM (Base / Skale)
Solana
Engångs godkännande (endast EVM första gången)
EVM Base använder X402 som går genom Permit2, vilket kräver att plånboken ger Permit2-kontraktet en engångsMaxUint256 godkännande för USDC. acedatacloud-x402 har inbyggd approve_permit2:
Fyra, verklig körning och verifiering
Testmål: TS SDK utan att skicka token, injicera X402-handler, kan normalt konstruera och initiera begäran (utan att förbruka verklig USDC på kedjan för lätt verifiering).- Ingen
apiTokenskickades, SDK-konstruktionen ger ingen fel vilket bevisar att X402-läget verkligen är en legitim ersättning för token. createX402PaymentHandlerreturnerar en funktion (hook), SDK kommer endast att anropa den när den får 402.- Verkliga kedjebetalningar har testats end-to-end, eftersom det involverar verkliga USDC-dragningar, har det inte inkluderats i denna handledning; se X402 integrationsguide för e2e-exempel.
Python-sidancreate_x402_payment_handlerhar också genomfört samma verifiering - funktionsreturvärdet är callable, och närpayment_handler=...injiceras, gerAceDataCloud(...)ingen fel. Båda sidor har samma betydelse.

