Estándares de pagos agénticos: 26 empresas escriben las reglas y ningún vendedor está en la mesa

Qué se lanzó el 18 de agosto de 2026

En Nueva York, el 18 de agosto de 2026, Rain —proveedor de infraestructura empresarial para programas de tarjetas con stablecoins— anunció la Agentic Payments Alliance, una coalición formada para definir cómo se les va a permitir a los agentes de IA transaccionar en nombre de una persona. Arrancó con 26 miembros fundadores: Avalanche, Basis Theory, Chainalysis, Circle, Coinflow, Crossmint, delta Network, Episode Six, Evertec, Fireblocks, Fiserv, Kala, Lithic, Mastercard, Monad, PayOS, Rain, Remitly, Rialo by Subzero Labs, Sardine, Shift4, Solana, Turnkey, Uniswap Labs, Visa y Yuno.

El encuadre fue de gobernanza, no de producto. Farooq Malik, cofundador y CEO de Rain, lo dijo sin vueltas: "Ninguna empresa por sí sola debería decidir cómo transaccionan los agentes en nombre de alguien". El grupo se describe como una coalición de trabajo conducida colectivamente por sus fundadores y no propiedad de ninguno, y su agenda inicial es investigación y marcos compartidos, probar estándares emergentes de identidad y autorización de agentes, e incidencia sobre las preguntas regulatorias que abren las transacciones iniciadas por máquinas. El número de fondo, según la cobertura del lanzamiento en PYMNTS, es una estimación de McKinsey de US$3–5 billones de comercio agéntico global para 2030.

La lectura más filosa fue la de American Banker: esto es un intento de EMV para la era de la IA, un organismo que estandarice autorización y riesgo antes de que cada participante construya algo incompatible. La comparación no es menor y conviene tomarla en serio: EMV es la razón por la que una tarjeta con chip funciona en una terminal de otro continente.

También es el cuarto o quinto organismo que reclama este territorio. Visa y Mastercard ya tienen protocolos de pago agéntico compitiendo entre sí. Google tiene AP2. OpenAI y Stripe tienen ACP; Shopify y Google, UCP. Y la Linux Foundation anunció la x402 Foundation el 2 de abril de 2026, operativa desde julio con unos cuarenta miembros —Adyen, AWS, American Express, Base, Circle, Cloudflare, Coinbase, Fiserv, Google, KakaoPay, Mastercard, Microsoft, Polygon Labs, PPRO, Shopify, Solana Foundation, Stripe, thirdweb y Visa, entre otros—. La cubrimos en su momento en la x402 Foundation y qué cambia un estándar abierto.

Leé la lista de miembros: es un mapa del lado comprador

Ordená los 26 fundadores por lo que realmente hacen y la foto se aclara sola:

• Redes de tarjetas: Visa, Mastercard.
• Procesadores y plataformas de adquirencia: Fiserv, Shift4, Evertec, Yuno, Coinflow, PayOS.
• Emisión de tarjetas e infraestructura de credenciales: Rain, Lithic, Episode Six, Basis Theory.
• Wallets, custodia y gestión de claves: Fireblocks, Turnkey, Crossmint.
• Cadenas e infraestructura de protocolo: Solana, Avalanche, Monad, Rialo, Uniswap Labs, delta Network, Kala.
• Riesgo, fraude y analítica: Sardine, Chainalysis.
• Emisor y remesas: Circle, Remitly.

Es un mapa completo y competente de la plomería del lado que paga: cómo se fondea el agente, cómo se lo credencia, cómo se puntúa el riesgo, por dónde se mueve la plata. Lo que falta es la otra mitad de toda transacción. Ningún comercio. Ningún proveedor de API. Ningún SaaS, marketplace, medio, vendedor de datos ni empresa de software que sea quien recibe esos pagos.

Hay un segundo hueco que desde acá se nota más: tampoco hay una sola empresa latinoamericana. Ni una fintech regional, ni un procesador local, ni una de las miles de empresas de software de Buenos Aires, Bogotá, CDMX, Montevideo o Madrid que hoy le venden servicios y APIs al mundo. Las reglas de cómo va a pagar una máquina se están escribiendo sin ningún vendedor y sin la región.

Para ser justos: la x402 Foundation sí incluye una plataforma de comercio, Shopify, y hay actores que se sientan con varios sombreros a la vez. Pero el patrón aguanta en los dos organismos. Quienes escriben los estándares de pagos agénticos son, mayoritariamente, quienes ganan dinero moviendo dinero. El negocio que tiene que decidir si acepta el pago de un agente —y que se come la pérdida si sale mal— no tiene representación.

No es una conspiración: es como siempre se escribieron los estándares de pagos, y es exactamente por eso que los comercios pasaron treinta años litigando el interchange. Igual conviene nombrarlo, porque dice algo práctico: las preguntas de la agenda son las que le importan al lado comprador, y no son las tuyas.

Sus cuatro problemas difíciles y los tuyos

Poné las dos listas una al lado de la otra y la asimetría salta.

