AWS et Anchor Browser ont documenté une intégration qui permet à un agent de navigateur de payer une page ou une API protégée par x402 pendant sa session existante. Le navigateur peut répondre à un défi de paiement HTTP 402, obtenir une preuve de paiement signée par Amazon Bedrock AgentCore payments, puis réessayer la requête. Pour les développeurs, le changement déterminant concerne le lieu où ce travail s’effectue : le navigateur gère le défi et la nouvelle tentative, tandis qu’un service de paiement configuré séparément vérifie l’autorisation de dépenser.

Le grand changement

  • Ce qui change :Après un défi x402, une requête Web payante peut aboutir dans la session de navigateur de l’agent, sans clé de portefeuille ni en-tête de paiement dans le code d’automatisation. Le développeur doit explicitement activer les paiements pour cette session.
  • Pourquoi c’est important :Les agents qui utilisent des données ou des contenus facturés à la requête peuvent poursuivre le même flux de travail, tandis que le moyen de paiement, les autorisations d’identité et le plafond de dépenses restent en dehors de la page et de l’environnement d’exécution de l’agent. La décision d’achat réelle passe ainsi dans une infrastructure que l’opérateur doit configurer et surveiller.
  • À surveiller :La limite utile est la réponse 402 initiale. Un défi mal formé, un réseau de paiement incompatible, un budget épuisé ou un paiement refusé laisse la ressource inaccessible à l’automatisation ; les développeurs doivent toujours traiter cette réponse.

Ce que fait le navigateur sur une page payante

Le tutoriel d’AWS et d’Anchor décrit le flux pour une navigation de document, fetch ou XMLHttpRequest dans une session Anchor Browser. Le marchand renvoie HTTP 402 Payment Required avec un défi de paiement. Anchor lit les conditions et cherche une méthode compatible avec le moyen de paiement lié à la session. AgentCore vérifie le budget restant et utilise le fournisseur de portefeuille configuré pour signer une preuve. Le navigateur ajoute cette preuve à la requête initiale et la réessaie une fois, avec PAYMENT-SIGNATURE pour x402 v2 ou X-PAYMENT pour v1. Le marchand vérifie et règle le paiement avant de renvoyer la ressource.

Il s’agit d’une séquence documentée, et non d’un test de point d’accès payant réalisé par BIG CHANGE. AWS indique que le navigateur conserve le contexte de session pendant le paiement et la nouvelle tentative. Les flux de travail Playwright, Puppeteer et Chrome DevTools Protocol existants peuvent continuer à naviguer ou à appeler des API via le navigateur sans construire eux-mêmes les en-têtes de paiement. Un paiement réussi ne rend pas tous les paywalls accessibles : le site doit présenter un défi x402 pris en charge, et le marchand décide toujours s’il accepte la preuve et fournit sa réponse.

Ce que le développeur doit activer

Le commutateur du navigateur est explicite. Dans la requête de session du tutoriel, session.x402 vaut false par défaut ; le définir sur true autorise les paiements réels depuis le moyen configuré. Une clé API Anchor est également nécessaire pour créer la session du navigateur. Le paramètre constitue le dernier lien vers l’autorité de paiement, et non un substitut à sa configuration.

Le guide AWS sur AgentCore payments décrit les ressources sous-jacentes. Payment Manager définit la configuration de paiement du compte AWS et utilise un rôle IAM et un autoriseur. Payment Connector se connecte à Coinbase Developer Platform ou à Stripe Privy. Payment Credential Provider conserve les identifiants du fournisseur via AgentCore Identity. Payment Instrument désigne le portefeuille et le réseau utilisés pour l’achat. La session du navigateur est liée à un AgentCore Payment Session doté d’un plafond de dépenses et d’une expiration. Le guide de démarrage rapide d’AWS exige aussi que le moyen de paiement soit approvisionné et que l’utilisateur accorde à l’agent une autorisation déléguée de signature avant qu’il puisse payer.

Ces contrôles sont distincts. IAM régit l’accès au service ; l’autorisation de portefeuille de l’utilisateur permet la signature ; le moyen de paiement détermine la source des fonds et le réseau ; le plafond de session limite les dépenses dans le temps. AWS indique qu’AgentCore refuse tout paiement supplémentaire lorsque la session expire ou atteint son plafond. Son service d’observabilité expose les tentatives et résultats de paiement dans CloudWatch. L’intégration garde les secrets du fournisseur hors du navigateur et de l’environnement d’exécution de l’agent, mais l’opérateur doit toujours choisir le moyen de paiement et le plafond adaptés à la tâche.

Où le flux automatisé s’arrête

Le comportement d’échec documenté par Anchor est précis : si le défi 402 est mal formé, si aucun réseau compatible n’est proposé, si le budget est épuisé ou si AgentCore refuse le paiement, le navigateur renvoie à la page la réponse 402 initiale sans la modifier. L’automatisation doit donc prévoir un 402 même lorsque la session est activée. Le guide de dépannage d’AWS recense d’autres erreurs de configuration, notamment une autorisation IAM manquante, une délégation de signature inactive, des identifiants de fournisseur invalides et, pour Coinbase, l’absence d’abonnement Marketplace.

Le commutateur session.x402 s’applique aux paiements de ressources tierces. AWS indique qu’il ne règle pas la session Anchor Browser et ne remplace pas les crédits Anchor. Le tutoriel évoque des limites de dépenses et de durée de session, mais renvoie à la documentation technique d’Anchor pour les limites précises ; ces détails n’étaient pas disponibles pour cet article. Le coût d’une requête tierce dépend du défi du marchand et du règlement effectif. Nous n’avons vérifié ni facture ni transaction de bout en bout ; l’article ne peut donc pas donner de prix universel pour une session activée.

Pour les développeurs, la décision pratique intervient avant que l’agent n’atteigne une URL payante : connecter un moyen de paiement approvisionné et autorisé, définir un budget de session pour le navigateur, puis n’activer x402 que si un achat est prévu. Le navigateur peut retirer le code du protocole de paiement du parcours de navigation. Il ne décharge pas l’opérateur de sa responsabilité concernant l’autorité de dépense, les requêtes échouées ou la vérification du montant réellement facturé par le marchand. Cette question d’autorité traverse aussi notre analyse plus large des choix de paiement des agents IA.

Sources et lectures complémentaires

  • AWS et Anchor Browser, « Building agents that transact with Anchor Browser and AgentCore payments » (13 octobre 2026). Le tutoriel d’intégration décrit l’activation volontaire du navigateur, le défi x402, les en-têtes de paiement propres à chaque version et le renvoi de la réponse 402 initiale en cas d’échec. Il présente le flux prévu ; nous n’avons pas testé de session payante.
  • AWS, « How AgentCore payments works » (guide développeur, consulté le 14 octobre 2026). Explique Payment Manager, les connecteurs de fournisseurs, les identifiants d’identité, les moyens de paiement, les sessions de dépenses et l’observabilité. Il s’agit de la conception générale du service, en complément du tutoriel consacré au navigateur.
  • AWS, « AgentCore payments quick start » (guide développeur, consulté le 14 octobre 2026). Présente la configuration des identifiants fournisseur, d’un moyen de paiement approvisionné et autorisé, ainsi que d’une session de paiement. Les budgets et durées d’exemple sont illustratifs, et non des valeurs Anchor par défaut vérifiées.
  • AWS, « Troubleshooting AgentCore payments » (guide développeur, consulté le 14 octobre 2026). Répertorie des erreurs IAM, fournisseur, autorisation de portefeuille, abonnement et charge utile x402 susceptibles d’empêcher un paiement. Nous n’avons pas reproduit ces erreurs.