El marco de pagos agénticos de EMVCo: las tarjetas construyen un registro para algo que una wallet ya sabe

Qué publicó EMVCo el 1 de septiembre de 2026

EMVCo no es una startup con una tesis. Es el organismo técnico propiedad de las seis redes de tarjetas que escribe las especificaciones que implementa todo el mundo del plástico: el chip EMV, EMV 3-D Secure, la tokenización de pagos. Cuando EMVCo publica un marco, está describiendo la forma que tendrán los pagos con tarjeta dentro de cinco años.

El 1 de septiembre de 2026 publicó un borrador titulado EMV® Agentic Payments – Framework for Specifications v1.0 y lo abrió a comentarios públicos hasta el 30 de septiembre de 2026. El objetivo declarado son pagos agénticos con tarjeta seguros, interoperables y escalables: agentes de IA comprando con la credencial de una persona.

La pieza central es un concepto nuevo: los Intent Services. En palabras de Clinton Allen, presidente del Agentic Payments Task Force de EMVCo, es «una capa compartida e interoperable que permite a los participantes del pago registrar, referenciar, recuperar y gestionar la intención autorizada por el consumidor antes, durante y después de una transacción». El borrador describe los roles del ecosistema y los campos de datos necesarios para tres tareas: registrar la intención, mantener su ciclo de vida y su estado, y permitir que las partes autorizadas la consulten.

EMVCo dice haberse centrado en los escenarios de tarjeta donde la intención hay que gestionarla en el tiempo: compras recurrentes, presupuestos acumulados y actividad posterior a la transacción. Y plantea que esa capa «complemente la garantía criptográfica que ya aportan soluciones del sector, como Verifiable Intent, con un punto común de coordinación». Dos capacidades quedan marcadas para posibles publicaciones futuras: Know Your Agent e indicadores de transacción agéntica, para que el rail pueda identificar qué agente intervino y señalar que hubo un agente.

La frase que revela todo el problema

Enterrada en el planteamiento hay la frase más honesta que ha publicado un organismo de tarjetas sobre el comercio agéntico. Como lo resumió PYMNTS: una credencial válida puede decirle al emisor que un agente de IA puede pagar; no le dice si ese agente debería hacer esa compra concreta.

El propio ejemplo de EMVCo es un consumidor que autoriza a su agente a gastar hasta 300 dólares al mes en el supermercado. La credencial sigue siendo válida todo el mes. El cuarto pedido es el que rompe el mandato, y nada en el mensaje de autorización lo sabe. La red ve una petición bien formada, con un token bueno, y ningún motivo para rechazarla.

Leelo con cuidado, porque no es una carencia de software. Es una propiedad del rail. Un pago con tarjeta es un pull: el comercio presenta una credencial y le pide a un emisor que adelante dinero que el pagador no tiene en ese momento. La autoridad para hacerlo vive en un contrato entre el titular y su banco, no en la transacción. Así que cuando delegás una porción de esa autoridad en un software, no hay lugar dentro del pago donde esa porción pueda vivir. Alguien tiene que llevar un libro aparte de cuánto mandato queda.

Ese libro aparte es exactamente lo que son los Intent Services. Y tiene que ser compartido, porque la plataforma del agente, el comercio, el adquirente y el emisor necesitan consultar el mismo estado. Por eso EMVCo lo describe como un punto común de coordinación y no como una función que cualquier participante pueda lanzar por su cuenta.

Cuánto cuesta que los «Intent Services» existan

Contá las piezas que necesitaría una compra agéntica con tarjeta bajo esta arquitectura:

• Una credencial: la tarjeta tokenizada, que prueba que el instrumento es válido.
• Verifiable Intent o equivalente: prueba criptográfica de que un humano autorizó un mandato.
• Intent Services: un registro compartido y con estado que sepa cuánto queda de ese mandato ahora mismo, y que sobreviva entre participantes y en el tiempo.
• Know Your Agent: identidad para el software, para saber qué agente está actuando. (Cubrimos el esfuerzo de Visa · Mastercard · Ant en Know Your Agent: las tarjetas le están dando pasaporte a los agentes de IA.)
• Indicadores de transacción agéntica: una bandera en el mensaje que diga «esto lo hizo un agente».
• Y debajo de todo, la maquinaria existente de autorización y disputas.

