Cómo los agentes de IA pagan eSIMs con x402 y stablecoins: el flujo de conectividad machine-payable

Dale a un agente de IA un navegador, una shell y un juego de claves API y podrá planificar, programar y llamar herramientas todo el día. Pero la primera vez que una tarea le exige pagar por algo — un crédito de inferencia, un dataset, un proxy, una SIM — se atasca. Los rieles de pago humanos asumen un humano: una página de checkout, un número de tarjeta, un desafío 3-D Secure, un login. Los agentes no tienen nada de eso. La brecha entre «agente que puede actuar» y «agente que puede transaccionar» es hoy el mayor cuello de botella del comercio agéntico.

x402 es el estándar emergente construido para cerrar esa brecha, y lo hace reviviendo una de las piezas más antiguas y menos usadas de la web: el código de estado HTTP 402 Payment Required. Esta guía explica qué es realmente x402, por qué la conectividad es la primera compra canónica de un agente autónomo, y cómo el flujo actual de stablecoins + MCP de Roamzy se mapea limpiamente sobre la forma de x402 hoy — sin fingir que habla x402 de forma nativa.

Qué es x402 en realidad

HTTP 402 quedó reservado en la especificación original como «Payment Required» y pasó más de tres décadas sin usarse, porque nunca existió una forma nativa de internet de liquidar un pago dentro de una petición. x402 — impulsado por Coinbase (con Cloudflare y una fundación creciente) y operando a escala desde 2025 — por fin conecta ese código con dinero real, liquidando pagos en stablecoins directamente sobre HTTP.

La mecánica es un bucle de petición/respuesta entre tres partes: el cliente (tu agente), el servidor de recursos (lo que se vende) y un facilitador (un servicio que verifica y liquida el pago on-chain para que el servidor no tenga que operar su propia infraestructura de blockchain). El flujo:

1. El agente hace una petición HTTP normal a un recurso con precio.
2. El servidor responde 402 Payment Required con una cabecera PAYMENT-REQUIRED que lleva los requisitos de pago estructurados: precio, token aceptado, dirección del destinatario y red.
3. El agente construye un payload de pago firmado — típicamente una autorización sin gas vía EIP-3009 para USDC, o Permit2 para otros tokens ERC-20 — y reintenta la misma petición con la prueba en una cabecera X-PAYMENT.
4. El facilitador verifica y liquida; el servidor devuelve los datos más una cabecera X-PAYMENT-RESPONSE que confirma la transacción.

El ciclo completo toma segundos, no necesita login y se liquida on-chain. x402 es agnóstico de blockchain (cadenas EVM más Solana y otras), no cobra comisiones de protocolo, y para principios de 2026 ya había procesado bastante más de 100 millones de transacciones solo en Base, con decenas de miles de agentes transaccionando activamente. Ya no es un experimento mental.

Por qué la conectividad es el primer pago canónico

De todo lo que un agente podría comprar, ¿por qué destacar una eSIM? Porque la conectividad está aguas arriba de cualquier otra compra. Mira la cadena de dependencias:

• Para pagar inferencia, un dataset o un proxy, el agente necesita una ruta de red que llegue hasta ese recurso.
• Un agente alojado en la nube hereda la red de su host — pero un agente de edge, robótica, drones, IoT o de campo se define por tener que conseguir su propia conectividad antes de poder hacer cualquier otra cosa.
• La conectividad es por naturaleza medida y de denominación pequeña — bytes, no suscripciones — que es justo la forma para la que se diseñaron los micropagos de x402.

Así que el momento machine-payable canónico se ve así: el agente necesita datos → topa con un recurso de conectividad con precio → liquida un micropago en stablecoin → obtiene conectividad → sigue con su tarea real. Un agente que puede pagar su propio ancho de banda es un agente que puede arrancar por sí solo en cualquier punto del planeta sin que un humano le inserte una SIM. Esa es toda la promesa, y por eso pensamos en la mejor eSIM para agentes de IA primero como un problema de pagos y después como un problema de telecomunicaciones.

Las dos mitades: presupuesto de datos y pago

Un agente que paga tiene que razonar sobre dos cosas a la vez. La primera es cuántos datos necesita y qué costarán — un problema de planificación que cubre nuestra guía de consumo de datos para agentes. La segunda es cómo liquida ese costo — el problema de pago del que trata este artículo. x402 es la mitad de liquidación; un producto de conectividad medido por MB es la mitad de presupuesto. Solo funcionan juntas: un agente que sabe que necesita 500 MB pero no puede pagar, o que puede pagar pero está obligado a un paquete fijo de 5 GB, está roto en una dirección o en la otra.

Mapeando x402 sobre Roamzy hoy

Honestidad primero: Roamzy no expone hoy un endpoint nativo HTTP-402 / x402. No devuelve respuestas 402 en vivo y no habla de forma nativa el handshake de cabeceras de x402. Lo que sí hace es liquidar en stablecoins a través del procesador cripto NowPayments y exponer el flujo de compra mediante un servidor MCP y una API REST. Ese flujo es la misma primitiva que x402 — un recurso de conectividad con precio, liquidado con un pago en stablecoin y sin checkout humano — lo que hace a Roamzy x402-ready en dirección, aunque no en el formato que viaja por el cable. Este es el mapeo de concepto a primitiva:

