Comment payer des API avec x402 via MetaMask Agent Wallet : 8 conseils

Lorsqu'une API, un flux de données ou un outil MCP répond à votre agent par 402 Payment Required, MetaMask Agent Wallet peut payer en USDC, sans inscription ni clé API. L'agent lit l'offre du serveur, vous présente l'actif, le montant, le réseau et le destinataire, puis signe une autorisation de paiement unique une fois que vous avez donné votre accord. La clé privée reste dans le wallet. La demande de signature passe également par l'analyse des menaces du service du wallet.

Avertissement : ce guide est fourni à titre informatif uniquement. Il ne constitue ni un conseil financier ni une sollicitation, et n'est pas destiné au public britannique. Les paiements en crypto effectués par des agents IA comportent des risques et ne conviennent pas à tous les utilisateurs.

Ce guide opérationnel explique comment payer avec x402 via Agent Wallet. Pour savoir ce qu'est x402, comment fonctionne le handshake 402 et qui gouverne le protocole, consultez ce qu'est x402. Les développeurs qui souhaitent intégrer des paiements x402 basés sur la délégation dans leurs propres applications devraient plutôt commencer par les guides x402 du Smart Accounts Kit. Si Agent Wallet n'est pas encore configuré, commencez par le guide de démarrage rapide.

Pourquoi les agents paient à chaque appel plutôt que de détenir des clés API

Une API payante implique généralement un compte et une clé API de longue durée. Pour un agent IA, cette clé doit être stockée à un endroit où il peut la lire, ce qui en fait une cible. Dans une étude publiée le 5 février 2026, Snyk a analysé 3 984 skills sur la marketplace ClawHub et en a trouvé 283 (environ 7,1 %) qui faisaient transiter des clés API, des mots de passe ou des numéros de carte par la fenêtre de contexte du modèle ou par des fichiers mémoire en clair, d'où une injection de prompt peut les extraire.

x402 supprime le secret permanent. L'agent paie chaque requête avec une autorisation signée pour un montant exact, à un destinataire précis, valable pendant une courte durée. Avec Agent Wallet, cette signature provient du service du wallet via mm wallet sign-typed-data : l'agent ne manipule donc jamais de clé privée ni de clé API. Chaque autorisation comporte un nonce aléatoire, ce qui l'empêche d'être réglée deux fois. Un article à venir examinera plus largement ce que x402 change pour le commerce entre agents, y compris pour les agents qui vendent des services à d'autres agents.

Le fonctionnement de x402, en détail

La prise en charge de x402 est fournie sous forme de script d'aide Python dans le skill metamask-agent-wallet, et non comme sous-commande mm. Votre agent l'appelle lorsqu'une requête renvoie un 402. En général, il vous suffit de demander en langage courant (« Récupère les données premium à cette URL et paie si elle renvoie un 402 »), et l'agent exécute ces étapes à votre place.

Vous trouverez la documentation complète dans le guide des paiements x402 et dans la référence x402 du skill.

Maintenant que vous connaissez le fonctionnement, voici 9 conseils pour effectuer des paiements x402 via Agent Wallet.

1. Approvisionnez-vous en USDC sur le réseau demandé par le service

Le serveur décide des actifs et des réseaux qu'il accepte. L'agent ne peut payer que via une option proposée par le serveur.

Agent Wallet ne paie que les offres EVM, sur les réseaux inclus dans mm chains list. Les soldes sont propres à chaque chaîne : des USDC sur Ethereum ne couvriront donc pas une offre sur Base. Si vous détenez des USDC sur une autre chaîne, vous pouvez aussi demander à l'agent de transférer les fonds vers la chaîne requise. Le paiement lui-même est une autorisation offchain, sans frais de gas. Le facilitator du service la règle onchain : votre wallet n'a donc pas besoin de tokens natifs pour couvrir les frais de réseau du paiement.

2. Inspectez l'offre avant de payer

inspect lit le 402 sans signer ni dépenser. Elle renvoie l'actif, un montant lisible, le réseau, le destinataire payTo et la ressource. Le skill demande à l'agent de vous présenter ces informations et d'attendre votre accord avant d'exécuter pay, et pay refuse de s'exécuter sans --confirm.

Plusieurs vérifications sont effectuées avant toute signature. L'URL de la ressource doit commencer par https://. Le script ne suit pas les redirections : une redirection vers un autre hôte ne peut donc pas détourner un paiement vers un serveur que vous n'avez pas choisi. Le montant doit être un nombre entier positif de la plus petite unité du token, et le destinataire comme l'actif doivent être des adresses valides. Pour le schéma exact, le montant signé est égal au montant proposé. Ce n'est pas un plafond jusqu'auquel le serveur pourrait facturer.

3. Définissez par défaut une confirmation pour chaque paiement

Le skill Agent Wallet peut demander à l'agent de confirmer avec vous, par défaut, l'actif, le montant, le réseau, le destinataire et la ressource avant chaque paiement x402. La confirmation a lieu dans votre conversation avec l'agent. Elle est distincte de la 2FA, que le service de wallet déclenche uniquement lorsqu'une requête est signalée ou sort du cadre de votre politique.

Cela convient à un agent qui achète un rapport de recherche, quelques extractions de données ou une carte cadeau au cours d'une session. En revanche, ce n'est pas adapté à une boucle qui appelle un endpoint payant toutes les quelques secondes, car chaque appel attend votre validation. Un achat en plusieurs étapes qui facture à plusieurs reprises vous sollicite à chaque étape.

4. Savoir ce que Guard Mode vérifie lors d'un paiement x402

