402 Payment Required su richieste senza token, allegando il campo accepts: [...] che elenca le catene / asset / prezzi accettabili; il client firma localmente una transazione autorizzata (su EVM è Permit2 / EIP-712, su Solana è l’autorizzazione del trasferimento di token SPL), inserisce l’envelope codificato in base64 nell’intestazione PAYMENT-SIGNATURE e la reinvia. Dopo la verifica, il server procede al pagamento on-chain e restituisce il risultato dell’operazione.
Il client X402 di Ace Data Cloud chiama direttamente l’API di destinazione e utilizza il402 Payment Requiredrestituito in tempo reale eacceptscome base per il prezzo e la firma. La capacità di pagamento del Facilitator può essere verificata in/.well-known/x402.
@acedatacloud/sdk e acedatacloud espongono entrambi un hook paymentHandler: quando una richiesta inviata dal SDK riceve un 402, chiama il tuo handler iniettato per ottenere l’intestazione PAYMENT-SIGNATURE, quindi reinvia la richiesta originale. Utilizzando @acedatacloud/x402-client / acedatacloud-x402 insieme al SDK, l’intero processo è completamente trasparente per il codice aziendale—basta usare client.openai.chat.completions.create(...), che appare identico al modello token, ma sotto il cofano è a pagamento per chiamata, senza necessità di ricarica anticipata.
Questo articolo:
- Ha eseguito una vera e propria catena “senza token + iniezione di handler X402” sul lato TS (Verifica T12)
- Ha elencato le differenze tra le due catene di firma EVM / Solana
- Ha fornito tre modalità di adattamento: modalità chiave privata
viem, modalità portafoglio browser, modalitàEVMAccountSignerPython - Ha chiarito il campo
preferScheme/prefer_scheme, che è facile da fraintendere
I. Panoramica del Protocollo (da leggere assolutamente)
Una chiamata X402 di successo coinvolge 3 RTT HTTP:PAYMENT-SIGNATURE. Struttura (estratto):
x402Version: 2, e utilizza l’oggetto accepted per dichiarare il scheme e la network scelti (identificazione CAIP-2).
preferScheme / prefer_scheme viene utilizzato per selezionare una preferenza quando il server offre più schemi contemporaneamente. Se il server espone solo exact, questo campo verrà ignorato; se è impostato su upto ma il server non lo espone, si tornerà al primo elemento corrispondente.
II. TypeScript: Portafoglio Browser + Due modalità di utilizzo del server viem
Installazione
createX402PaymentHandler Firma Completa
(ctx) => Promise<{ headers: Record<string, string> }> che corrisponde esattamente alla firma dell’hook paymentHandler del SDK.
Utilizzo 1: Browser (MetaMask / WalletConnect)
MaxUint256, scritto sulla catena); la seconda è la firma EIP-712 dell’envelope X402 (non sulla catena, solo per la verifica del facilitator). Le chiamate successive richiederanno solo la seconda firma, l’esperienza sarà “clicca una volta per firmare → ottieni il risultato”.
Utilizzo 2: Server Node + chiave privata viem (adatto per backend / CLI)
@acedatacloud/x402-client sul lato TS accetta solo provider EIP-1193—non gestisce direttamente le chiavi private. Nello scenario Node / CLI, la prassi standard è utilizzare viem per incapsulare la chiave privata in un WalletClient, quindi utilizzare @ethereumjs/util o l’adattamento EIP-1193 interno di viem.
Se pensi che l’adattamento EIP-1193 di viem non sia abbastanza stabile, puoi anche utilizzare un approccio più di basso livellosignEVMUptoPayment, concatenando tu stesso il percorsoaccepts → signed envelope → PAYMENT-SIGNATURE header, saltando i ganci SDK; tuttavia, si consiglia comunque di preferirecreateX402PaymentHandler, per evitare di dover mantenere gli aggiornamenti del protocollo.
Uso 3: Solana
exact, quindi preferScheme non ha effetto su Solana.
Tre, Python: modalità chiave privata
Ilacedatacloud-x402 di Python segue la strada di firmare direttamente con la chiave privata (senza astrazione EIP-1193), più adatta per server / esecutori di task.
Installazione
EVM (Base / Skale)
Solana
Approvazione una tantum (solo EVM la prima volta)
Su EVM Base, X402 utilizza Permit2, richiedendo che il portafoglio approvi una volta il contratto Permit2 per USDC con unMaxUint256. acedatacloud-x402 include approve_permit2:
Quattro, verifica di esecuzione reale
Obiettivo del test: SDK TS senza passare token, iniettare gestore X402, in grado di costruire e avviare richieste normalmente (verifica leggera senza consumare USDC sulla vera catena).- Non avendo passato
apiToken, la costruzione SDK non genera errori, dimostrando che la modalità X402 è effettivamente un sostituto legittimo del token. createX402PaymentHandlerrestituisce una funzione (gancio), che SDK utilizza solo quando riceve un 402.- I test end-to-end di pagamento sulla vera catena, poiché coinvolgono il prelievo reale di USDC, non sono stati inclusi in questo tutorial; puoi fare riferimento alla Guida all’integrazione X402 per esempi e2e.
Anche il lato Pythoncreate_x402_payment_handlerha effettuato la stessa verifica - il valore restituito dalla funzione è callable, e iniettandopayment_handler=...non genera errori nella costruzione diAceDataCloud(...). Le semantiche sono allineate su entrambi i lati.
Cinque, confronto con la modalità “Bearer token”
Sei, trappole comuni
- La classe chat deve avere
preferScheme=upto: usareexactfarà sì che il facilitator detragga USDC in base amaxAmountRequired(non all’uso effettivo). - Non passare la chiave privata nuda al
createX402PaymentHandlerdal lato Node: il pacchetto TS non accetta{ privateKey }, deve essere incapsulato in un provider EIP-1193 (si consiglia viemWalletClient). - La prima chiamata è una doppia firma: la prima volta si firma il Permit2 approve (on-chain, con gas), la seconda volta si firma l’involucro X402 (off-chain). Le chiamate successive richiederanno solo la seconda firma.
- Solana non ha il concetto di Permit2: si firma direttamente l’autorizzazione al trasferimento di token SPL, non è necessario approvare; ma attualmente la catena Solana supporta solo
exact. - Distinzione tra errori di business e errori di pagamento: 402 → il handler fallisce lanciando
X402SignError(il tipo specifico varia a seconda della catena); gli errori dell’interfaccia di business dopo un nuovo invio (401 / 422 / 5xx) vengono ancora classificati come eccezioni SDK normali. - Scrittura più stabile per l’adattamento di
viem:evmProvider: walletClient as anyperderà il controllo dei tipi ma avrà la migliore compatibilità; se si desidera mantenere i tipi, utilizzare.transport.requestdi viem per incapsulare separatamente l’oggetto{ request }.