Mirá la columna del medio. Tres de los cuatro problemas son artefactos del instrumento, no de los agentes. Identidad, autoridad delegada y atribución de fraude son difíciles porque un pago con tarjeta es una promesa: una credencial que se presenta ahora, se fondea después y se puede revertir durante meses. Todo lo que viene detrás —la tarjeta acotada, el tope de gasto, el detector de anomalías, el marco de responsabilidad— existe para administrar esa brecha entre la promesa y el dinero.

Cerrá la brecha y se cierra casi todo el set. Cuando un agente paga transfiriendo valor que liquida al llegar, no hay ventana en la que el pago pueda no ser real: o el agente tiene los fondos o la llamada falla. No necesitás saber quién es el agente para saber que cobraste; necesitás saberlo para tu propio legajo de cumplimiento, que es otra obligación que ya tenías y que el riel no modifica.

Por eso también la cuarta pregunta —las recompensas— es un problema fascinante para una red de tarjetas y un no-problema para quien vende. Buena parte de lo que vende una red es esa capa de fidelización, y un agente comprando por vos rompe al humano al que está atada.

Lo que cuesta esperar un estándar que no es sobre vos

Los organismos de estandarización tardan años. EMV, la analogía que todos usaron, se especificó a mediados de los noventa y tardó dos décadas en desplegarse en Estados Unidos, y recién se movió cuando un traspaso de responsabilidad lo forzó. La APA tiene dos docenas de miembros y está reclutando. Hay al menos otros cuatro consorcios con reclamos superpuestos. Nadie sensato espera convergencia este año.

Mientras tanto, el lado de la demanda ya está financiado y en producción. AWS habilitó los pagos de agentes en Bedrock AgentCore de forma general este mes —lo contamos en AgentCore y x402 en disponibilidad general—. Cloudflare le emite wallets e identidades a los agentes. Coinbase, Google, OpenAI y Binance tienen stacks de pago del lado comprador funcionando. Y la demanda se mide: en la semana del 17 de agosto de 2026, x402 movió 8,7 millones de transferencias en stablecoins, casi el doble que la semana previa, a un promedio de unos cuatro centavos cada una —el detalle está en la semana récord de x402—.

Cuatro centavos es toda la historia en un número. Dice dos cosas a la vez: la economía de agentes es real y crece rápido, y no puede correr sobre rieles de tarjeta, porque una transacción de cuatro centavos no absorbe un costo fijo de autorización, mucho menos una disputa. Lo desarmamos en tarjetas virtuales para agentes de IA vs x402.

Así que el riesgo real de esperar no es elegir mal el estándar. Es más prosaico: durante los próximos años los agentes van a comprar, y los vendedores alcanzables van a ser alcanzables y los que no, no. Un comité no te va a facturar mientras delibera.

La respuesta del lado vendedor ya existe

La razón por la que ningún consorcio se está reuniendo a resolver el lado del que cobra es, sin vueltas, que es la mitad más fácil, y que ya tiene una respuesta funcionando.

x402 es un protocolo abierto que usa el código HTTP 402 Payment Required, dormido desde siempre. Un agente pide tu endpoint; el endpoint responde 402 con un precio y los datos de pago; el agente paga; la llamada pasa. Coinbase lo aportó a una casa neutral en la Linux Foundation, y liquida en stablecoins: en el caso de Payzum, USDC en Base, donde una transferencia confirma en unos dos segundos y cuesta una fracción de centavo de gas.

Y acá el rol exacto de Payzum, dicho con precisión, porque es la parte que más se malinterpreta. Payzum es el middleware / proxy que se para delante de tu API existente. Vos no implementás ningún protocolo. En el panel configurás el endpoint que ya tenés, la API key o el bearer que ya usa, y un precio. Payzum publica una URL x402, devuelve el 402 al agente, gestiona el pago a través de un facilitator externo —hoy el de Coinbase— y después hace de proxy reenviando la llamada pagada a tu endpoint real con tu key. Payzum no es el facilitator hoy; serlo es un objetivo futuro, no una afirmación presente.

Y la plata no nos toca. Payzum es no-custodial: los USDC caen directo en una wallet que vos controlás. No hay saldo de Payzum, ni demora de liquidación, ni reserva, ni nada que congelar. La liquidación es el pago. El pricing es por uso: alrededor de 1.000 transacciones por mes gratis y luego unos $0,001 por transacción más gas.

Fijate qué le hace ese esquema a las cuatro preguntas de la alianza. No necesitás identificar al agente para estar seguro del cobro. No necesitás un marco de delegación, porque el agente no puede gastar plata que no tiene. No necesitás atribución de fraude, porque no hay ventana de reversa que atribuir. Y no necesitás portabilidad de beneficios, porque nunca vendiste puntos: vendiste llamadas a una API.

Cómo funciona, paso a paso

