USDC en Base por request: el rail que hace posible cobrar por llamada

Por qué cobrar por request no tenía dónde liquidar

Todo equipo de API que miró el tráfico de agentes tuvo la misma idea y el mismo problema. La idea: dejar de vender asientos y planes, y cobrar por lo que cada llamante consume — un centavo por una consulta, una fracción de centavo por un cache hit, más por una inferencia cara. El problema: no había dónde poner la plata.

Medir es la mitad fácil. Ya contás los requests; cualquier gateway lo hace. La mitad difícil es mover el valor. Para cobrar $0,002 históricamente tenías tres opciones, y ninguna encaja con un comprador que es una máquina:

• Acumular y facturar. Medís el uso, esperás el cierre de mes, emitís la factura y la perseguís. Eso es una relación de crédito, y el crédito exige saber quién es el cliente, creer que va a pagar y tener cómo cobrarle si no lo hace. Un agente autónomo que apareció hace cuatro minutos y mañana ya no existe no es una contraparte crediticia.
• Pedir una tarjeta por adelantado. Es decir: registro, formulario, un humano con billetera en el bolsillo, un desafío 3-D Secure y una comisión fija por autorización que se come la compra entera. Una red de tarjetas es una forma razonable de mover $40. Es una forma absurda de mover $0,002.
• Créditos prepagos. La solución de compromiso que casi todos terminan construyendo. Funciona, pero ahora tenés un libro contable, un flujo de recarga, una política de reembolsos, un sistema de cobranza y un float que estás guardando por cuenta de otro. Querías vender una API y te convertiste en un banco.

Así, el precio de un request terminaba siempre redondeado hacia arriba hasta convertirse en una suscripción. No porque la suscripción sea la forma correcta de la demanda de máquinas, sino porque era el monto más chico que la plomería podía transportar. El rail dictaba el modelo de negocio.

USDC en Base por request es lo que cambió eso. No es una feature de facturación: es una capa de liquidación donde un pago de menos de un centavo cuesta menos moverlo de lo que vale, y donde ese pago ocurre dentro del request que lo disparó.

Lo que este hueco le cuesta a un negocio de API

El costo no aparece como una línea en el P&L, y por eso pasa desapercibido durante años. Se manifiesta como tres distorsiones.

Ponés precio pensando en el comprador equivocado. Un piso de USD 49 al mes es una respuesta racional a una comisión fija de $0,30 por autorización: es el ticket más chico que no pierde plata. Pero ese piso es invisible para quien quería once llamadas. No lo convierte a un precio menor: hace que directamente no exista. Nunca ves la demanda que dejaste afuera, así que jamás aparece en un dashboard como pérdida.

Pagás por tráfico que nunca te paga. Las capas gratuitas existen para resolver el mismo problema desde el otro lado: como no podés cobrar montos chicos, los regalás. Después los agentes descubren el free tier y deja de ser presupuesto de marketing para convertirse en factura de cómputo. La respuesta habitual son los rate limits: terminás estrangulando a tu no-cliente más entusiasta en vez de cobrarle, porque no tenés mecanismo para cobrarle.

Perdés al comprador que llega listo. Este es el caro. Un agente que golpea tu endpoint con una wallet fondeada es un cliente con la plata en la mano y cero interés en negociar. Si tu única puerta es un formulario de registro y una tarjeta, ese comprador se va. No abre un ticket de soporte ni completa una encuesta de churn: elige el endpoint que le respondió con un precio que podía pagar y no vuelve.

En LATAM hay una capa extra: muchos proveedores de API facturan en dólares desde países donde abrir la cuenta de cobro internacional es la parte más lenta del negocio — un tema que tratamos en cobrar desde el exterior sin cuenta bancaria. Cobrar por request en USDC salta ese paso entero: el dólar llega a tu wallet, no a un trámite.

Por qué los rails tradicionales estructuralmente no pueden hacer esto

Es tentador leer las tablas de comisiones y concluir que las redes de tarjetas son simplemente caras. La respuesta real es más útil: están construidas para otro trabajo, y cada pieza lo refleja.

