AI-translated from English; not yet reviewed by a fluent editor. # Pagos de Anchor Browser y AgentCore: cómo un agente atraviesa un muro de pago x402 > Anchor Browser puede reintentar una página o llamada a una API con pago x402 mediante AgentCore payments cuando el desarrollador habilita la sesión y configura un instrumento de pago autorizado y con presupuesto. By BIG CHANGE Editorial Published: 2026-10-14T05:55:23.177Z Updated: 2026-10-14T05:55:23.177Z Canonical: https://bigchange.ai/blog/anchor-browser-agentcore-x402-payments ![A payment card and blank purchase order sit on a track beside an adjustable mechanical stop with an orange knob.](https://bigchange.ai/api/media/file/payment-authority-hero-v1.png) AI-generated conceptual illustration by BIG CHANGE. Delegating a purchase still requires a boundary around payment authority. The intact card, order and adjustable stop are a conceptual illustration, not a depiction of a specific product. AWS y Anchor Browser han [documentado una integración](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) 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](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) 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](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/), `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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) 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](https://bigchange.ai/blog/ai-agent-payments-stablecoins-bank-deposits). ## Fuentes y lecturas adicionales - [AWS y Anchor Browser, «Building agents that transact with Anchor Browser and AgentCore payments»](https://aws.amazon.com/blogs/machine-learning/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»](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) (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»](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) (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»](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) (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. ## Sources - [AWS Machine Learning Blog, Building agents that transact with Anchor Browser and AgentCore payments](https://aws.amazon.com/blogs/machine-learning/building-agents-that-transact-with-anchor-browser-and-agentcore-payments/) — Tutorial principal de integración. Documenta session.x402 como valor predeterminado y la habilitación de pagos reales, la secuencia del navegador y AgentCore, un único reintento y la devolución sin cambios del 402 original en los fallos enumerados. Es comportamiento descrito por el proveedor; BIG CHANGE no realizó una sesión de pago. Su afirmación separada sobre créditos y facturación consolidados de Anchor no se contrastó de forma independiente con la documentación de financiación de cartera de AgentCore y no se repite como modelo de cobro universal. - [AWS, How AgentCore payments works](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-how-it-works.html) — Referencia mantenida sobre arquitectura y controles del servicio. Define Payment Manager, conector, proveedor de credenciales de identidad, instrumento, límites y vencimiento de sesión, autorización de cartera del usuario, flujo de pago y observabilidad. El flujo x402 genérico usa X-PAYMENT; el tutorial específico de Anchor distingue la cabecera PAYMENT-SIGNATURE de x402 v2. - [AWS, AgentCore payments quick start](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-getting-started.html) — Pasos y requisitos previos de configuración, incluida la conexión con Coinbase o Stripe Privy, instrumento financiado, permiso delegado de firma y sesión de pago limitada en el tiempo. Las cantidades y duraciones de ejemplo no son valores predeterminados ni límites de Anchor. - [AWS, Troubleshooting AgentCore payments](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/payments-troubleshooting.html) — Documenta errores de permisos, suscripción, autorización de cartera, credenciales y carga x402. Los errores del servicio complementan el comportamiento de devolución del 402 original descrito en el tutorial de Anchor Browser; aquí no se probó ninguna ruta de fallo.