x402: Pago por Llamada API para que la IA Pague tu API

Qué es x402 y por qué importa el pago por llamada API ahora

x402 es un estándar abierto para pagar sobre HTTP. Toma un código de estado que llevaba décadas sin uso — 402 Payment Required — y le da un significado concreto: este recurso cuesta dinero, así se paga, reintenta con prueba de pago. El comprador liquida el monto en una stablecoin, reintenta la petición y el servidor devuelve los datos. Todo el intercambio ocurre dentro del ciclo normal de petición/respuesta de la web.

Durante casi toda la historia de la web esa idea no tenía a dónde ir. El dinero se movía sobre rieles de tarjeta que necesitaban un humano, una relación de facturación y días para liquidar — nada de eso encaja con una sola llamada API que vale una fracción de centavo. Lo que cambió es el comprador. El consumidor de APIs que más rápido crece ya no es una persona haciendo clic en un botón; es un agente IA que llama a herramientas, modelos y fuentes de datos miles de veces para completar una tarea. Ese comprador no puede llenar un formulario de registro ni esperar una factura. Necesita pagar, de forma programática, en el instante en que choca con un muro de pago — exactamente la brecha que x402 fue diseñado para cerrar.

El problema: los agentes pueden llamar tu API, pero no pueden pagarla

Si operas una API, un feed de datos o una herramienta para desarrolladores, tus opciones de monetización fueron construidas para clientes humanos: un flujo de registro, una API key emitida después de que alguien ingresa una tarjeta, un plan mensual y un panel para gestionarlo. Cada uno de esos pasos asume que hay una persona en el bucle, con un email, una tarjeta y la paciencia para hacer el onboarding.

Los agentes autónomos rompen ese modelo. Un agente que orquesta una tarea puede querer llamar tu endpoint una vez, o diez mil veces, y no tiene forma de inscribirse solo en tu sistema de facturación. Así que no lo hace — se salta por completo las APIs de pago, o un desarrollador pre-aprovisiona una key compartida y se come el costo, o tu servicio simplemente nunca se llama porque no hay camino entre "el agente necesita estos datos" y "el agente te paga por ellos". La demanda es real y crece; el riel de pago para capturarla ha estado ausente.

Lo que te cuesta seguir en suscripciones y API keys

El precio por suscripción obliga a cada comprador a la misma forma: un plan recurrente dimensionado para un equipo humano. Un agente que necesita cien llamadas esta semana y ninguna la próxima tiene que comprometerse con un nivel mensual o irse a otro lado. Pierdes la larga cola de uso pequeño, esporádico y movido por máquinas — que es justamente el uso que escala a medida que crece la web agéntica.

Las API keys traen su propio impuesto. Construyes y mantienes el registro, la bóveda de keys, el rate limiting, la medición, los emails de cobro cuando una tarjeta falla. Cargas con el riesgo de contracargo en los pagos con tarjeta detrás de esos planes, y esperas días a que los fondos liquiden mientras un adquirente los retiene. Mientras tanto, el valor que de verdad vendes — una sola respuesta medida — queda enterrado bajo una capa de gestión de cuentas que el comprador nunca quiso y que un agente literalmente no puede usar. El pago por llamada elimina toda esa capa: la petición es la compra.

Cómo funciona realmente el flujo de pago x402

x402 es un apretón de manos pequeño y nativo de HTTP. Nada en él requiere un navegador, una redirección o una página de checkout alojada — está diseñado para que un programa le pague a otro. El flujo se ve así:

1. Un agente hace una petición normal a tu endpoint de pago.
2. En lugar de los datos, el servidor que está delante del recurso responde 402 Payment Required con el precio y a dónde enviarlo (activo, monto, red, destino).
3. La wallet del agente paga el monto indicado — una transferencia de USDC sobre Base — y adjunta la prueba de pago a una segunda petición idéntica.
4. Un facilitador verifica el pago on-chain; el servidor ve que está liquidado y devuelve el recurso.

En esencia, el viaje de ida y vuelta es solo:

# 1) El agente llama un endpoint de pago
GET /v1/market-data HTTP/1.1
Host: api.tuservicio.com

# 2) Servidor: paga primero
HTTP/1.1 402 Payment Required
Accept-Payment: x402
X-Price: 0.01 USDC
X-Network: base

# 3) El agente reintenta con prueba de un pago USDC sobre Base
GET /v1/market-data HTTP/1.1
Host: api.tuservicio.com
X-Payment: <prueba de pago firmada>

# 4) Verificado y liquidado → datos devueltos
HTTP/1.1 200 OK
Content-Type: application/json
{ "data": "..." }

Dos capas hacen esto práctico. Un facilitador verifica el pago on-chain y confirma la liquidación, para que el código de nadie tenga que hablar blockchain directamente. Y un proxy delante de tu API habla el apretón de manos x402 por ti — devuelve el 402, recoge la prueba y luego reenvía la petición pagada a tu endpoint real. Payzum es ese proxy: corre el flujo x402 e integra el facilitador de liquidación, para que tu servicio nunca tenga que hacerlo.

Cómo Payzum liquida los pagos x402 a tu propia wallet

