x402 — un protocole ouvert pour des paiements natifs à Internet

• x402 réactive le code d’état HTTP 402 (Payment Required), longtemps resté inutilisé, afin de permettre des paiements en temps réel et une facturation à l’usage (pay-per-use) sans compte ni clé API, via un protocole de paiement natif à Internet
• Avec une seule ligne de code middleware, les développeurs peuvent exiger un paiement en stablecoin comme l’USDC à chaque requête API, ce qui le rend facile à déployer aussi bien pour de petits micropaiements que pour des services à grande échelle
• Les frais de transaction sont pratiquement nuls et la confirmation du paiement intervient en 200 ms à 2 secondes, ce qui résout les problèmes de latence, rétrofacturation et authentification complexe des systèmes de paiement traditionnels basés sur les cartes ou les comptes bancaires
• Les agents IA, appareils IoT et fournisseurs de contenu peuvent payer de façon autonome les appels API, l’accès aux données et l’usage de ressources cloud, ce qui en fait une infrastructure de base conçue pour le commerce machine-to-machine (M2M)
• Au-delà des modèles traditionnels centrés sur l’abonnement ou la publicité, x402 rend possibles de nouveaux modèles économiques réellement fondés sur les micropaiements, offrant aux développeurs comme aux créateurs un mode de monétisation plus flexible et ouvert

---

Présentation de x402

• Un standard de paiement ouvert porté par la plateforme développeur de Coinbase
• Conçu pour permettre à l’IA et aux services web d’effectuer automatiquement des paiements afin d’accéder à des API, des données et des services numériques
• Une approche native au web qui exploite les en-têtes HTTP et les codes d’état, facilement intégrable dans l’infrastructure serveur existante

Principales caractéristiques

• Sans frais : aucun frais de transaction au niveau du protocole
• Règlement instantané : règlement en 200 ms à 2 secondes sur la base de paiements blockchain
• Indépendant de la blockchain : non lié à une chaîne ou à un token spécifique
• Intégration simple : utilisable sur un serveur web existant avec une seule ligne de code
• Standard ouvert : chacun peut l’implémenter et l’étendre, sans dépendance à un fournisseur centralisé
• Compatible avec l’IA : des agents peuvent traiter les paiements en temps réel pour chaque requête API

Fonctionnement

1. Le client envoie une requête API
2. Si la requête est faite sans information de paiement, le serveur répond avec HTTP 402 Payment Required
3. L’agent renvoie la requête en incluant une signature de paiement
4. Le serveur vérifie et diffuse le paiement, puis renvoie une réponse normale

Cas d’usage

• Agents IA : paiement à l’usage lors d’appels à des données ou modèles en temps réel
• Services cloud : paiement à l’usage pour du stockage ou du temps GPU, sans compte
• Fournisseurs de contenu : paiement à l’unité pour des articles ou vidéos, avec de véritables micropaiements
• IoT / commerce machine : paiements automatiques entre systèmes autonomes

Nouveaux modèles économiques

• Prise en charge de transactions de faible montant et à haute fréquence : paiements possibles à partir de 0,001 $
• Alternative à la publicité et aux abonnements : monétisation sans abonnement forcé ni dépendance à la publicité
• Commerce natif pour l’IA : l’IA peut acheter et utiliser directement des ressources cloud et des API

Support pour les développeurs

• Implémentations de référence : middleware Express.js et Next.js, bibliothèques clientes fournies
• Outils de test : environnement de développement avec portefeuille virtuel et tokens inclus
• Intégration native avec Coinbase AgentKit, pour accélérer le développement d’applications AI-first

Conclusion

• x402 dépasse les limites de l’infrastructure de paiement existante et fournit une couche de paiement adaptée aux machines pour une économie Internet AI-first
• Sans compte, abonnement ni clé API, chacun peut bâtir de nouveaux modèles de commerce numérique sur un standard de paiement ouvert et extensible

[GN⁺]

Avis Hacker News

