Qu'est-ce que le protocole x402 : paiements HTTP 402 ?

Le protocole X402 est une norme de paiement ouverte, native HTTP, qui utilise la réponse HTTP 402 "Paiement requis" ainsi que des en-têtes standardisés pour obliger un client à payer avant qu'un serveur ne renvoie une ressource. Il transforme un appel API normal en un flux déterministe de devis → paiement → vérification/règlement → reçu, avec des services tiers optionnels pour gérer la vérification et le règlement à travers les réseaux.

Points clés

• x402 utilise http 402 "Paiement requis" ainsi que des en-têtes standardisés afin qu'un serveur puisse exiger un paiement avant de servir une réponse APIou une ressource web.
• La poignée de main principale est 402 + PAYMENT-REQUIRED (devis) → réessayer avec PAYMENT-SIGNATURE (charge de paiement) → vérifier et régler → 200 + PAYMENT-RESPONSE (reçu).
• x402 reste agnostique au réseau en associant un schéma de paiement à une mise en œuvre réseau spécifique, et il peut externaliser la vérification et le règlement à un facilitateur.
• Solanacommercialise x402 avec des statistiques spécifiques à la chaîne, y compris ~400 ms de finalité, des coûts de transaction d'environ 0,00025 $, et plus de 35 millions de transactions x402 et plus de 10 millions de dollars de volume depuis son lancement sur Solana.

X402 en tant que norme de paiement HTTP

Le mouvement clé dans ce qu'est le protocole x402 est que le paiement devient un modèle de réponse HTTP de première classe, et non un système de facturation spécifique à une application ajouté ultérieurement. Un serveur de ressources peut répondre à une demande non payée avec http 402 et des exigences de paiement lisibles par machine, et le client peut répondre avec une charge utile de paiement signée dans les en-têtes.

C'est pourquoi "x402 expliqué" ressemble moins à une présentation de produit crypto et plus à un élément manquant de la plomberie web qui est comblé.

Cela est important pour l'économie des agents expliquée, car les agents ne veulent pas "s'inscrire" pour chaque point de terminaison qu'ils touchent. La monétisation traditionnelle des API impose des comptes,Clés API, factures, et une histoire d'authentification séparée.

x402 inverse la séquence : le serveur cite les conditions de paiement à l'intérieur du même flux HTTP, et le client prouve l'autorisation de paiement de la même manière qu'il prouve toute autre propriété de la requête, en envoyant un en-tête.

x402 est spécifié comme un standard ouvert pour les "paiements natifs d'internet", destiné à être agnostique par rapport au réseau, au token et à la monnaie. Le centre de gravité de la spécification est le dépôt de la x402 Foundation, qui est l'objectif de compatibilité que les développeurs doivent suivre.

Coinbase x402 existe également, mais son propre README le signale comme un fork de développement après que le projet ait été transféré sous la x402 Foundation, qui est la réalité de gouvernance pratique derrière "coinbase x402".

Comment une demande x402 est payée

Entre un client atteignant un point de terminaison et le serveur renvoyant un 200 OK, x402 force l'interaction dans une microstructure prévisible : devis, remplissage, compensation, reçu. Le protocole le fait avec des codes d'état et des en-têtes, et non avec une poignée de main SDK sur mesure.

Un flux typique, tel que documenté dans la spécification de la fondation x402, fonctionne comme suit :

1. Le client demande une ressource à un serveur de ressources via HTTP. 2. Le serveur de ressources renvoie une réponse 402 Payment Required avec un en-tête PAYMENT-REQUIRED contenant un objet PaymentRequired encodé en base64 qui liste les PaymentRequirements acceptables. 3. Le client sélectionne un PaymentRequirement et construit un PaymentPayload qui correspond à la paire (schéma, réseau) choisie. 4.