Seis sistemas coordinados —cuatro de los cuales todavía no existen en producción— para responder una sola pregunta: ¿esta compra concreta estaba dentro de la autoridad que el humano concedió?

Hay una consecuencia de segundo orden que casi nadie menciona. EMVCo dice que la intención debe gestionarse también después de la transacción, cubriendo la «actividad posterior». Un registro persistente de qué instruyó el consumidor, cuándo y por cuánto tiempo es, entre otras cosas, prueba. Va a terminar dentro de las disputas. Es decir: el efecto más probable a corto plazo de la capa de intención sobre los comercios no es que las compras agénticas con tarjeta dejen de ser reversibles, sino que revertirlas venga con un expediente más gordo. Escribimos sobre quién se queda con ese muerto en contracargos en el comercio agéntico.

Nada de esto convierte a EMVCo en el equivocado. Si los agentes van a comprar vuelos y comida con el crédito de una persona, esa maquinaria tiene que existir de verdad. El punto es más estrecho y más útil: ese es el precio de que el pago siga siendo un pull.

Por qué un pago push no necesita registro de intención

Ahora corré el mismo mandato de 300 dólares de supermercado sobre una wallet en vez de una tarjeta.

La persona fondea la wallet del agente con 300 USDC. El agente sale a comprar. Cada compra es un push: el agente firma un pago por un importe concreto a una dirección concreta y se liquida on-chain. El cuarto pedido que rompía el mandato no necesita que lo atrape ningún registro: si excede lo que queda, no hay con qué firmar. El presupuesto restante no es un número en una base de datos compartida que cuatro partes tienen que consensuar. El presupuesto restante es el saldo.

Esta es la diferencia que el borrador de EMVCo está rodeando sin nombrarla. Una credencial puede probar que un mandato existió. No puede decirte cuánto queda, porque el dinero no está ahí. Una wallet solo puede decirte cuánto queda, porque eso es lo único que una wallet es.

La misma propiedad aparece un nivel más abajo, donde en realidad vive la mayor parte del tráfico de agentes: pagar una llamada a una API. El protocolo x402 revive el código HTTP 402 Payment Required, que llevaba décadas dormido. El servidor responde a una petición sin pagar con un 402 que cotiza el precio de ese recurso exacto. El agente firma un pago por exactamente ese importe y reintenta. La petición pasa.

No hay estado de mandato que consultar, porque el alcance de la autoridad es el importe firmado, y se gasta en el mismo gesto en que se concede. No queda ningún «¿debería?» para que lo resuelva un emisor, porque a nadie se le está pidiendo que adelante nada. No hay ciclo de vida posterior, porque la transacción no tiene cola. Por eso insistimos en que la división del comercio agéntico es registro primero frente a pago primero, y en que esa línea coincide casi exactamente con bienes de consumo frente a servicios de máquina.

Cómo dejar que los agentes de IA paguen tu API hoy, paso a paso

El rol de Payzum acá es específico y conviene decirlo con precisión: somos el middleware/proxy delante de tu API, no el facilitator. La liquidación del pago pasa por un facilitator externo (hoy el de Coinbase). Lo que Payzum elimina es la parte en la que vos tenés que implementar un protocolo de pagos.

1. Configurás el endpoint. En el panel de Payzum apuntás al endpoint de API que ya tenés en producción y pegás la API key o el bearer token que espera. De tu lado no cambia nada: sin SDK, sin middleware en tu stack, sin protocolo que implementar.
2. Ponés un precio por llamada. Denominado en USDC. Distintas rutas pueden tener distintos precios, que es como fijan precio los vendedores con ingresos reales de agentes: lecturas baratas, cómputo caro.
3. Payzum publica una URL x402. El agente la llama, recibe el 402 con el precio, firma un pago en USDC sobre Base y reintenta. La liquidación se gestiona a través del facilitator externo y los fondos caen directo en la wallet que vos controlás: Payzum nunca los retiene.
4. Payzum hace de proxy de la llamada pagada. Una vez confirmado el pago, la petición se reenvía a tu endpoint real con tu key, y tu respuesta vuelve al agente. Desde tu servidor es una petición autenticada normal y corriente.

