AWS y Anchor Browser han documentado una integración que permite a un agente de navegador pagar por una página o API protegida por x402 durante su sesión existente. El navegador puede responder a un desafío de pago HTTP 402, obtener una prueba de pago firmada de Amazon Bedrock AgentCore payments y reintentar la solicitud. Para el desarrollador, el cambio importante es dónde ocurre ese trabajo: el navegador gestiona el desafío y el reintento, mientras que un servicio de pago configurado por separado comprueba la autoridad para gastar.

El gran cambio

  • Qué cambió:Una solicitud web de pago puede completarse dentro de la sesión del navegador del agente después de un desafío x402, sin incluir una clave de cartera ni una cabecera de pago en el código de automatización. El desarrollador debe habilitar explícitamente los pagos para esa sesión.
  • Por qué importa:Los agentes que usan datos o contenido de pago por solicitud pueden continuar el mismo flujo de trabajo, mientras el instrumento de pago, los permisos de identidad y el límite de gasto quedan fuera de la página y del entorno de ejecución del agente. La decisión real de compra pasa así a una infraestructura que el operador debe configurar y supervisar.
  • Qué observar:El límite útil es la respuesta 402 original. Un desafío mal formado, una red de pago incompatible, un presupuesto agotado o un pago rechazado dejan el recurso inaccesible para la automatización; los desarrolladores aún deben gestionar esa respuesta.

Qué hace el navegador en una página de pago

El tutorial de AWS y Anchor describe el flujo para una navegación de documento, fetch o XMLHttpRequest dentro de una sesión de Anchor Browser. El comercio devuelve HTTP 402 Payment Required con un desafío de pago. Anchor lee las condiciones y busca un método compatible con el instrumento de pago vinculado a la sesión. AgentCore comprueba el presupuesto restante y usa el proveedor de cartera configurado para firmar una prueba. El navegador añade esa prueba a la solicitud original y la reintenta una vez, usando PAYMENT-SIGNATURE para x402 v2 o X-PAYMENT para v1. El comercio verifica y liquida el pago antes de devolver el recurso.

Esta es una secuencia documentada, no una prueba de BIG CHANGE con un punto de acceso de pago. AWS indica que el navegador conserva el contexto de sesión durante el pago y el reintento. Los flujos existentes de Playwright, Puppeteer y Chrome DevTools Protocol pueden seguir navegando o llamando a API a través del navegador sin construir por sí mismos cabeceras de pago. Un pago exitoso tampoco hace legible cualquier muro de pago: el sitio debe presentar un desafío x402 compatible y el comercio sigue decidiendo si acepta la prueba y entrega la respuesta.

Qué debe habilitar el desarrollador

El interruptor del navegador es explícito. En la solicitud de sesión del tutorial, session.x402 tiene el valor predeterminado false; establecerlo en true autoriza pagos reales desde el instrumento configurado. También se necesita una clave API de Anchor para crear la sesión del navegador. La opción es el último vínculo con la autoridad de pago, no un sustituto de configurarla.

La guía de pagos de AgentCore de AWS describe los recursos subyacentes. Payment Manager define la configuración de pago de la cuenta de AWS y utiliza un rol IAM y un autorizador. Payment Connector se conecta a Coinbase Developer Platform o Stripe Privy. Payment Credential Provider conserva las credenciales del proveedor mediante AgentCore Identity. Payment Instrument identifica la cartera y la red usadas en la compra. La sesión del navegador se vincula a un AgentCore Payment Session con límite de gasto y vencimiento. El inicio rápido de AWS también exige que el instrumento tenga fondos y que el usuario conceda al agente permiso delegado de firma antes de que pueda pagar.

Son controles distintos. IAM gobierna el acceso al servicio; la autorización de la cartera del usuario permite firmar; el instrumento determina la fuente de fondos y la red; y el límite de sesión restringe el gasto durante un periodo. AWS afirma que AgentCore deniega pagos posteriores cuando vence la sesión o se alcanza su límite. Su servicio de observabilidad expone en CloudWatch los intentos y resultados de pago. La integración mantiene los secretos del proveedor fuera del navegador y del entorno de ejecución del agente, pero el operador aún debe elegir el instrumento y el límite adecuados para el trabajo.

Dónde se detiene el flujo automatizado

El comportamiento de fallo documentado por Anchor es concreto: si el desafío 402 está mal formado, no se ofrece una red compatible, se agota el presupuesto o AgentCore rechaza el pago, el navegador devuelve el 402 original a la página sin cambios. Por tanto, la automatización debe considerar posible un 402 incluso en una sesión habilitada. La guía de resolución de problemas de AWS identifica otros fallos de configuración, como permisos IAM ausentes, una autorización delegada de firma inactiva, credenciales de proveedor inválidas y, para Coinbase, una suscripción a Marketplace que falta.

La opción session.x402 se aplica a pagos de recursos de terceros. AWS dice que no paga la sesión de Anchor Browser ni sustituye los créditos de Anchor. El tutorial menciona límites de gasto y tiempo de sesión, pero remite a la documentación técnica de Anchor para los límites concretos; esos detalles no estaban disponibles para este artículo. El cargo de cada solicitud de terceros depende del desafío del comercio y de la liquidación real. No verificamos una factura ni una transacción de extremo a extremo, por lo que el artículo no puede ofrecer un precio universal para una sesión habilitada.

Para los desarrolladores, la decisión práctica llega antes de que el agente alcance una URL de pago: conectar un instrumento con fondos y autorizado, fijar un presupuesto para la sesión del navegador y habilitar x402 solo cuando se pretendan compras. El navegador puede eliminar código del protocolo de pago de la ruta de navegación. No elimina la responsabilidad del operador sobre la autoridad de gasto, las solicitudes fallidas o la comprobación del importe que realmente cobró el comercio. Esa cuestión de autoridad también atraviesa nuestro análisis más amplio de las opciones de pago para agentes de IA.

Fuentes y lecturas adicionales

  • AWS y Anchor Browser, «Building agents that transact with Anchor Browser and AgentCore payments» (13 de octubre de 2026). El tutorial de integración documenta la activación voluntaria del navegador, el desafío x402, las cabeceras de pago específicas de cada versión y el comportamiento de devolver el 402 original ante fallos. Describe el flujo previsto; no probamos una sesión de pago.
  • AWS, «How AgentCore payments works» (guía para desarrolladores, consultada el 14 de octubre de 2026). Explica Payment Manager, conectores de proveedores, credenciales de identidad, instrumentos, sesiones de gasto y observabilidad. Es el diseño general del servicio, junto con el tutorial específico del navegador.
  • AWS, «AgentCore payments quick start» (guía para desarrolladores, consultada el 14 de octubre de 2026). Indica los pasos de configuración de credenciales, instrumento financiado y autorizado, y sesión de pago. Los presupuestos y duraciones de ejemplo son ilustrativos, no valores predeterminados verificados de Anchor.
  • AWS, «Troubleshooting AgentCore payments» (guía para desarrolladores, consultada el 14 de octubre de 2026). Enumera errores de IAM, proveedor, autorización de cartera, suscripción y carga x402 que pueden impedir el pago. No reprodujimos estos errores.