1. Elegí un endpoint que valga la pena medir. No todo tu producto: una ruta que un agente querría comprar —una búsqueda, un lookup, un enriquecimiento, una generación, un scraping—. Idealmente algo que hoy regalás o que escondés detrás de un registro que ninguna máquina va a completar nunca.
2. Conectá una wallet que controlás vos. La liquidación va ahí, directo. Elegí si los pagos entrantes se auto-convierten a USDC o USDT, para quedarte con el dólar digital que decidiste y no con el que aparezca.
3. Configurá el endpoint y el precio en el panel. Tu URL de siempre, tu API key o bearer de siempre y cuánto sale una llamada. Payzum publica la URL x402 y se ocupa del 402, del facilitator y del proxy. Cero código en tu servicio, cero protocolo, cero deploy nuevo.
4. Conectalo a lo que ya corrés. API REST con API keys, webhooks firmados y playground de integración, para que tu facturación, tu analítica o tu sistema de permisos se entere de la llamada pagada en el momento en que liquida. La mecánica completa está en x402: pago por llamada de API.
5. Hacete encontrable y poné un precio honesto. Los agentes descubren endpoints con precio; si el tuyo responde un 402 con un número razonable, es comprable. Empezá con un precio por llamada y no por asiento: cotizarle a máquinas es otro ejercicio, y lo recorrimos en x402 vs facturación con API key.

Dónde aparece esto en negocios reales

Nada de lo que sigue necesita que alguien termine de escribir un estándar.

• La empresa de API con un muro de registro que ninguna máquina puede pasar. Un proveedor de datos o de enriquecimiento recibe tráfico de agentes que rebota contra un formulario de free tier que pide mail, tarjeta y un humano. Publicar ese mismo endpoint con precio por llamada convierte tráfico rechazado en ingreso: el argumento completo en dejá que los agentes de IA paguen tu API.
• El servidor MCP que nadie paga. Alguien construyó una herramienta genuinamente útil, la llaman miles de veces por día dentro de los asistentes de otros y no factura nada, porque no había forma de cobrarle a un llamador que no es persona. Ver monetizar un servidor MCP con x402.
• La transacción de cuatro centavos. Un precio de US$0,0004 por llamada es imposible en cualquier riel de tarjeta: solo la autorización ya lo supera. En USDC en Base, por request, es rutina.
• El que exporta servicios desde la región. Un estudio de software en Buenos Aires, Bogotá o Montevideo que vende una API al exterior conoce el problema de siempre: el giro tarda, llega descontado o directamente no sale, y los rieles instantáneos locales —Pix, SPEI, Bizum, CBU— son para residentes y no existen para una máquina del otro lado del mundo. Un endpoint que cobra en USDC a la wallet propia no depende de ninguno de los dos.
• El que solo quiere finalidad. Las compras iniciadas por agentes abren una pregunta de responsabilidad que nadie resolvió limpio sobre rieles reversibles: quién se la come cuando el agente compra mal. Lo miramos en contracargos y comercio agéntico. Sobre un riel liquidado la pregunta no aparece, lo que no significa que sea gratis: significa que tu política de reembolso tiene que estar escrita, porque los reembolsos son pagos que iniciás vos.

Esperar el estándar vs publicar un endpoint pago hoy

Objeciones que vale la pena tomar en serio

"¿x402 no es también uno más de varios estándares en pugna?"

Sí, y decir lo contrario sería deshonesto. x402 convive con AP2, ACP, UCP, los protocolos de agentes de Visa y Mastercard y ahora los marcos que saque la APA. Lo que vuelve asimétrico el riesgo es de qué lado de la transacción estás. El lado comprador tiene que elegir un stack y construir contra él. El lado vendedor, en este esquema, se queda con su propio endpoint, su propia API key y su propia wallet, y alquila una pasarela adelante. Si gana otro protocolo, lo que cambia es la configuración de la pasarela: no tu servicio, no tu facturación, no dónde vive tu dinero. Vale sumar un dato: x402 ya figura como extensión dentro de AP2 de Google, y varios fundadores de la APA también se sientan en la x402 Foundation. Estos organismos se superponen más de lo que sugieren los titulares.

"Visa y Mastercard están en todos. ¿No significa que ganan las tarjetas?"

Significa que quieren estar presentes donde sea que esto aterrice, lo cual es racional y no dice nada sobre la economía. La restricción de la tarjeta en la economía de agentes no es estratégica, es aritmética: un riel con costo fijo por autorización y una ventana de disputa de meses no puede servir a un mercado cuyo ticket promedio son cuatro centavos. Las tarjetas probablemente ganen la compra agéntica grande y aprobada por un humano —un vuelo, un hotel, una reposición de stock—. Los micropagos máquina a máquina por llamadas de API son otro mercado con otra física, y la posición honesta es que van a convivir.

"¿No conviene esperar a que se definan las reglas de responsabilidad?"

Si vendés un bien físico de ticket alto a consumidores a través de un agente, hay un argumento real para mirar ese espacio: la responsabilidad está sin resolver y no es tuya para resolverla. Si vendés llamadas de API, herramientas, datos o cómputo, esperar no te compra nada, porque el problema que estarías esperando es una propiedad de los instrumentos reversibles. Y el legajo de cumplimiento no cambia en ningún caso: identificación de clientes, facturación, registros, deberes de sanciones e impuestos no se mueven porque cambie el instrumento de liquidación. Lo que mejora es la evidencia: un registro con marca de tiempo y verificable de un monto exacto llegando a una dirección que controlás, más un audit log completo.