Skip to main content
X402 est un protocole de paiement en chaîne “facturé par HTTP 402” proposé par Coinbase : le serveur renvoie 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 le 402 Payment Required et accepts renvoyé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, mode EVMAccountSigner Python
  • 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 :
L’enveloppe X402 est un segment JSON, encodé en base64 et placé dans l’en-tête PAYMENT-SIGNATURE. Structure (extrait) :
Le niveau supérieur de l’enveloppe est 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

Numéros de version testés :

Signature complète de createX402PaymentHandler

La valeur de retour est un (ctx) => Promise&lt;{ headers: Record<string, string> }> qui correspond exactement à la signature du hook paymentHandler du SDK.

Utilisation 1 : Navigateur (MetaMask / WalletConnect)

Lors du premier appel, le navigateur affichera deux fois une invite de signature : la première est une approbation unique de Permit2 pour USDC (le montant est 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 niveau signEVMUptoPayment, en reliant vous-même accepts → signed envelope → PAYMENT-SIGNATURE header, en contournant les hooks du SDK ; cependant, il est recommandé de privilégier createX402PaymentHandler pour éviter de maintenir vous-même les mises à jour du protocole.

Utilisation 3 : Solana

La chaîne Solana expose actuellement uniquement le schéma exact, donc preferScheme n’a pas d’effet sur Solana.

Trois, Python : Mode clé privée

Le acedatacloud-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

Versions testées :

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 de MaxUint256 pour le contrat Permit2 sur USDC. acedatacloud-x402 intègre approve_permit2 :
Cette transaction n’a besoin d’être envoyée qu’une seule fois, après quoi tous les paiements X402 EVM utiliseront cette autorisation. Solana n’en a pas besoin.

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).
Sortie :
Résultats :
  • 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.
  • createX402PaymentHandler retourne 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é Python create_x402_payment_handler a également effectué la même validation - la valeur de retour de la fonction est callable, et lors de l’injection payment_handler=..., la construction AceDataCloud(...) 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

  1. La classe chat doit preferScheme=upto : utiliser exact fera que le facilitateur déduira l’USDC selon maxAmountRequired (et non selon la consommation réelle).
  2. Ne pas transmettre la clé privée brute au createX402PaymentHandler côté Node : le paquet TS n’accepte pas { privateKey }, il doit être encapsulé dans un fournisseur EIP-1193 (recommandé : viem WalletClient).
  3. 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.
  4. 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.
  5. 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.
  6. Écriture la plus stable pour viem : evmProvider: walletClient as any perdra la vérification de type mais a la meilleure compatibilité ; si vous souhaitez conserver le type, utilisez .transport.request de viem pour encapsuler un objet { request } à transmettre.

En savoir plus