Agentes y automatización Inteligencia artificial

x402: cómo los agentes de IA pagan por lo que usan

8 de noviembre de 2026 Miquel Monsalvat · Human-IA

Hay un código en el protocolo HTTP que lleva ahí desde los primeros días de la web y casi nadie ha visto en acción: el 402 «Payment Required». Estaba pensado para que un servidor pudiera exigir un pago antes de servir contenido, pero, según recoge Coinbase, nunca llegó a realizarse (Coinbase). Era el código de estado que esperaba en la sala de espera sin que nadie pasara a buscarlo.

Ahora ha encontrado trabajo gracias a los agentes de IA y a un estándar llamado x402. Este artículo explica qué es, cómo funciona, quién lo respalda y qué riesgos tiene. Separa lo que está documentado de lo que son anuncios, estimaciones o escenarios de futuro.

Qué es x402 y qué problema resuelve

x402 es un estándar abierto de pago nativo de la web, construido sobre el código HTTP 402. No es una criptomoneda ni una blockchain. Es un conjunto de reglas (mensajes, cabeceras y un flujo de petición y respuesta) que cualquier servidor o cliente puede implementar (documentación de x402, repositorio en GitHub).

Lo incubó Coinbase y se publicó en mayo de 2025. Después se cedió a la x402 Foundation, que se gobierna bajo la Linux Foundation (Cloudflare, Coinbase).

El problema que resuelve es muy práctico. Un agente de IA no puede rellenar un formulario de pago, darse de alta en una suscripción mensual ni gestionar una clave de API distinta para cada servicio que utiliza. Con x402, el agente paga por un recurso (una llamada a una API, un dato, un artículo) dentro de la propia petición HTTP, sin cuenta, sin sesión y sin clave (Decrypt).

Imagina que cada vez que quieres un café tuvieras que registrarte en la web del fabricante de la máquina, verificar el correo y aceptar las cookies. Para una persona sería un fastidio, y para un agente que consulta cien servicios en un minuto, un callejón sin salida.

Cómo funciona, paso a paso

La mejor imagen es la de una máquina expendedora con una peculiaridad: te dice el precio cuando pulsas el botón, tú pagas y recoges el producto en la misma operación. En x402 son dos peticiones HTTP y no hace falta registro previo (Coinbase Developer Platform, Polygon):

El cliente pide un recurso, por ejemplo GET /datos. Es el equivalente a pulsar el botón.
El servidor responde 402 Payment Required. Incluye un objeto PaymentRequirements legible por máquina (el campo accepts) con el esquema que acepta, la red, el precio y la dirección a la que pagar. Es el cartelito con el importe.
El cliente firma una autorización de pago con su cartera y reenvía la petición con la cabecera PAYMENT-SIGNATURE, que lleva el payload firmado en Base64. Es meter la moneda.
El servidor verifica la firma, bien por su cuenta, bien delegando en un facilitador (a través de /verify).
Se liquida el pago en cadena. El facilitador ejecuta /settle y espera la confirmación. El servidor devuelve entonces un 200 OK con el recurso y una cabecera PAYMENT-RESPONSE con el recibo. Cae el café.

En la versión 2 del estándar, las cabeceras quedan normalizadas así (documentación de HTTP 402 en x402):

PAYMENT-REQUIRED: del servidor al cliente.
PAYMENT-SIGNATURE: del cliente al servidor.
PAYMENT-RESPONSE: del servidor al cliente.

Tres roles y varios esquemas de pago

El sistema reparte el trabajo entre tres figuras: el cliente (el comprador, normalmente un agente), el servidor (el vendedor) y el facilitador, un intermediario de confianza que verifica y liquida (arXiv: «When HTTP 402 Meets the Blockchain»).

El campo scheme define cómo se cobra. Según el repositorio del proyecto y Cloudflare, estos son los esquemas descritos (GitHub, Cloudflare):

exact: un importe fijo por petición.
upto: un tope máximo, y el vendedor liquida el uso real.
batch-settlement: monederos con vales fuera de la cadena que se liquidan en lote.
deferred: una propuesta de Cloudflare basada en firmas HTTP, sin transacción inmediata en cadena.