El pricing del lado agéntico ronda las ~1.000 transacciones al mes gratis y luego ~0,001 USD por transacción más gas. // confirmar pricing actual

Todo es configuración de panel. Un proveedor de API puede quedar cobrable por agentes el mismo día, que es el argumento entero de este artículo comprimido en una frase. Para el recorrido largo mirá dejá que los agentes de IA paguen tu API y x402: pago por llamada a la API.

A quién le cambia algo esto de verdad

Tres lecturas concretas del borrador del 1 de septiembre, según qué vendas.

• Vendés una API, un dataset, un endpoint de modelo o una herramienta MCP. No sos participante de los Intent Services: estás aguas abajo. Nada del marco es una tarea en tu roadmap, y nada del marco te bloquea tampoco. Tu cuello de botella es tener un endpoint que un agente pueda pagar sin que un humano abra una cuenta. Eso es un cambio de configuración, no un proceso de estandarización.
• Tenés un SaaS o una plataforma de desarrolladores con consumo medido. La pregunta interesante que te deja el borrador es la de los presupuestos acumulados, justo aquello para lo que hace falta un registro. Sobre una wallet lo tenés gratis: el agente de tu cliente fondea una wallet, la va gastando por llamada y la recarga. Sin ciclo de vida de mandato, sin gestión de impagos, sin tarjeta vencida matando una suscripción a mitad de mes. Y si además vendés a humanos, las suscripciones, el checkout alojado, los links de pago y las facturas corren sobre la misma liquidación sin custodia.
• Vendés productos físicos a consumidores. Acá el rail que importa es el de la tarjeta y sí conviene leer el marco, pero leelo por lo que le hace a tu exposición a disputas, no a tus ingresos. Mientras tanto, los clientes que ya tienen stablecoins pueden pagarte de forma final e irreversible hoy, online o en el mostrador con POS de QR por venta y cajeros con PIN.

Registro de intención vs. pago firmado: la comparativa

Las objeciones honestas

«Estás comparando un borrador de estándar con un producto; obvio que el producto llega antes.»

Es justo, y conviene concederlo limpio: EMVCo está haciendo exactamente el trabajo que le toca. Las tarjetas son casi universales; los agentes pagando en stablecoins no. Si el comercio agéntico de consumo va a ser seguro sobre rails de crédito, una capa de intención interoperable es mejor que doce propietarias, y EMVCo es el único organismo en posición de escribirla. Quien despache el marco como burocracia no está prestando atención.

El argumento acá no es que el carril de la tarjeta esté equivocado. Es que los dos carriles responden preguntas distintas para bienes distintos, y a quien vende servicios de máquina le están diciendo que espere la solución a un problema que no tiene. Nada de Framework for Specifications v1.0 se convierte en ingresos para un proveedor de API, y el plazo entre un marco de EMVCo y una realidad visible para el comercio está documentado por todas las especificaciones anteriores del organismo.

«La finalidad on-chain significa que un agente que se equivoca no se puede deshacer. Eso es peor.»

Para compras de consumo con expectativa de devolución es un costo real, y no vamos a fingir lo contrario. Si un agente compra lo que no era con una tarjeta, el proceso de disputa existe para deshacerlo; on-chain el pago es final y el recurso es la política de devoluciones del vendedor. Los topes de gasto del lado del agente y el modelo de wallet fondeada limitan el radio de daño, pero no recrean un contracargo.

Lo que sí discutimos es aplicar ese marco a pagos de máquina de menos de un dólar. Nadie disputa una llamada de API de 0,002 USD: el costo de la disputa supera a la transacción en tres órdenes de magnitud. La reversibilidad es una función que pagás en cada transacción la uses o no, y para el comercio por llamada entre máquinas es puro sobrecosto. Elegí el rail que le corresponde al bien.

«¿No puedo usar una tarjeta virtual para mi agente y listo?»

Podés, y muchos equipos lo hacen; comparamos los enfoques en tarjetas virtuales para agentes de IA vs. x402. La versión corta: las tarjetas virtuales te dan controles familiares y reversibilidad, con economía de tarjeta y un piso por transacción que hace imposible cobrar fracciones de centavo, y encima dejan al vendedor haciendo onboarding estilo tarjeta. Ese es justamente el intercambio que el marco de EMVCo intenta mejorar — para los compradores, no para los vendedores.