• Il y a 18 ans, j’avais vu quelqu’un dire : « ce code est prévu pour être utilisé dans le futur », et j’ai l’impression qu’un Redditor avait anticipé le scénario où AT&T, Comcast, TimeWarner et d’autres tenteraient de faire payer Internet, seul le nom ayant changé
• Cela a commencé comme un protocole soutenu par Coinbase, et dans un contexte où Stripe pousse activement dans ce domaine pour enfermer le tout dans son propre écosystème, l’arrivée d’un protocole ouvert paraît positive
  • Si c’est un vrai protocole de paiement ouvert, il devrait pouvoir gérer n’importe quelle devise, et le vendeur comme l’acheteur devraient pouvoir décider eux-mêmes des intermédiaires, du mode de paiement, des politiques d’annulation et de litige, etc. Avec SEPA et d’autres, on pourrait même voir apparaître des moyens de paiement totalement gratuits, instantanés et irrévocables
  • Le problème, ce n’est pas la forme du payload API, c’est que presque aucune banque ne propose d’API REST pour les paiements
  • Vu le soutien de Coinbase, j’ai l’impression que toutes les transactions finiront avec des exigences KYC/AML ; même pour lire un simple message payant, on risque de devoir fournir une facture récente et passer une vérification vidéo ; et si on n’est pas citoyen américain ou qu’on n’a pas de pièce d’identité prise en charge par Coinbase, on sera probablement refusé
• Le protocole met en avant le « sans frais », mais s’il repose sur une blockchain, j’ai du mal à croire qu’il puisse réellement ne pas y avoir de frais de transaction. Pour les petits paiements — avec l’accent mis sur « aucun montant minimum » — les frais en pourcentage ne sont pas forcément un gros problème, mais des frais fixes par transaction peuvent vite peser lourd. En plus, chaque blockchain a une volatilité propre des frais, ce qui ajoute un risque. Je me demande si je comprends mal quelque chose
  • Sur beaucoup de transactions on-chain récentes, le coût du gas est devenu extrêmement bas, souvent sous le centime, donc en pratique presque gratuit ; x402 utilise surtout des réseaux L2 comme Base, donc le coût unitaire de chaque transaction devient à peine un sujet. Référence : infos sur les frais de gas
  • Le protocole lui-même n’ajoute pas de frais ; les frais dépendent du moyen de paiement choisi par l’utilisateur, qu’il s’agisse d’une blockchain, de VISA, etc.
  • x402 lui-même est sans frais, mais les réseaux qui traitent réellement le paiement — blockchain, réseau de paiement, etc. — ont chacun leur propre structure de coûts. Le vendeur peut choisir le réseau qui lui convient, et x402 a une fonction de facilitator qui abstrait le réseau de paiement ; des intermédiaires comme Coinbase prennent aussi souvent en charge le gas nécessaire à la transaction
  • Le fait d’être basé sur la blockchain ne veut pas forcément dire qu’il faut payer des frais à chaque transaction ; on peut aussi approuver le coût par simple signature du wallet, puis regrouper plusieurs opérations pour un traitement en une seule fois
  • Sur la blockchain Base de Coinbase, les frais de transfert USDC sont inférieurs à 1 centime, et c’est du même ordre sur Solana
• Le nom x402 lui-même me paraît un peu suspect et très marketing, comme s’ils voulaient lui donner l’allure d’un protocole standard international du type X.500 ; or il existe déjà un protocole X.402 dans les standards de l’Union internationale des télécommunications (UIT) lien ITU X.402
• Le livre blanc x402 ne mentionne ni Lightning ni Bitcoin ; il ne parle que de Base (Ethereum L2, poussé par Coinbase). Cette focalisation de Coinbase sur l’extension de son propre écosystème me met mal à l’aise. À mon avis, un paiement vraiment libre devrait être construit sur Bitcoin, surtout sur des L2 comme Lightning ou Liquid, plus adaptés à la décentralisation
  • J’ai moi-même développé il y a 5 ans un protocole basé sur le Lightning Network, L402 (ancien nom : LSAT). x402 traite la vérification du reçu de paiement via un canal séparé, donc contrairement à la promesse marketing de « l’intégrer en une ligne de code », il faut en réalité pas mal de code côté client comme côté serveur. À l’inverse, L402 intègre directement dans le protocole la vérification du paiement sur le Lightning Network et prend aussi en charge une autorisation fine basée sur Macaroon. Les avantages du Lightning Network sont la confidentialité, une décentralisation complète et une finalité rapide, de l’ordre de 100 ms. Des chaînes comme celles de Coinbase exposent toutes les transactions au niveau du réseau, reposent sur une instance centrale vulnérable aux pannes, et même Base met plusieurs secondes à finaliser un bloc. Détails : présentation de L402, blog LSAT
  • Je me demande si quelqu’un pourrait aider à intégrer les paiements Lightning dans x402 ; cela permettrait sans doute de sortir de la dépendance à Base
  • Il est souligné qu’il est très difficile de construire une « agentic application » sur une base Bitcoin, alors qu’avec un socle EVM cela devient possible sur plusieurs réseaux ; x402 n’est pas censé rester limité à Base et prévoit de prendre en charge plusieurs réseaux compatibles EVM
  • Présenter Bitcoin comme le seul moyen de parvenir à une « vraie » décentralisation me paraît forcé ; la capacité à gérer Bitcoin a de l’intérêt, mais il peut y avoir plusieurs approches
