402 Payment Required sur une requête sans token, accompagné du champ accepts: [...] listant les chaînes / actifs / prix acceptables ; le client signe localement une autorisation (sur EVM, c’est Permit2 / EIP-712, sur Solana, c’est l’autorisation de transfert de token SPL), place l’enveloppe encodée en base64 dans l’en-tête PAYMENT-SIGNATURE et renvoie la requête. Le serveur vérifie ensuite et procède au règlement sur la chaîne, puis renvoie le résultat commercial.
Le client X402 d’Ace Data Cloud appelle directement l’API cible et utilise le402 Payment Requiredetacceptsrenvoyés en temps réel comme base de prix et de signature. La capacité de paiement du Facilitateur peut être vérifiée sur/.well-known/x402.
@acedatacloud/sdk et acedatacloud exposent tous deux un hook paymentHandler : lorsque les requêtes émises par le SDK reçoivent un 402, il appelle votre gestionnaire injecté pour obtenir l’en-tête PAYMENT-SIGNATURE, puis renvoie la requête d’origine. En combinant @acedatacloud/x402-client / acedatacloud-x402 avec le SDK, l’ensemble du processus est totalement transparent pour le code métier — vous n’avez qu’à utiliser client.openai.chat.completions.create(...), cela ressemble exactement au mode token, mais en réalité, c’est un paiement à l’appel, sans besoin de recharger à l’avance.
Cet article :
- A réellement testé le lien “sans token + injection de gestionnaire X402” côté TS (Vérification T12)
- A listé les différences entre les deux chaînes de signature EVM / Solana
- A fourni trois modes d’adaptation : mode clé privée
viem, mode portefeuille de navigateur, modeEVMAccountSignerPython - A clarifié le champ
preferScheme/prefer_scheme, qui est facile à mal utiliser
I. Vue d’ensemble du protocole (à lire absolument)
Un appel X402 réussi implique 3 RTT HTTP :PAYMENT-SIGNATURE. Structure (extrait) :
x402Version: 2, et utilise l’objet accepted pour déclarer le scheme et le network choisis (identifiant CAIP-2).
preferScheme / prefer_scheme est utilisé pour sélectionner une préférence lorsque le serveur propose plusieurs schemes simultanément. Si le serveur n’expose que exact, ce champ sera ignoré ; s’il est défini sur upto mais que le serveur ne l’expose pas, il reviendra au premier élément correspondant.
II. TypeScript : Portefeuille de navigateur + deux méthodes viem côté serveur
Installation
Signature complète de createX402PaymentHandler
(ctx) => Promise<{ headers: Record<string, string> }> qui correspond exactement à la signature du hook paymentHandler du SDK.
Utilisation 1 : Navigateur (MetaMask / WalletConnect)
MaxUint256, écrit sur la chaîne) ; la seconde est la signature EIP-712 de l’enveloppe X402 (non sur la chaîne, juste pour la vérification du facilitateur). Les appels suivants nécessitent uniquement la seconde signature, l’expérience est donc “un clic sur la signature → obtenir le résultat”.
Utilisation 2 : Serveur Node + clé privée viem (adapté pour le backend / CLI)
@acedatacloud/x402-client n’accepte que les fournisseurs EIP-1193 côté TS — il ne gère pas directement les clés privées. Dans les scénarios Node / CLI, la méthode standard consiste à utiliser viem pour encapsuler la clé privée dans un WalletClient, puis d’utiliser @ethereumjs/util ou l’adaptation EIP-1193 interne de viem.
Si vous trouvez que l’adaptation EIP-1193 de viem n’est pas assez stable, vous pouvez également utiliser une méthode plus bas niveausignEVMUptoPayment, en reliant vous-mêmeaccepts → signed envelope → PAYMENT-SIGNATURE header, en contournant les hooks du SDK ; cependant, il est recommandé de privilégiercreateX402PaymentHandlerpour éviter de maintenir vous-même les mises à jour du protocole.
Utilisation 3 : Solana
exact, donc preferScheme n’a pas d’effet sur Solana.
Trois, Python : Mode clé privée
Leacedatacloud-x402 de Python suit la voie de la signature directe avec la clé privée (sans abstraction EIP-1193), plus adapté pour les serveurs / exécuteurs de tâches.
Installation
EVM (Base / Skale)
Solana
Approbation unique (uniquement pour EVM la première fois)
Sur EVM Base, X402 utilise Permit2, nécessitant que le portefeuille fasse une approbation deMaxUint256 pour le contrat Permit2 sur USDC. acedatacloud-x402 intègre approve_permit2 :
Quatre, validation de fonctionnement réel
Objectif du test : SDK TS sans passer de token, injecter le gestionnaire X402, capable de construire et d’initier des requêtes normalement (validation légère sans consommer de l’USDC sur la vraie chaîne).- Sans passer
apiToken, la construction du SDK ne génère pas d’erreur, prouvant que le mode X402 est effectivement un substitut légitime au token. createX402PaymentHandlerretourne une fonction (hook), que le SDK n’appellera que lorsqu’il recevra un 402.- Les tests de bout en bout sur le paiement réel sur la chaîne, impliquant des frais réels en USDC, ne sont pas inclus dans ce tutoriel ; vous pouvez vous référer aux exemples e2e dans le guide d’intégration X402.
Le côté Pythoncreate_x402_payment_handlera également effectué la même validation - la valeur de retour de la fonction est callable, et lors de l’injectionpayment_handler=..., la constructionAceDataCloud(...)ne génère pas d’erreur. Les deux côtés sont alignés sémantiquement.
Cinq, comparaison avec le mode « Bearer token »
VI. Pièges courants
- La classe chat doit
preferScheme=upto: utiliserexactfera que le facilitateur déduira l’USDC selonmaxAmountRequired(et non selon la consommation réelle). - Ne pas transmettre la clé privée brute au
createX402PaymentHandlercôté Node : le paquet TS n’accepte pas{ privateKey }, il doit être encapsulé dans un fournisseur EIP-1193 (recommandé : viemWalletClient). - Le premier appel est une double signature : la première fois, signer le Permit2 approve (sur la chaîne, avec des frais), la deuxième fois, signer l’enveloppe X402 (hors chaîne). Les appels suivants ne nécessitent que la deuxième signature.
- Solana n’a pas le concept de Permit2 : signer directement l’autorisation de transfert de token SPL, pas besoin d’approuver ; mais actuellement, la chaîne Solana ne prend en charge que
exact. - Différencier les erreurs métier et les erreurs de paiement : 402 → échec du gestionnaire lance
X402SignError(type spécifique selon la chaîne) ; les erreurs de l’interface métier après une nouvelle tentative (401 / 422 / 5xx) sont toujours classées comme des exceptions SDK ordinaires. - Écriture la plus stable pour
viem:evmProvider: walletClient as anyperdra la vérification de type mais a la meilleure compatibilité ; si vous souhaitez conserver le type, utilisez.transport.requestde viem pour encapsuler un objet{ request }à transmettre.