Acá está la parte que hace la adopción trivial: tú no implementas x402 — lo hace Payzum. Agregas tu endpoint de API existente y la API key o bearer token que Payzum debe usar para llamarlo, fijas un precio, y Payzum publica una URL x402 de pago delante de él. Cuando un agente paga, Payzum reenvía la petición a tu endpoint real, inyectando tu key, y devuelve la respuesta. Tu servicio sigue haciendo exactamente lo que ya hace — Payzum se encarga del 402, del pago y de toda la plomería. Es una configuración de dashboard, no un proyecto de integración, así que un proveedor de API puede empezar a servir llamadas pagadas de agentes de inmediato sin cambiar una línea de código.

La liquidación sigue siendo no-custodial. Cuando un agente paga una de tus llamadas, el USDC sobre Base liquida directo a una wallet que tú controlas; Payzum coordina el pago pero nunca agrupa, retiene ni controla el dinero — así que, como en todos los rieles de Payzum, no hay saldo de plataforma que nadie pueda congelar. Como explicamos en nuestra guía de procesador sin custodia, la liquidación es el pago.

Base es el hogar adecuado para esto. Es un Layer 2 de Ethereum donde las transferencias de USDC confirman en unos dos segundos y cuestan una fracción de centavo en gas — rápido y barato como para que pagar por cada llamada API individual sea económicamente sensato, no solo técnicamente posible. Como el pago es una transferencia de stablecoin, es final en el momento en que confirma: sin contracargos, sin reversas, sin un intermediario de red de tarjetas decidiendo si tu dinero es de verdad tuyo.

Obtienes la superficie de desarrollo que esperarías alrededor: una REST API con API keys para tu propia integración, webhooks firmados para que cada llamada liquidada dispare un evento en tus sistemas, secretos encriptados, 2FA y un audit log completo. El pago agéntico es nuevo; las herramientas operativas alrededor son el mismo stack probado de Payzum.

Cómo activar el pago por llamada API, paso a paso

1. Apunta Payzum a tu API. En el dashboard, agrega tu endpoint existente y la API key o bearer token que Payzum debe usar para llamarlo en tu nombre. Sin cambios de código de tu lado.
2. Fija un precio y tu wallet de cobro. Decide cuánto vale una llamada — una fracción de centavo, un centavo, más por cómputo pesado — y la wallet de Base donde debe llegar el USDC. Payzum publica una URL x402 de pago para ese recurso.
3. Payzum corre el 402 y hace de proxy de la llamada. Cuando un agente entra a la URL, Payzum devuelve el 402, el pago liquida en USDC sobre Base, y Payzum reenvía la petición pagada a tu endpoint y devuelve su respuesta.
4. Concilia con webhooks firmados. Cada llamada liquidada dispara un webhook firmado en tus sistemas para medición, analítica y contabilidad — respaldado por 2FA, secretos encriptados y audit log.

Hay un nivel gratuito para empezar: aproximadamente las primeras 1.000 transacciones al mes son gratis, luego alrededor de $0,001 por transacción más gas, de modo que el costo de aceptar un pago se mantiene muy por debajo del valor de la llamada.

Casos de uso: quién monetiza con x402

El pago por llamada encaja en cualquier cosa que un agente pueda consumir bajo demanda, donde una suscripción es demasiado pesada y lo "gratis" deja dinero sobre la mesa:

• APIs de datos y mercado: vende una sola cotización de precio, una consulta de clima, un dato deportivo o una verificación de compliance por una fracción de centavo — y deja que los agentes compren exactamente las llamadas que necesitan, cuando las necesitan.
• Herramientas IA y endpoints de inferencia: cobra por llamada al modelo, por generación o por enriquecimiento, para que el cómputo pesado se pague en el momento en que se usa en vez de promediarse en un plan plano.
• Servidores MCP y herramientas de agentes: pon un muro de pago alrededor de una herramienta que expones a agentes IA, para que cada invocación de tu servidor MCP liquide USDC directo a tu wallet.
• Scraping, búsqueda y recuperación premium: mide el acceso a un índice caro o un dataset curado por consulta, sin una API key compartida que se filtre o se sobreutilice.

El hilo común es la granularidad. Cuando la unidad de valor es una respuesta, la unidad de pago debería ser también una respuesta — y quien coloca esa orden es cada vez más un agente, no una persona.

Pago por llamada con x402 vs API keys y suscripciones

Objeciones frecuentes, resueltas

¿No es muy caro pagar por llamada en comisiones y gas?

Por eso x402 liquida en Base con USDC. Una transferencia ahí confirma en unos dos segundos y cuesta una fracción de centavo en gas, y el costo por transacción de Payzum ronda la décima de centavo tras un nivel mensual gratis. La economía solo funciona porque el riel es barato y rápido — que es justo el sentido de usar una stablecoin sobre un Layer 2 en vez de una tarjeta.

¿Tengo que reconstruir mi API para soportar x402?

No — ni siquiera implementas x402 tú mismo. Apuntas Payzum a tu endpoint existente y agregas tu API key; Payzum se pone delante como proxy, devuelve el 402, liquida el pago y luego reenvía la petición pagada a tu servicio. No cambias código ni implementas ningún protocolo — es una configuración de dashboard, que es lo que permite a los proveedores de API empezar a servir agentes el mismo día.

¿El dinero está seguro si Payzum está en el medio?

Payzum es no-custodial. El USDC liquida directo a una wallet que tú controlas; Payzum verifica y coordina el pago pero nunca lo retiene. No hay saldo de Payzum que congelar, y la finalidad on-chain significa que una llamada liquidada no se puede revertir.