Le client réessaie la demande avec un en-tête PAYMENT-SIGNATURE portant le PaymentPayload. 5. Le serveur de ressources vérifie le payload soit localement, soit en POSTant le payload et les requirements à un point de terminaison facilitateur /verify. 6. Si la vérification est valide, le serveur de ressources exécute la demande, puis se règle soit directement onchain, soit en POSTant à un point de terminaison facilitateur /settle. 7.

Si le règlement réussit, le serveur de ressources renvoie 200 OK avec la ressource dans le corps et un en-tête PAYMENT-RESPONSE contenant une réponse de règlement encodée en base64.

Deux détails déterminent la plupart des résultats d'intégration. Tout d'abord, les étapes 1 et 2 sont optionnelles si le client connaît déjà les détails de paiement pour cette ressource, ce qui permet aux équipes d'éviter un aller-retour supplémentaire à grande échelle.

Deuxièmement, la spécification permet explicitement de faire un compromis entre la rapidité de réponse et la garantie de paiement, c'est pourquoi "http 402 payment" n'est pas automatiquement synonyme de "règlement final instantané".

Réseaux, schémas et facilitateurs

La revendication agnostique de la chaîne de x402 vit ou meurt sur une contrainte : les clients et les facilitateurs doivent prendre en charge des paires explicites (schéma, réseau). Un schéma est une manière logique de déplacer de l'argent, mais l'implémentation de ce schéma diffère selon le réseau. "Exact surEthereum« et « exact sur Solana » ne sont pas le même problème d'ingénierie, même si la surface HTTP semble identique.

Le dépôt de la Fondation x402 décrit des schémas incluant le règlement exact, le règlement jusqu'à un plafond et le règlement par lots (EVM). Les distinctions sont des choix de style d'exécution. exact est un transfert fixe pour une demande. jusqu'à est une autorisation jusqu'à un plafond, le vendeur réglant l'utilisation réelle jusqu'à ce maximum.

le règlement par lots (EVM) utilise des dépôts et des bons hors chaîne afin que de nombreuses petites charges puissent être échangées sur la chaîne par lots au lieu de régler chaque demande HTTP individuellement.

Le rôle de facilitateur est l'autre grand levier de conception. Un facilitateur est un serveur qui facilite la vérification et l'exécution des paiements pour un ou plusieurs réseaux. Concrètement, il donne au serveur de ressources une interface /verify et /settle afin que le serveur n'ait pas besoin de mettre en œuvre lui-même chaque intégration de chaîne.

Cette commodité s'accompagne d'une nouvelle dépendance : le facilitateur devient partie intégrante de la fiabilité et de la frontière de confiance, même si l'objectif déclaré de la norme est de minimiser la confiance et de ne pas laisser les facilitateurs déplacer des fonds en dehors de l'intention du client.

C'est ici que les évaluations du "protocole crypto x402" se trompent souvent. La bonne question n'est pas "est-ce que x402 est rapide ou bon marché", car x402 est une couche de négociation et de preuve. La latence, le profil des frais et les garanties de règlement proviennent de la paire (schéma, réseau) et de la manière dont la vérification et le règlement sont gérés localement ou externalisés à un facilitateur.

Pourquoi x402 est important pour les agents d'IA

agents IAchanger la forme de la demande car elles génèrent de nombreuses petites demandes fréquentes qui sont difficiles à monétiser avec des abonnements et compliquées à restreindre avec l'intégration des comptes. x402 est conçu pour rendre le paiement agentique semblable à un HTTP normal : l'agent appelle un point de terminaison, obtient un devis 402, et peut décider de payer en fonction de ses propres règles.

La page x402 de Solana présente cela comme des "paiements natifs d'internet" pour des outils autonomes, et elle s'appuie surstablecoinle règlement comme le rail économique qui rend le prix à la demande sensé.

Cette page affirme que les paiements en stablecoin sur Solana dépassent 11 milliards de dollars en circulation et représentent plus de 200 millions de transactions par mois, positionnant le réseau comme une couche de règlement à haut débit pour les services de paiement à la demande.