• Retour d’expérience concret après essai avec un client appelé « Frame »
  1. Recevoir des USDC depuis un faucet est plutôt simple
  2. Une fois Frame connecté au navigateur, x402 a été détecté immédiatement
  3. La première transaction a disparu après l’envoi, avec la page qui restait à charger indéfiniment ; il a fallu lancer une deuxième transaction. En situation réelle, cela pourrait amener à payer deux fois, ce qui est risqué ; la première transaction est probablement encore perdue quelque part dans la mempool
  4. L’outil Frame n’est pas vraiment recommandable : il n’y a pas d’historique des transactions, donc impossible de réémettre avec un nonce ou un gas ajusté ; et l’outil semble en plus à peine maintenu
  5. La deuxième transaction s’est bien passée, et la vitesse de traitement était très rapide
• Cloudflare a un cas d’usage de x402 lien vers le blog Cloudflare
• Je me demande quel est le moyen le plus simple d’envoyer des stablecoins ; en essayant d’utiliser des USDC, j’ai été surpris de voir à la fin un message disant qu’il fallait aussi de l’ether pour payer les frais de gas. Il y avait aussi plusieurs alertes disant qu’en cas d’erreur d’adresse ou de réseau, les coins pouvaient être perdus, ce qui rend l’expérience difficile. Je ne comprends pas pourquoi l’envoi de stablecoins exige autant de pièces différentes et a été rendu aussi complexe. Ce genre de complexité plaît peut-être aux experts crypto, mais pour les paiements grand public c’est beaucoup trop compliqué
  • Les USDC fonctionnent aussi sur Solana et les frais y sont vraiment minimes ; depuis Coinbase vers Solana, les frais paraissent presque nuls. En revanche, la gestion de l’adresse de destination est cruciale : si les fonds partent vers la mauvaise adresse, il n’y a pas de retour possible. C’est un peu comme un virement bancaire américain : si l’on se trompe dans le numéro de compte ou de routage, il y a un problème. Il existe des mécanismes de vérification, mais ils ne sont pas parfaits dans tous les cas ; sur Ethereum, ENS (Ethereum Name Service) essaie d’atténuer un peu ce problème
  • La réponse un peu plate au moyen le plus simple d’envoyer des stablecoins, c’est : donner un wallet à un agent IA et n’y mettre que des USDC. Au fond, ce protocole a été conçu dans le sens des « agentic payments » de Coinbase. Même l’équipe qui l’a créé n’a pas encore complètement défini les cas d’usage concrets ni le mode de fonctionnement final. Cela dit, l’idée qu’un agent IA puisse payer lui-même quand il se heurte à un paywall reste intéressante. La critique sur la complexité est légitime, et les approches de Bridge, Privy ou Stripe paraissent bien plus pratiques
  • x402 abstrait justement les frais de gas ; on peut vraiment l’essayer directement en tant qu’humain, et il est facile de voir comment l’implémenter via la page de démonstration, l’exemple de serveur et l’exemple de client
• Je me demande qui, chez Coinbase, a pensé que le code HTTP 402 n’était pas utilisé ; il existe réellement des sites qui renvoient un 402 et affichent une page disant de payer, et je ne pense pas que tous ces sites vont se mettre à supporter ce mode de paiement blockchain
  • Le problème n’est pas que 402 ne soit pas utilisé, mais qu’il n’existe pas de réponse standardisée permettant à un agent IA de traiter le paiement d’accès. x402 fournit un format de réponse standard pour que le client puisse payer de façon programmatique. Cela peut inclure les stablecoins, et plus tard potentiellement aussi des moyens de paiement en monnaie fiduciaire
• Après 15 ans à travailler avec des banques et des prestataires de paiement, j’en suis sûr à 1000 % : une banque normale ne touchera jamais à ce genre de chose, même dans 20 ans
  • L’an dernier, on aurait peut-être dit la même chose de l’idée qu’un président ou une première dame lance sa propre memecoin
  • Des plateformes comme Coinbase ou Kraken l’utiliseront, et comme elles sont déjà connectées aux banques, les banques n’ont pas besoin d’intervenir directement
  • Des acteurs comme Anchorage prennent déjà en charge Base
  • En réalité, la participation des banques n’a pas beaucoup d’importance ; comme tout cela fonctionne sur la blockchain, on peut se passer des contraintes réglementaires des banques et de leurs mécanismes KYC/AML. Cela dit, vu le soutien de Coinbase, je ne suis pas certain qu’une fois mis sur la blockchain, ce soit réellement ouvert au monde entier