Qu'est-ce que x402.
x402 est un protocole ouvert pour les paiements natifs HTTP, publié par Coinbase fin 2024. Il définit comment un serveur renvoie 402 Payment Required avec un corps JSON structuré - une liste d'exigences de paiement acceptables (schéma, réseau, identifiant de chaîne, adresse du destinataire, montant en unités de base USDC, et un identifiant de demande de paiement) - afin qu'un client machine puisse analyser la réponse, payer on-chain, et réessayer l'appel original avec un en-tête X-Payment, le tout de manière programmatique.
HTTP 402 est resté inutilisé pendant trente ans. x402 l'a fait fonctionner.
The 402 Payment Required status code was reserved in the original HTTP spec for "future use" and never received a standardized implementation. For three decades, every actual payment flow on the web was built on top of 200 / 401 / 403: a server returns 401 when authentication is missing, the client signs up via a separate UI flow, gets credentials, and re-authenticates. The signup happens out of band. None of this works for AI agents, which cannot complete signup forms.
x402 fixes this by giving 402 a usable specification. A server can return 402 with structured machine-readable payment instructions; a client can parse those instructions, pay, and retry, all without ever touching a signup form. The protocol is the missing piece between "AI agents can call APIs" and "AI agents can pay for the APIs they call". Before x402, the only practical agent payment paths were pre-paid balance accounts (with manual top-up) or proprietary integrations per API. Both broke at scale.
L'importance stratégique de x402 est qu'il établit une norme sur laquelle le reste de l'écosystème peut se baser. Les portefeuilles implémentent un gestionnaire x402 une fois, et chaque API conforme à x402 fonctionne avec ce portefeuille. Les frameworks serveur implémentent un middleware x402 une fois, et chaque client conscient de x402 peut leur payer. Les facilitateurs (services qui règlent les paiements sous-jacents) rivalisent sur la qualité du service plutôt que sur le verrouillage.
Une réponse, une nouvelle tentative, un paiement.
Le cycle de vie a trois états : appel impayé, paiement, appel réessayé. Voici à quoi ressemble réellement la réponse de l'appel impayé sur le fil.
HTTP/1.1 402 Payment Required Content-Type: application/json { "resource": "POST /api/research-query", "accepts": [ { "scheme": "exact-usdc", "network": "mainnet", "chainId": "eip155:8453", "payToAddress": "0xAgent...", "amountWeiUsdc": "50000", "paymentRequestId": "pr_01J9...", "maxAgeSeconds": 60 } ] }
- Status code 402. Distinct from 401 (auth missing) and 403 (auth refused). The presence of 402 signals "payment is the missing input."
- resource + accepts[]. Le corps nomme la ressource protégée et énumère une ou plusieurs exigences de paiement acceptables. Une migration peut citer deux exigences (par exemple, mainnet et testnet) et laisser le client choisir.
- scheme / network / chainId. Le schéma de paiement (exact-usdc), la chaîne (mainnet est Base) et son identifiant CAIP-2. Le client correspond à ceux-ci avant de payer.
- payToAddress / amountWeiUsdc. Le portefeuille du destinataire et le montant exact en unités de base USDC (50000 = 0,05 USDC, 6 décimales). Le client vérifie les deux avant de payer.
- paymentRequestId + maxAgeSeconds. L'identifiant lie le paiement à cette citation ; maxAgeSeconds est combien le paiement doit être frais. Un paiement qui fait référence à un identifiant différent, ou qui est plus ancien que la fenêtre, est rejeté.
- Le réessai transporte un en-tête X-Payment. Le client paie sur la chaîne, puis réémet la demande d'origine avec un en-tête X-Payment prouvant le paiement. Le serveur le vérifie et renvoie le résultat réel. Aucun en-tête de réponse ou page hébergée ne fait partie du fil x402 lui-même.
x402 dans la nature.
Trois déploiements concrets, classés par maturité de l'adoption dans chaque couche.
Serveur MCP retournant un défi 402 à un appel d'outil non payé
Un outil MCP payant reçoit une invocation de Claude Desktop et l'appelant n'est pas encore marqué comme payé. Le serveur construit un défi requirePayment - un 402 dont le corps contient le prix et une hostedUrl - et le renvoie comme une erreur d'outil. Claude Desktop rend le lien dans le chat ; l'utilisateur paie 0,05 $ USDC ; l'appel suivant au même outil réussit.
Facturation par appel pour les points de terminaison API
Une API de recherche facture 0,50 $ par appel derrière l'adaptateur de serveur x402. Un agent AI appelle le point de terminaison, obtient un 402 listant le montant et le destinataire, paie sur Base depuis son portefeuille, et réémet la demande avec un en-tête X-Payment. L'adaptateur vérifie l'en-tête et renvoie la réponse payée. L'ensemble de la boucle se termine en moins de 60 secondes.
Agent payant par programmation via un portefeuille compatible x402
Le runtime d'un agent est conscient de x402 (il implémente la spécification). Lorsqu'il rencontre un 402, il lit le payToAddress et le montant depuis accepts[], signe un transfert depuis son portefeuille pré-autorisée (dans le cadre de sa permission de dépense), diffuse sur Base et réessaie l'appel original avec un en-tête X-Payment. Pas d'intervention humaine ; la boucle se termine en 5 à 10 secondes.
Ce qui entoure x402 dans la pile.
x402 est le protocole. Ces trois termes couvrent les concepts sur lesquels il repose et les cas d'utilisation qu'il permet.