Un pago con tarjeta es reversible por diseño. La protección al consumidor que tenés como tarjetahabiente — poder disputar un cargo meses después — es el producto. Esa reversibilidad hay que financiarla, monitorearla y arbitrarla, y esa maquinaria cuesta un monto fijo por transacción, sea de $3 o de $3.000. Ese piso fijo es exactamente lo que vuelve imposible un pago de $0,002: el overhead es mil veces el pago.

Un pago con tarjeta también es custodial y diferido. Los fondos van al adquirente, quedan en una cuenta de comercio y llegan a tu banco uno a tres días después — después de reservas, retenciones y un equipo de riesgo que puede decidir que tu patrón de tráfico es raro. Tráfico de alta frecuencia, bajo valor y originado por máquinas es justamente el patrón que un underwriting conservador marca.

Y un pago con tarjeta es identidad primero. Asume un humano con nombre, domicilio de facturación y relación bancaria. Un agente autónomo no tiene nada de eso: tiene una wallet, un presupuesto y una tarea. Pedirle que complete un registro no es un problema de UX que se resuelva puliendo pantallas: es un error de categoría.

Las transferencias bancarias fallan por latencia y montos mínimos. La facturación falla porque es crédito. Lo que cobrar por request necesitaba era un rail final en el momento del pago, lo bastante barato para que la comisión no se coma el pago, lo bastante rápido para ocurrir a mitad de un request, y abierto a una contraparte cuya única identidad es una dirección de wallet. Esa combinación no existía en la infraestructura tradicional. Existe en una L2 con stablecoins.

Por qué USDC en Base por request, y no cualquier cripto

"Cobrar en cripto" no es una respuesta: la mayoría de las cadenas y de los tokens no sirven para esto. Los pagos por request imponen cuatro restricciones duras, y USDC sobre Base es la combinación que cumple las cuatro a la vez.

1. La comisión tiene que ser menor que el pago

Esta es la restricción que manda y elimina casi todas las opciones de entrada. Un pago de una fracción de centavo en Ethereum mainnet es un absurdo: solo el gas puede superar la compra en órdenes de magnitud. Base es una Layer 2 sobre OP Stack construida por Coinbase; desde que la actualización Dencun de Ethereum habilitó el almacenamiento en blobs, el costo de transferir una stablecoin ahí suele quedar bastante por debajo de un centavo. Esa es la diferencia entre un pago por llamada que deja margen y uno que es puro teatro.

2. Tiene que confirmar dentro de la paciencia de un request

Un pago que liquida en diez minutos no puede ocurrir durante una llamada HTTP. Base confirma en unos dos segundos, lo que entra dentro del timeout de la mayoría de los clientes de API. Eso permite que todo el intercambio — request, 402, pago, reintento, respuesta — sea una sola interacción y no un flujo de onboarding. En las otras redes que soporta Payzum pasa lo mismo: Solana confirma en ~0,4 segundos y Polygon en ~2.

3. La unidad tiene que ser el dólar

Si ponés precio a una llamada en "0,000004 ETH", convertiste en silencio a cada cliente en operador de cambio, y a vos también. USDC está denominado en dólares: $0,002 son $0,002 al cotizar y al liquidar. Circle emite USDC nativo en Base — vale aclararlo, porque el token puenteado viejo (USDbC) todavía aparece en algunas wallets con una etiqueta parecida. El nativo es el que tiene redención directa con Circle y más liquidez, y es el que usan por defecto las herramientas de agentes.

4. El comprador tiene que poder pagar sin tener gas

Este es el detalle que vuelve práctico el pago de máquinas, y el que casi todas las explicaciones se saltean. USDC implementa EIP-3009, el estándar de transferencia con autorización. El comprador firma una autorización de datos tipados — origen, destino, monto, ventana de validez y un nonce aleatorio — y un tercero la transmite on-chain pagando el gas. Según el esquema exact-EVM de x402, ese transmisor no puede modificar el monto ni el destino: solo retransmite una firma que no puede reescribir. Así, un agente que solo tiene USDC puede pagar, y la firma no le sirve a nadie que la intercepte — o te paga a vos, a tu precio, o no hace nada.

Juntá las cuatro y tenés la razón real por la que USDC en Base por request se volvió la forma por defecto de los pagos de agentes: es la intersección donde valor de menos de un centavo puede moverse rápido, en dólares, desde una contraparte sin banco.

