x402: pago por llamada API para que los agentes de IA paguen tu API

Qué es el pago por llamada API con x402 y por qué el 402 estuvo dormido

La idea del pago por llamada API es sencilla. Quien compra paga un monto pequeño por una petición, recibe una respuesta y no debe nada más, sin plan ni cuenta que abrir antes. x402 es el protocolo abierto que hace esto posible sobre HTTP normal, y su nombre viene del código de estado que por fin pone a trabajar.

Ese código pasó décadas sin uso. Cuando HTTP/1.1 se publicó como RFC 2068 en enero de 1997, la entrada completa del 402 decía: "This code is reserved for future use" (reservado para uso futuro). El estándar vigente, RFC 9110 de junio de 2022, mantiene la misma frase. MDN lo describe como un código no estándar sin una convención común de uso.

x402 aporta esa convención que faltaba. El servidor contesta una petición sin pagar con un 402 y las condiciones de pago en un formato que una máquina entiende. El cliente paga en una stablecoin y repite la petición con la prueba adjunta. El servidor verifica el pago y entrega los datos.

Además, el protocolo ya tiene gobernanza neutral. El 14 de julio de 2026, la Linux Foundation anunció la puesta en marcha de la x402 Foundation. Coinbase aportó el protocolo. Desde abril se habían sumado 40 organizaciones como miembros, entre ellas Visa, Mastercard, Google, AWS, Cloudflare y Circle. En nuestro mapa del ecosistema x402 verás qué hace cada actor.

Pagos agénticos para APIs: ahora el cliente es un programa

Los pagos agénticos para APIs son los que un agente de IA hace por su cuenta, sin que una persona apruebe cada uno. El agente es un programa que resuelve una tarea. Por el camino llama a modelos, herramientas y fuentes de datos, y algunas de esas llamadas cuestan dinero.

Imagina un agente al que le piden dimensionar un nicho de mercado en México. En menos de un minuto puede comprar una cotización bursátil, correr una inferencia, revisar una empresa contra una lista de sanciones y bajar un dataset pequeño. Son cuatro vendedores y cuatro pagos de pocos centavos. Nadie abriría cuatro cuentas para eso, y el agente ni siquiera puede abrir una.

También cambia la forma de la visita. Un cliente humano se registra una vez y se queda meses. Un agente aparece para una ráfaga de trabajo, hace unas pocas llamadas y quizá no vuelva nunca con la misma identidad. Por eso el pago tiene que ser tan chico y tan breve como la visita.

Los datos on-chain ya muestran ese patrón. En un informe del 14 de octubre de 2026, Chainalysis contó más de 138 millones de transacciones x402 en Base durante los 16 meses que terminaron en septiembre de 2026. Más del 87% quedó entre una centésima de centavo y diez centavos, y el tamaño más común fue de uno a diez centavos. Las wallets también empezaron a gastar antes. A fines de 2025, la wallet mediana que hacía un pago x402 tenía 73 días de antigüedad. En el tercer trimestre de 2026, esa cifra bajó a 18 minutos.

Por qué un agente se traba en tu formulario de registro

Casi todos los negocios de APIs venden con un embudo pensado para personas. Un desarrollador lee la documentación, crea una cuenta, carga una tarjeta, elige un plan y copia una key. Cada paso da por hecho una persona con correo y tarjeta.

Un agente no trae nada de eso. Cuando choca con el registro, pasa una de tres cosas. Se va a un endpoint gratuito que responde más o menos bien. Un desarrollador le pega una key compartida y paga la cuenta sin decir nada. O tu API nunca recibe la llamada. En los tres casos hubo demanda y no hubo ingreso.

Los planes lo empeoran. Supón que un agente necesita 200 llamadas esta semana y ninguna la siguiente. Un nivel mensual no encaja con ese uso, así que el agente se va. Esa cola larga de uso chico e irregular es justo la que crece a medida que más software compra solo.

Y está el costo de mantener el embudo. Sostienes el registro, el almacenamiento de keys, los límites de uso, la medición y los correos por tarjetas rechazadas. También gestionas las disputas de las tarjetas que pagan tus planes. Nada de eso suma valor a la única respuesta que el comprador quería.

Tarjetas, planes y checkouts custodiales piensan en una persona

La causa está en cómo se diseñaron las redes de tarjetas. Nacieron alrededor de la identidad del titular, una relación de cobro continua y el derecho a disputar. Como un cargo puede revertirse meses después, los procesadores piden cuentas, verificación del titular y períodos de retención. Un agente sin estado que compra una respuesta de un centavo no puede cumplir con nada de eso.

Las tarjetas cobran además una comisión fija por transacción, y esa sola comisión puede superar lo que vale una respuesta. Aunque un agente tuviera tarjeta, cobrarle por llamada te haría perder dinero en cada petición. Nuestro análisis del precio mínimo pone cifras a dónde deja de funcionar cada riel.