Ilustración del flujo de un micropago con x402 en cuatro etapas: la petición, la respuesta 402 Payment Required, la firma y el pago, y el recurso entregado con un 200 OK.

HTTP 402: la historia del código olvidado

HTTP organiza sus respuestas en familias de códigos. El 200 significa que todo fue bien, el 404 que no se encontró nada, y el 402 que hay que pagar. Los dos primeros se hicieron famosos, mientras que el tercero quedó reservado para un uso futuro que no llegó (Coinbase).

x402 lo activa sin inventar una capa nueva. Usa códigos y cabeceras HTTP estándar, de modo que la compatibilidad con la web existente se mantiene (documentación de x402). Aun así, el estándar no sustituye al protocolo HTTP: se apoya en un hueco que HTTP dejó previsto.

Pagos entre agentes, servicios y APIs

Los casos de uso documentados giran en torno a una idea: máquinas que compran a máquinas, en cantidades pequeñas y sin intervención humana en cada compra.

Monetizar contenido y APIs. AWS ha habilitado x402 en CloudFront y WAF, como un interruptor sobre la configuración existente. Cuando un agente pide contenido, recibe un 402 con lo que debe pagar, paga, el facilitador de Coinbase verifica y se sirve el contenido, «todo en una petición» (Coinbase). Este caso es un anuncio y una integración de producto, no un dato de uso masivo.
Agentes y MCP. El Agents SDK de Cloudflare permite que un agente pague herramientas de servidores MCP (Model Context Protocol). Si el agente intenta usar una herramienta de pago, el servidor MCP responde 402 y el agente interpreta las instrucciones, con confirmación humana o sin ella (Cloudflare).
Ejemplos que cita Cloudflare: un asistente que compra accesorios en varias tiendas, un agente que paga por sesión de renderizado en lugar de una suscripción mensual y un operador autónomo que hace micropagos por un flujo de datos en tiempo real (Cloudflare). Son escenarios que ilustran el potencial, no casos con cifras verificadas.

El patrón común es sustituir la suscripción de «todo o nada» por un pago proporcional al uso. En lugar de contratar un plan mensual para consultar un dato tres veces, el agente paga esas tres consultas. A esto se le suele llamar micropagos, y la idea de fondo es que un agente pague solo por lo que consume.

Ilustración que compara la suscripción mensual con el micropago: el plan se paga lo uses o no, mientras que el micropago cobra solo las consultas que se hacen.

El ecosistema: fundación, facilitadores, USDC y Bazaar

La fundación. La x402 Foundation, bajo la Linux Foundation, reúne a más de 50 empresas. Entre los fundadores figura AWS y, según distintas fuentes, también Cloudflare, Visa, Mastercard, Google, Circle, NEAR y Anthropic (Decrypt, Cloudflare). Como la lista varía según la fuente, conviene verificar la composición exacta en las páginas oficiales de la fundación antes de darla por cerrada.

La liquidación. Se hace principalmente en USDC sobre Base, la red de segunda capa de Ethereum que impulsa Coinbase. El protocolo, sin embargo, es agnóstico de red y de token. Los facilitadores operan en varias cadenas, con Coinbase y Polygon entre los ejemplos citados.

Los SDK. Existen en TypeScript, Python, Go y .NET (arXiv: «Five Attacks on x402»).

El descubrimiento. Un agente necesita saber dónde hay servicios que cobren por x402. Para eso existen x402 Bazaar, un registro abierto y buscable de endpoints x402 del que se citan más de 13.000 servidores de recursos (arXiv), y Agentic.Market, un catálogo curado de Coinbase.

Las cifras, con cautela

Estas son las cifras de adopción que circulan. Son datos de terceros y deben leerse como estimaciones, no como hechos consolidados:

Más de 196 millones de transacciones en 12 cadenas hasta el 1 de noviembre de 2026, con más de 42 millones de dólares liquidados. Es la cifra de Fireblocks, que a su vez cita a agenteconomy.to (Decrypt).
Coinbase afirma que más del 97 % de las transacciones on-chain de agentes en el segundo trimestre de 2026 usaron x402 (Decrypt). Es una afirmación de una de las partes interesadas.
Cloudflare dice enviar más de mil millones de respuestas HTTP 402 al día a bots y rastreadores (Cloudflare). Es un dato de la propia empresa. Hay que notar que una respuesta 402 es una petición de pago, no un pago completado.