Cómo Payzum te deja cobrar en ese rail sin escribir código

Todo lo anterior es el rail. El hueco donde se traban los equipos es la distancia entre "el rail existe" y "mi endpoint está arriba": habría que hablar el protocolo x402, devolver un 402 válido con los requisitos de pago, verificar firmas, hablar con un facilitator, confirmar la liquidación y recién ahí hacer el trabajo. Eso es un proyecto de pagos atornillado encima de un negocio de API.

Payzum elimina ese proyecto. Se pone como middleware delante de tu endpoint existente. Configurás tres cosas en un dashboard — la URL de tu endpoint, la API key o bearer token que espera, y un precio — y Payzum publica una URL con x402 habilitado. Cuando un agente llama a esa URL, Payzum devuelve el 402 con los datos de pago, el agente paga USDC en Base, el pago se liquida a través de un facilitator externo (hoy el de Coinbase), y entonces Payzum hace de proxy y reenvía la llamada pagada a tu endpoint real con tu key, devolviendo tu respuesta al agente.

Dos cosas de ese flujo importan más que el resto:

• Tu código no cambia. Tu servicio sigue recibiendo requests autenticados normales de un cliente en el que ya confía. Sin SDK, sin implementar protocolo, sin migración. Un proveedor de API puede empezar a atender agentes que pagan el mismo día.
• La plata nunca toca un saldo de Payzum. La liquidación es no-custodial: el USDC cae en una wallet cuyas llaves tenés vos. No hay cuenta que congelar, ni calendario de payout, ni reserva. La liquidación es el pago.

Y para ser precisos con los roles, porque es lo que más se confunde: Payzum no es el facilitator. El facilitator es quien verifica la autorización firmada y la transmite on-chain; hoy es el de Coinbase. Payzum es la capa proxy que le permite a tu endpoint hablar x402 sin que implementes nada de eso.

Cómo funciona, paso a paso

1. Apuntá Payzum a tu endpoint. Le das la URL que ya servís, más la API key o bearer token que debe inyectar al reenviar el tráfico pagado. Tu autenticación actual queda igual: la key vive en el almacén de secretos encriptados de Payzum, nunca en manos del agente.
2. Definí un precio por llamada, en dólares. Elegí un número por ruta: una fracción de centavo para una consulta barata, algunos centavos para algo que te cuesta inferencia o una API upstream. El precio se cotiza en USDC, así que lo que ponés es lo que liquida. Podés cobrar distinto por ruta.
3. Agregá la wallet que cobra. Una dirección en Base que controlás vos. Cada pago liquidado cae ahí directo: no hay saldo de Payzum en el camino ni un paso de retiro que recordar.
4. Publicá la URL x402 y dejá que los agentes la encuentren. Payzum devuelve el 402 Payment Required con tu precio y los datos de pago; los agentes y wallets que hablan x402 lo resuelven solos, pagan y reintentan. Los webhooks firmados y el audit log te dan el registro por llamada para conciliar.

Del lado del agente, el intercambio completo se ve así:

GET /v1/enrich?domain=acme.com
→ 402 Payment Required
   { "price": "0.004 USDC", "network": "base", "payTo": "0x…", "scheme": "exact" }

# el agente firma una autorización EIP-3009 y reintenta con el header de pago
GET /v1/enrich?domain=acme.com   [X-PAYMENT: <autorización firmada>]
→ 200 OK   { …la respuesta normal de tu endpoint… }

Sin cuenta. Sin intercambiar una API key con quien llama. Sin factura. La llamada y el pago son el mismo evento, y esa es la propiedad que hace funcionar todo el modelo. Si querés el recorrido a nivel protocolo, lo explicamos en x402: pago por llamada API; la comparación con la facturación por API key está en x402 vs facturación con API key.

Casos de uso: dónde la liquidación por request se paga sola

El rail importa sobre todo donde el valor de una llamada es chico, el volumen es alto y quien llama es efímero. Cuatro formas concretas:

• Una API de enriquecimiento de datos que cobra por consulta. Datos de empresas, WHOIS, geocoding, validación de direcciones. Cada llamada vale una fracción de centavo y hoy queda empaquetada en un plan que la cola larga no compra. A $0,004 por llamada en Base, esa cola larga se vuelve ingreso en vez de una regla de rate limit — y un agente de research que corre 20.000 consultas paga USD 80 sin haber creado jamás una cuenta.
• Un endpoint de inferencia o modelo con costo marginal real. Cuando cada llamada quema GPU, el free tier es un subsidio directo y los planes planos invierten tu economía unitaria: tus usuarios más pesados son los menos rentables. Cobrar por request en USDC hace que el ingreso siga al costo llamada por llamada, en la granularidad en la que el costo realmente ocurre.
• Un servidor MCP o una herramienta de agentes. El Model Context Protocol volvió tus herramientas descubribles por todos los frameworks de agentes y llegó sin ninguna capa de cobro. x402 vive por debajo, a nivel HTTP, así que una llamada paga funciona sin que el agente tenga cuenta con vos — lo desarrollamos en cómo monetizar un servidor MCP con x402.
• Un carril premium sobre una API gratuita que ya tenés. Dejá el endpoint gratis y con rate limit para humanos y hobbistas. Publicá al lado una URL x402 paga, sin throttle y con routing prioritario, para quien prefiere pagar centavos antes que esperar. Mismo backend, dos puertas, y el tráfico caro por fin se financia solo.

El hilo común: en todos los casos el comprador llegó dispuesto a pagar un monto demasiado chico para que cualquier rail convencional lo transporte. Esa es toda la oportunidad, y por eso la elección de cadena y token no es una nota técnica al pie. Es el modelo de negocio.

USDC en Base por request vs las alternativas — comparativa

Objeciones frecuentes, resueltas

"¿Una Layer 2 no es más riesgosa que liquidar en Ethereum mainnet?"

Es un trade-off distinto, no estrictamente peor, y conviene ser preciso. Base es un rollup OP Stack que publica sus datos en Ethereum: tenés disponibilidad de datos de L1 con costo y velocidad de L2. Para pagos por request la alternativa no es "liquido en mainnet": el gas de mainnet vuelve estructuralmente imposible un pago de menos de un centavo, así que la alternativa real es "no cobro nada". Si tu política de riesgo lo pide, barré el USDC acumulado hacia donde quieras que viva; como la liquidación es no-custodial, esa es tu decisión y tu llave, no un pedido de retiro a nosotros.

"No queremos tener cripto en el balance."

La exposición acá es más acotada de lo que suena. USDC está denominado en dólares, así que lo que se acumula en tu wallet es un saldo en dólares, no una posición volátil: la pregunta de volatilidad que aplica a aceptar BTC o ETH no aplica igual a una stablecoin. Payzum es crypto-only y no liquida a cuentas bancarias en fiat; lo que sí te da es liquidación en un activo atado al dólar, en una wallet que controlás, con auto-conversión opcional a USDC o USDT si alguien paga en otra cosa. La contabilidad y la política de tesorería siguen siendo tuyas: hablá con tu contador sobre cómo registrarlo.

"Nuestro tráfico es casi todo humanos con API key. ¿Hay que migrar?"

No, y no deberías. Esto es aditivo. Tus keys, planes y clientes actuales siguen funcionando igual — el proxy de Payzum se pone delante de una URL publicada aparte. Los agentes pagan por llamada en ese carril; tus clientes humanos ni se enteran. La mayoría de los proveedores con los que hablamos corren los dos modelos de forma indefinida, porque los dos compradores quieren cosas genuinamente distintas: el humano quiere costo mensual previsible, la máquina quiere pagar exactamente lo que usó y nada más.

"¿Qué pasa si un agente paga y después mi endpoint falla?"

Vale diseñarlo, y la respuesta honesta es que es una decisión de política tuya, no algo que el protocolo resuelva por vos. El pago y la entrega están fuertemente acoplados — la llamada paga se proxea de inmediato — pero los upstream tienen días malos. Los webhooks firmados y el audit log te dan el registro por llamada de qué se pagó y qué devolvió tu endpoint, que es la materia prima para lo que decidas: un crédito, un reintento, o un health check que deje de publicar precio cuando tu servicio está degradado. Es el mismo razonamiento que aplica cualquier API medida ante requests fallidos; la diferencia es que acá tenés evidencia on-chain de cada pago.