Los checkouts cripto custodiales tampoco lo resuelven. El dinero cae primero en un saldo de la plataforma y se paga después, así que vuelve la demora de retener y liberar. Un comprador máquina necesita lo contrario: un pago dentro de la petición, del tamaño de una unidad, liquidado en segundos y sin posibilidad de reversa.

El intercambio x402, encabezado por encabezado

La especificación vigente es la versión 2 de x402, fechada el 9 de diciembre de 2025 en el historial de versiones de la especificación x402. Sobre HTTP usa tres encabezados, todos con JSON codificado en base64:

1. El agente hace una petición común a una URL de pago.
2. El servidor responde 402 Payment Required con el encabezado PAYMENT-REQUIRED. Ahí lista lo que acepta: esquema, red, monto, activo, la dirección payTo y un tiempo límite.
3. La wallet del agente firma un pago para una de esas opciones. Luego repite la petición con el encabezado PAYMENT-SIGNATURE.
4. Un facilitador verifica la firma y liquida la transferencia on-chain. El servidor devuelve 200 OK con los datos y un encabezado PAYMENT-RESPONSE que incluye el hash de la transacción.

Este es el viaje completo, con los encabezados decodificados y recortados para leerlos mejor:

# 1) El agente pide datos
GET /v1/cotizacion?simbolo=ACME HTTP/1.1
Host: api.tuservicio.com

# 2) El servidor pone precio (PAYMENT-REQUIRED, decodificado)
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: {
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "20000",
    "asset": "<contrato de USDC en Base>",
    "payTo": "<tu wallet>",
    "maxTimeoutSeconds": 60
  }]
}

# 3) El agente paga y vuelve a pedir
GET /v1/cotizacion?simbolo=ACME HTTP/1.1
Host: api.tuservicio.com
PAYMENT-SIGNATURE: <pago firmado, base64>

# 4) Liquidado: datos y comprobante
HTTP/1.1 200 OK
PAYMENT-RESPONSE: { "success": true, "transaction": "0x...", "network": "eip155:8453" }
Content-Type: application/json

{ "simbolo": "ACME", "precio": "..." }

Hay dos detalles que importan al fijar precios. Los montos van en la unidad mínima del token, y USDC tiene seis decimales, así que "20000" equivale a dos centavos de dólar. Y eip155:8453 identifica la red principal de Base con el formato de identificador de cadena que adoptó la versión 2.

El facilitador es la única pieza que toca la blockchain. La especificación lo define como un servicio que verifica y liquida pagos, de modo que el servidor que vende los datos no corre código de blockchain. El campo payTo lleva la dirección del propio vendedor, y por eso el dinero llega directo a él.

Dónde encaja Payzum: proxy adelante, facilitador atrás

Payzum es el middleware x402 delante de tu API. No es el facilitador. En el dashboard cargas tu endpoint actual, la API key o el bearer token que ese endpoint exige y un precio por llamada. Con eso, Payzum publica una URL x402 para ese recurso.

Cuando un agente llama a esa URL, Payzum responde el 402 con tus condiciones. El pago firmado va a un facilitador externo, hoy el de Coinbase, que lo verifica y liquida el USDC sobre Base en tu wallet. Después Payzum reenvía la petición pagada a tu endpoint real con tu key y devuelve la respuesta. Tu API ve una llamada autenticada como cualquier otra. No escribes código ni implementas protocolo, así que puedes atender agentes que pagan desde el mismo día.

El facilitador de Coinbase ya mueve volumen real. Su documentación, revisada en octubre de 2026, incluye Base, Polygon, Arbitrum y Solana entre sus redes. Informa más de 100 millones de transacciones y 28 millones de dólares en volumen de pagos entre Base y Solana.

La liquidación es no-custodial. Payzum nunca agrupa ni retiene el USDC, así que no existe un saldo de Payzum que alguien pueda congelar. Según su documentación de rendimiento, Base cierra un bloque completo cada dos segundos y da preconfirmaciones en unos 200 milisegundos. Cuando la transferencia se confirma, es final y no hay ventana de contracargo.

Alrededor del pago tienes las herramientas de siempre de Payzum: una REST API con keys, webhooks firmados por cada llamada liquidada, secretos encriptados, 2FA y un audit log completo. La página de x402 muestra el dashboard, y nuestra guía de procesador sin custodia explica el modelo de liquidación.

Activa el pago por llamada API en cuatro pasos

1. Agrega tu endpoint. Carga la URL de la API que ya tienes y la key o el bearer token que pide. Tu código queda igual.
2. Ponle precio a una llamada y elige la wallet. Define cuánto cuesta una petición en USDC y la dirección de Base que la recibe. Payzum te entrega la URL x402 pública.
3. Publica la URL donde buscan los agentes. Inclúyela en tu documentación, en los listados de herramientas y en la descripción de tu servidor MCP. Desde ahí, cada llamada por esa URL paga antes de llegarte.
4. Concilia desde los dos lados. Los webhooks firmados avisan a tus sistemas de cada llamada liquidada para medición y contabilidad. Los mismos pagos aparecen en el historial de tu propia wallet.