Leídas de izquierda a derecha, las formas coinciden casi una a una. La diferencia es puramente el canal de liquidación: x402 liquida el pago dentro del round-trip HTTP; Roamzy lo liquida junto a la llamada MCP/REST mediante el procesador y confirma de forma asíncrona por el webhook IPN. La primitiva económica — el agente paga en stablecoin, obtiene conectividad medida, sin login, sin KYC — es idéntica.

Qué llama un agente en la práctica

Una secuencia concreta para una compra en Roamzy hoy:

1. roamzy_status — comprueba purchases_paused y espera si está activado.
2. roamzy_estimate — convierte un presupuesto de datos en un costo esperado en USDT (solo para planificar; el agente no pre-compra volúmenes).
3. roamzy_payment_options — lee la lista habilitada de stablecoin+red (el análogo de parsear una cabecera PAYMENT-REQUIRED) y elige una cadena, p. ej. USDC en Solana por sus comisiones casi nulas.
4. roamzy_create_order con pay_currency fijado explícitamente → liquida el pago en stablecoin (recarga mínima de $20).
5. roamzy_order_status — consulta hasta que el IPN confirme y el saldo quede acreditado.

Como el saldo está medido por MB y nunca caduca, una sola recarga financia muchas tareas posteriores — el agente recarga una vez y va descontando mientras trabaja, que es el patrón pay-as-you-go sin suscripción que fomentan los micropagos de x402. Las formas completas de petición/respuesta están en la documentación de la API y en la guía MCP para desarrolladores.

Los modos de fallo que conviene prever

Quien construya hacia pagos de máquina debe conocer los bordes afilados. En el lado x402, la patología clásica es el bucle de reintentos: el agente recibe un 402, firma, reenvía, recibe otro 402 y nunca converge — normalmente por desfase de reloj en la ventana de validez firmada, por un chain-ID que no coincide (firmar contra la cadena X mientras el facilitador verifica en la cadena Y) o por caídas intermitentes del facilitador. En Roamzy hoy el análogo es más sutil porque la liquidación es asíncrona: las trampas son elegir un pay_currency cuya red la wallet del agente en realidad no puede usar para enviar, mandar menos del mínimo de $20, o tratar la respuesta de create-order como definitiva en vez de consultar roamzy_order_status hasta la confirmación del IPN. En ambos mundos la disciplina es la misma — fija la red explícitamente, respeta el mínimo y confirma antes de continuar.

Hacia dónde va esto

x402 convierte la conectividad en algo que un agente puede comprar igual que compra una llamada a una API — con precio, firmado, liquidado, listo. Roamzy está construido hoy sobre la misma primitiva económica: conectividad anónima por defecto, liquidada en stablecoins y medida por MB, a la que un agente llega por MCP o REST sin ningún humano en el bucle. Todavía no es x402 en el cable, pero sí es x402 en espíritu — y el flujo de compra, la elección de token y el saldo medido ya están operativos ahora mismo. Consulta los precios por MB en vivo en la página de precios o intégralo en tu agente desde el hub de agentes de IA.

FAQ

¿Roamzy soporta x402 de forma nativa hoy?

No. Roamzy no expone un endpoint HTTP-402, no devuelve respuestas 402 en vivo y no habla el handshake de cabeceras de x402. Liquida en stablecoins vía el procesador NowPayments y expone el flujo de compra por MCP y REST. Ese flujo tiene la misma forma económica que x402 — conectividad con precio, liquidación en stablecoin, sin login — lo que lo hace x402-ready en dirección, aunque no en el formato que viaja por el cable.

¿Con qué stablecoins y redes puede pagar un agente?

Hay once combinaciones activas: USDT en TRON, BSC, Polygon, Optimism, Arbitrum y TON, y USDC en Solana, BSC, Polygon, Optimism y Arbitrum. Llama a roamzy_payment_options para obtener la lista actual con pistas de comisión por red, y pasa el código correspondiente como pay_currency. USDC en Solana tiene comisiones casi nulas; USDT en TRON tiene el soporte de wallets más amplio.

¿El agente necesita cuenta o KYC para pagar?

No. Roamzy es anónimo por defecto — un agente puede estimar, ordenar y pagar en stablecoin sin registrar una cuenta ni pasar KYC. Es la misma propiedad sin login que hace atractivo a x402 para agentes autónomos.

¿Cómo funciona el saldo medido por MB con los micropagos?

El agente recarga una vez un saldo en USDT/USDC (mínimo $20) y luego lo va descontando por cada MB realmente usado, sin caducidad. No pre-compra paquetes fijos de datos. Esto encaja con el modelo de micropagos de x402 — liquidación pequeña y basada en uso, en vez de una suscripción fija — y permite que una sola recarga financie muchas tareas posteriores. Consulta la guía de consumo de datos para presupuestar la mitad del consumo.