En mode server-wallet, chaque demande de signature est envoyée au service de wallet, qui effectue une analyse des menaces avant de signer. Une requête signalée reste en pause dans l'état AWAITING_MFA jusqu'à ce que vous l'approuviez. Les autorisations x402 ont une courte fenêtre de validité définie par le serveur. Si Guard Mode met la signature en pause pour une 2FA et que vous approuvez après la fermeture de cette fenêtre, l'autorisation expire sans avoir été utilisée. Demandez à l'agent de relancer pay, qui récupère un nouveau 402 et signe de nouvelles valeurs. Les approbations arrivent là où votre méthode de connexion les envoie : un lien par e-mail pour la connexion Google ou e-mail, ou le menu des notifications dans MetaMask Mobile pour la connexion par QR code.

La limite glissante de sorties sur 24 heures fonctionne différemment ici. La politique de sorties prend en compte les transferts de tokens, les swaps et les dépôts, et, au 27 octobre 2026, elle précise que les signatures, comme Permit2, ne sont pas incluses dans le calcul des sorties. Une autorisation x402 est une signature : la limite de 24 heures n'est donc pas un plafond fiable pour les dépenses x402. L'étape de confirmation repose sur le respect du skill par l'agent, et le plafond absolu est le solde de tokens du wallet qui paie. Pour limiter l'exposition, vous pouvez utiliser un wallet distinct, approvisionné uniquement pour les appels d'API payants. mm wallet create et mm wallet select permettent de gérer plusieurs wallets.

5. Choisir une option lorsque le serveur en propose plusieurs

Lorsqu'un 402 liste le même schéma sur plusieurs réseaux ou actifs pris en charge, le script s'arrête avec une erreur « multiple eligible options » au lieu de choisir à votre place. Un service qui accepte l'USDC à la fois sur Base et sur Monad peut la déclencher. Relancez avec --network (par exemple, eip155:8453 pour Base) ou avec --asset et le contrat du token. Indiquez à l'agent le réseau que vous avez approvisionné, et il pourra passer l'option dès le premier essai.

6. Vérifier que l'offre est bien signable par Agent Wallet

Le helper signe le schéma exact avec EIP-3009 transferWithAuthorization sur les réseaux EVM, pour les versions v1 et v2 du protocole x402. Il renvoie une erreur explicite et ne signe rien lorsqu'il détecte :

Si un service propose à la fois Permit2 et EIP-3009 pour le même actif, c'est l'option EIP-3009 qui est utilisée. La page de dépannage liste chaque erreur.

7. Ne relancez pas un paiement à l'aveugle

Le script ne conserve aucun historique des paiements passés. Le nonce EIP-3009 empêche la même autorisation signée d'être réglée deux fois, mais chaque nouvelle exécution de pay crée un nouveau paiement. Si pay renvoie « payment not accepted », vérifiez le résultat du règlement et si la fenêtre d'autorisation a expiré avant de réessayer. Une seconde exécution pour la même ressource entraîne un second débit, et le guide x402 recommande aux appelants de se prémunir contre les appels répétés.

8. Payer aussi pour des outils MCP et des endpoints POST

x402 ne se limite pas aux requêtes GET. Si vous passez --method et --data, le helper rejoue le même corps de requête avec le paiement joint : un POST payant (un endpoint de complétion de chat IA, par exemple) fonctionne ainsi comme un téléchargement payant.

Les outils MCP payants utilisent le transport MCP de x402 v2. Un appel d'outil non payé renvoie un résultat d'erreur contenant le challenge de paiement. L'agent exécute mcp-inspect, vous présente l'offre, exécute mcp-sign --confirm après votre approbation, puis relance l'appel d'outil avec la charge utile signée dans _meta["x402/payment"]. Le script signe, mais ne parle pas MCP : c'est donc la propre session MCP de l'agent qui envoie la nouvelle tentative. Si cette nouvelle tentative renvoie un autre challenge, le paiement n'a pas été réglé, et l'agent vous le signale au lieu de signer à nouveau.

Ce que les agents achètent via x402

Un premier usage est l'achat de données : un agent de trading peut récupérer des signaux ou des recherches dev avant d'agir, puis passer la main aux swaps ou aux perps pour l'exécution. Voici quelques services qui acceptent x402, avec des détails issus de leur propre documentation au 27 octobre 2026 :

Chaque service définit son propre format d'offre : demandez donc à l'agent d'exécuter d'abord inspect pour vérifier que l'offre peut être signée par Agent Wallet (conseil 6). Par exemple, les endpoints x402 de Nansen acceptent les requêtes POST et uniquement x402 v2. Exemple de requête : « Récupère les flux nets Smart Money de Nansen pour Ethereum. S'il renvoie une erreur 402, montre-moi le coût et paie une fois que j'aurai confirmé. » Pour découvrir d'autres services x402, x402scan est un explorateur de l'écosystème x402.

Ce qu'Agent Wallet ne fait pas pour x402

• Plafonner les dépenses x402 avec la limite de sorties. Pour l'instant, la politique de sorties exclut les signatures du calcul sur 24 heures.

• Signer toutes les offres x402. Les offres Permit2 uniquement, upto et non EVM sont rejetées.

• Dédoublonner les paiements. Il n'existe pas encore de registre des paiements. Relancer pay déclenche un nouveau paiement.

• Vendre via x402. L'assistant ne fonctionne que côté acheteur. Héberger un endpoint payant pour d'autres agents nécessite une configuration distincte.

• S'exécuter comme une commande mm. C'est un script Python 3 inclus dans le skill. Il affiche toujours du JSON, donc --toon et --format ne s'appliquent pas.