Sobre el costo: Payzum todavía no publicó un precio para x402, así que pídenos una cotización en una llamada. Como referencia, la comisión de Payzum en ventas cripto normales es de 0,5% por venta procesada, descontada del monto recibido, más el gas de red on-chain.

Ejemplo resuelto: un agente de investigación, 260 llamadas y dos modelos de precio

Las cifras de este ejemplo son ilustrativas y no salen de ningún cliente de Payzum. Una API de datos de mercado vende un plan mensual de 49 USD con 10.000 llamadas, cerca de medio centavo por llamada. También ofrece su endpoint de cotizaciones por x402 a 0,02 USD la llamada, dentro de la franja de uno a diez centavos donde Chainalysis ubicó la mayoría de los pagos x402.

Un agente de investigación necesita cotizaciones por ráfagas a lo largo del mes:

El plan no factura nada porque el agente nunca se registra. Incluso un desarrollador que comprara por él lo dudaría: 260 llamadas son el 2,6% de la cuota, así que cada una costaría en la práctica 49 / 260, unos 0,19 USD. Es más de nueve veces el precio por llamada.

Cobrando por llamada, esa misma demanda deja 5,20 USD brutos, antes de la comisión de Payzum por x402 y del gas. Si 400 agentes se comportan igual, son 104.000 llamadas y 2.080 USD al mes de compradores que de otro modo no pagarían nada. En el 402 de cada una de esas llamadas, el campo amount dice "20000".

Qué APIs y herramientas encajan con el cobro por llamada

Cobrar por llamada sirve para todo lo que un agente consume a demanda, donde un plan es demasiado pesado y lo gratis deja dinero sobre la mesa:

• Datos de mercado y de referencia. Una cotización, una lectura del clima, un resultado deportivo o la consulta de una empresa. El agente compra solo la respuesta que necesita.
• Inferencia y enriquecimiento. Cobra por llamada al modelo o por registro enriquecido, para que el cómputo pesado se pague cuando corre y no se diluya en una tarifa plana.
• Servidores MCP y herramientas para agentes. Cualquier herramienta accesible por HTTP puede quedar detrás de una URL x402, así que cada invocación paga. Nuestra guía para monetizar un servidor MCP lo explica paso a paso.
• Búsqueda, scraping y recuperación. Mide por consulta el acceso a un índice caro en lugar de repartir una key que se puede filtrar o sobreusar.
• Excedente sobre un nivel gratuito. Deja tu cuota gratis en la API normal para que te descubran y ofrece la URL x402 a los agentes que necesitan más. Un agente que llega a tu límite puede pagar y seguir en vez de abandonar.

La mayoría de los proveedores mantiene los planes para equipos humanos y suma x402 para agentes, con los dos modelos en paralelo. Los comparamos en x402 vs facturación con API key.

Cobro por llamada con x402 frente a API keys y checkout custodial

Lo que preguntan los proveedores de APIs antes de activar x402

¿Los micropagos no fracasaron ya?

Fracasaron con personas. Los intentos anteriores pedían a un humano aprobar montos ínfimos, y las comisiones de tarjeta eran más grandes que los pagos. Acá paga un software con presupuesto, así que nadie aprueba cada centavo. El riel es una transferencia de stablecoin en una cadena con bloques de dos segundos. Esos dos cambios son los que vuelven viable una venta de dos centavos.

¿Hay suficiente demanda de agentes como para molestarse?

Es temprano. En un estudio publicado el 9 de septiembre de 2026, TRM Labs encontró 52,7 millones de dólares en 198,9 millones de liquidaciones de facilitadores desde mayo de 2025. Tras filtrar autopagos, flujos masivos y vendedores con pocos compradores, quedaron 25,62 millones con aspecto de comercio real. Entre el 0,6% y el 7,5% de eso parecía agéntico.

El propio TRM lo resume así: "nothing in the protocol requires an agent" (nada en el protocolo exige un agente). Para quien vende, eso importa menos de lo que parece, porque un script con presupuesto paga igual que un agente. La configuración es una entrada en el dashboard, así que averiguarlo cuesta poco. Nuestra lectura de los tres conteos de volumen x402 profundiza en el tema.

¿Tengo que cambiar mi API?

No. Tu endpoint sigue respondiendo como hoy. Payzum se ubica adelante, maneja el 402, pasa el pago al facilitador y reenvía la llamada pagada con tu key. Tus clientes actuales siguen llamando a tu API directo y no notan nada. La versión paso a paso está en cómo agregar x402 a tu API sin código.

¿Mi dinero está seguro con un proxy en el medio?

El proxy nunca toca el dinero. Las condiciones de pago ponen tu wallet en payTo, el facilitador liquida el USDC en esa dirección y Payzum no guarda saldo. Una transferencia confirmada en Base no se puede revertir, así que una llamada pagada queda pagada.