Un cálculo aproximado, y por tanto análisis y no dato, sobre las dos primeras cifras: 42 millones de dólares entre 196 millones de transacciones da una media de unos 0,21 dólares por transacción. Encaja con la idea de micropagos, aunque una media oculta mucha variedad y depende de lo fiables que sean las cifras de origen.

Limitaciones y seguridad

Un sistema que mueve dinero de forma automática atrae a quien quiere aprovecharse de él. La investigación académica ya lo ha examinado, y conviene contarlo con la misma claridad que las ventajas.

Un puente entre dos mundos. x402 combina una autorización HTTP síncrona (la respuesta tiene que llegar ya) con una liquidación en cadena de finalidad probabilística (la certeza llega con el tiempo). El puente entre ambas es el facilitador, y el protocolo no impone que este se comporte correctamente (arXiv).

Ataques documentados. Los investigadores describen cinco ataques concretos que afectan a la autorización, al binding, al replay y al manejo en la capa web, y proponen ocho reglas de seguridad para facilitadores. Entre los vectores nombrados están Free Shopping, Asset Theft, Service Denial y Gas Abuse. Se hallaron violaciones en los 15 facilitadores evaluados, que atendían a más de 60.000 vendedores y 360.000 compradores. Según los trabajos, las vulnerabilidades ya se han mitigado tras una divulgación responsable (arXiv, arXiv). Que se encontraran en todos los facilitadores analizados no es una buena noticia, pero que se corrigieran sí lo es. Así es como suele madurar un estándar joven.

Privacidad. Cada pago incluye metadatos como resource_url, description y reason en claro, visibles para el servidor y para el facilitador. Un estudio propone filtrar los datos personales antes del envío (arXiv: «PII-Safe Agentic Payments»). Si un agente describe por qué compra algo, esa descripción viaja con el pago.

Centralización. El facilitador es infraestructura compartida, y un fallo en uno de ellos puede afectar a muchos servicios a la vez (arXiv).

Presente y futuro

Conviene separar lo que existe de lo que se espera.

Lo que está documentado hoy:

Pago por petición en USDC sobre Base.
Facilitadores que verifican y liquidan.
SDK en varios lenguajes.
Integración en CloudFront y WAF, en el Agents SDK de Cloudflare y en servidores MCP.
Un registro de descubrimiento, Bazaar.
Soporte de liquidación por lotes, incorporado en mayo de 2026.

Lo que son escenarios de futuro, no hechos:

Rieles fiat, ya que el protocolo se declara extensible a redes cripto y a dinero tradicional.
Pagos entre agentes a gran escala.
Precios variables según el uso.
Una liquidación por lotes generalizada y los esquemas de pago diferido.

Que el estándar se declare agnóstico y extensible no garantiza que esos escenarios se cumplan. Dependerá de que se adopten, de que los facilitadores sean robustos y de que los usuarios y las empresas confíen en dejar que un agente gaste su dinero.

Por qué importa para la economía de los agentes

La web actual está construida para personas con tarjeta, correo electrónico y paciencia. Los agentes de IA no tienen ninguna de las tres cosas, y cada vez hacen más tareas por cuenta de alguien. Si van a consultar datos, usar herramientas y contratar servicios, necesitan una forma de pagar que funcione a la velocidad de una petición HTTP.

x402 es un intento serio de dársela, con una virtud: se apoya en algo que ya existía, un código de estado esperando su momento. Su historial es todavía corto. Las cifras de adopción son estimaciones de terceros, los facilitadores concentran riesgo y la privacidad de los metadatos está en discusión. Aun así, conviene seguirlo, porque describe cómo podrían empezar a comprar los agentes. Si funciona, el código 402 dejará de ser una rareza de los manuales y se convertirá en una parte cotidiana de la infraestructura.

Para ampliar información

<strong>x402 es una marca registrada de The Linux Foundation.</strong> Este artículo no está afiliado ni patrocinado por x402 ni por la Linux Foundation.