Le mécanisme s'intègre parfaitement aux flux de travail des agents car il supprime le besoin d'une identité et d'un canal de facturation séparés. Un client capable de parler HTTP peut apprendre à payer en lisant des en-têtes standardisés, plutôt qu'en intégrant un SDK de facturation différent pour chaque API.

C'est la fonctionnalité décisive pour le paiement machine à machine : la négociation de paiement est lisible par des clients génériques, et pas seulement par des humains cliquant sur une page de paiement.

Le compromis est que « le paiement est une authentification » ne fonctionne aussi bien que les choix de schéma et de facilitateur le permettent. Si un agent effectue des milliers d'appels, la différence entre « réglé exactement à chaque fois » et « règlement par lot échangé plus tard » est la différence entre une boucle serrée et un système qui passe son temps à attendre des confirmations.

Signaux d'adoption et compromis pratiques

Le point de données de traction le plus clair dans les sources fournies est spécifique à la chaîne : la page x402 de Solana affirme que depuis le lancement de x402 sur Solana « cet été », elle a traité plus de 35 millions de transactions et plus de 10 millions de dollars de volume sur x402. La même page affirme que Solana a une finalité d'environ 400 ms et des coûts de transaction d'environ 0,00025 $.

Ces informations sont utiles en tant que signaux d'adoption et de performance pour ce déploiement, mais elles ne prouvent pas que chaque intégration x402 hérite de ces chiffres.

La spécification elle-même propose un cadre plus sobre : x402 est flexible, et les implémentations peuvent échanger la vitesse de réponse contre des garanties de paiement. C'est pourquoi des affirmations générales comme « se règle en ~2 secondes » provenant d'explications de l'écosystème doivent être interprétées comme dépendantes du réseau et de la conception, et non comme une propriété de la poignée de main HTTP.

Les développeurs doivent également distinguer le "marketing standard" du "marketing écosystémique". La page de Solana affirme que des plateformes majeures comme Cloudflare, Google et Vercel soutiennent x402, mais les sources fournies ne définissent pas ce que signifie "soutien" au niveau du produit. Sans une surface d'intégration concrète, cette affirmation n'est pas exploitable.

La posture pratique est de commencer étroit et de mesurer. Une paire (schéma, réseau) en production offre un chemin heureux unique à instrumenter de bout en bout. À partir de là, les équipes peuvent ajouter d'autres schémas ou réseaux, et décider de garder la vérification et le règlement locaux ou de s'appuyer sur un facilitateur.

C'est la différence entre une démo qui fonctionne et une couche de paiement qui survit aux nouvelles tentatives, aux délais d'attente et aux échecs partiels dans l'économie des agents.

La Prise

J'ai vu des équipes traiter x402 comme "un mur de paiement crypto" et ensuite être surprises par la partie qui détermine réellement l'expérience utilisateur : la paire (schéma, réseau) et où se trouvent la vérification et le règlement. La poignée de main HTTP est déterministe. La couche de compensation ne l'est pas.

Si le /verify d'un facilitateur est rapide mais que le /settle est bloqué, le client le voit comme une API qui se fige aléatoirement, même si les en-têtes sont parfaitement standardisés.

Le modèle mental qui reste est la microstructure. 402 + PAYMENT-REQUIRED est le devis, PAYMENT-SIGNATURE est la commande, vérifier et régler est la compensation, et 200 + PAYMENT-RESPONSE est le reçu.

Une fois que cela fait clic, l'évaluation cesse d'être "est-ce que x402 est bon marché" et devient "quel style d'exécution ce point de terminaison a-t-il choisi, et quelles dépendances a-t-il introduites," ce qui est exactement le bon prisme pour l'économie des agents expliquée.

Sources

• Fondation Solana
• Fondation x402 (GitHub)
• Coinbase (GitHub)
• thirdweb