Skip to main content
X402 är ett on-chain betalningsprotokoll föreslaget av Coinbase som “debiterar enligt HTTP 402”: servern returnerar 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 med 402 Payment Required och accepts som 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 viem privatnyckelsläge, webbläsarplånboksläge, Python EVMAccountSigner-läge
  • Klargör fältet preferScheme / prefer_scheme som är lätt att snubbla över

I. Protokollöversikt (måste läsas)

Ett framgångsrikt X402-anrop involverar 3 HTTP RTT:
X402-kuvertet är en JSON-sträng som efter base64-kodning placeras i PAYMENT-SIGNATURE-huvudet. Struktur (utdrag):
Kuvertets översta nivå är 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

Testade versionsnummer:

createX402PaymentHandler Fullständig signatur

Returvärdet är en (ctx) => Promise&lt;{ headers: Record<string, string> }> som exakt matchar SDK:s paymentHandler hook-signatur.

Användning 1: Webbläsare (MetaMask / WalletConnect)

Vid första anropet kommer webbläsaren att visa två signaturpromptar: den första är en engångs godkännande av Permit2 för USDC (beloppet är 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 med signEVMUptoPayment, och själv koppla ihop accepts → signed envelope → PAYMENT-SIGNATURE header, hoppa över SDK-krokar; men det rekommenderas att först välja createX402PaymentHandler för att slippa underhålla protokolluppgraderingar.

Användning 3: Solana

Solana-kedjan exponerar för närvarande endast exact scheme, så preferScheme fungerar inte på Solana.

Tre, Python: privat nyckel läge

Pythons acedatacloud-x402 går den direkta vägen att signera med privat nyckel (ingen EIP-1193-abstraktion), mer lämplig för server / uppgiftsexekverare.

Installation

Verktygsversioner:

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ångs MaxUint256 godkännande för USDC. acedatacloud-x402 har inbyggd approve_permit2:
Denna transaktion behöver bara skickas en gång, efter det används denna auktorisering för alla X402 EVM-betalningar. Solana behöver inte detta.

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).
Utdata:
Resultatet visar:
  • Ingen apiToken skickades, SDK-konstruktionen ger ingen fel vilket bevisar att X402-läget verkligen är en legitim ersättning för token.
  • createX402PaymentHandler returnerar 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-sidan create_x402_payment_handler har också genomfört samma verifiering - funktionsreturvärdet är callable, och när payment_handler=... injiceras, ger AceDataCloud(...) ingen fel. Båda sidor har samma betydelse.

Fem, jämförelse med “Bearer token-läge”