Contracargos en el comercio agéntico: quién paga cuando la IA compra mal

La noticia: el comercio agéntico está construyendo su capa de evidencia porque no tiene ninguna

El 13 de julio de 2026, una empresa llamada A-Comm Technologies abrió a consulta pública un borrador de estándar que casi nadie fuera del mundo de pagos registró, y dice más sobre el estado real del comercio agéntico que la mayoría de los lanzamientos del año. El A-Comm Evidence Protocol es una especificación abierta, con licencia Apache 2.0, para dejar constancia de lo que hizo un agente de IA durante una transacción —del descubrimiento hasta el cumplimiento— en un formato inalterable que cualquiera puede exportar y verificar por su cuenta. La consulta está abierta hasta el 14 de agosto de 2026.

Mirá quién está detrás y deja de parecer un proyecto lateral. A-Comm fue fundada por ex líderes de pagos de Visa, con inversión ángel de ejecutivos de Visa, Mastercard, American Express, SoFi, Citigroup, Wells Fargo y Qualcomm. Su CEO, Krystal Gracier, lo planteó sin vueltas: "Para que el comercio agéntico escale, tiene que ser observable, trazable y auditable. Ninguna empresa sola puede construir un ecosistema de confianza".

El mismo anuncio cita a Salesforce atribuyendo a la IA influencia sobre el 20% de las ventas online globales en 2025, y espera que las transacciones iniciadas por agentes lleguen a escala de pago real durante la temporada alta del comercio minorista —el tramo que genera cerca del 19% de la facturación anual—.

Ahora la parte que conviene masticar. El checkout humano nunca necesitó un protocolo de evidencia. A nadie se le ocurrió estandarizar cómo probar que una persona hizo clic en "comprar". Se está redactando uno recién ahora porque, cuando el comprador es software, toda la cadena de prueba sobre la que corren las disputas de tarjeta deja de funcionar en silencio. Y la industria lo sabe.

Cuánto te cuesta hoy una compra agéntica disputada

Arranquemos por la mecánica de un contracargo normal. El titular de la tarjeta desconoce un cargo, el emisor le pide al comercio evidencia convincente, y el comercio arma el rastro digital de una sesión humana: IP, huella de dispositivo, recorrido de navegación, tiempo en el sitio, confirmación de entrega. Ese paquete es lo que convence al emisor de que esta persona, en este dispositivo, hizo esta compra.

Ahora delegá la compra en un agente. Todas esas señales pasan a generarse en la infraestructura del agente en vez de en el cliente, mientras el emisor sigue esperando un vínculo limpio entre titular y transacción. Al comercio le piden probar algo que la arquitectura nueva directamente ya no registra.

Debajo hay una pregunta legal sin resolver: ¿la transacción estaba autorizada? Si alguien le dice a su agente "buscá la mejor oferta en zapatillas y compralas" y el agente compra el par equivocado, la práctica de disputas no tiene respuesta consolidada sobre si eso fue autorizado —y todo el proceso gira sobre esa única palabra—. A 2026 ninguna jurisdicción sancionó reglas escritas específicamente para la compra autónoma.

La industria tampoco se pone de acuerdo sobre quién debería pagar. Encuestas difundidas por firmas de gestión de disputas ponen cerca del 39% de las respuestas en el proveedor de IA, 20% en el cliente, 14% en el comercio o la plataforma, 11% en el banco o procesador y 15% en algún modelo compartido. Cuando la opinión se parte así de parejo, significa que el marco todavía se está escribiendo —y mientras tanto, sin una protección específica de la red, la responsabilidad tiende a caer por defecto en el comercio—. Datos Insights proyecta que el volumen global de contracargos crecerá alrededor de 24% entre 2025 y 2028, hasta unos 324 millones de disputas anuales, y el volumen agéntico se suma a eso, no lo reemplaza.

Las redes se están moviendo, pero a medias. American Express presentó a comienzos de 2026 un kit de desarrollo agéntico junto con el compromiso de cubrir compras erróneas hechas por agentes registrados en su red. El Trusted Agent Protocol de Visa y Agent Pay de Mastercard construyen marcos de identidad para agentes. Todo eso resuelve quién es el agente y cómo se comporta al autorizar; no resuelve qué pasa semanas después, cuando alguien impugna el cargo.

Los reguladores, en cambio, ya eligieron un lado en materia de responsabilidad. La CMA británica publicó una guía el 9 de marzo de 2026 que establece que la ley de consumo aplica igual si el cliente trata con una persona o con un agente de IA, que las empresas responden por la conducta de sus agentes como responden por la de sus empleados, y que eso vale incluso si un tercero diseñó o proveyó el sistema. Bajo la DMCC Act, las infracciones pueden llegar a multas de hasta el 10% de la facturación mundial. Su formulación es directa: "si un agente de IA que usás hace algo ilegal, sos responsable".

Por qué los rieles de tarjeta no pueden producir esa evidencia solos

Es tentador leer el vacío de evidencia como un descuido de ingeniería: logs que alguien se olvidó de escribir. No lo es. Es la consecuencia directa de cómo funciona el pago con tarjeta.

Una autorización de tarjeta es una promesa, no un hecho. El dinero se mueve días después y, durante meses, puede volver atrás. Esa reversibilidad es el producto: es lo que permitió que desconocidos transaccionaran online antes de que existiera alguna forma de liquidar valor con finalidad. Pero una promesa hay que juzgarla, y juzgar requiere evidencia. Así fue como el sistema de tarjetas desarrolló un aparato enorme —representaciones, reglas de evidencia convincente, traslados de responsabilidad, ventanas de disputa— cuyo trabajo completo es reconstruir después si un pago debía sostenerse o no.

Ese aparato descansa sobre un supuesto: que una persona autorizó el pago y que quedan rastros de esa persona. Meté un tercero autónomo entre el humano y el checkout y el supuesto se cae. La respuesta —un protocolo de evidencia, registros de agentes, marcos de agente confiable— es un intento de reconstruir la prueba faltante al costado de un riel que estructuralmente no puede generarla. Los especialistas en disputas fueron francos sobre el hueco: las redes anuncian marcos de identidad y pilotos en vivo mientras la plomería post-transacción para asignar responsabilidad sin comprador humano sigue casi sin atender.

Ahora mirá la misma transacción en un riel con finalidad de liquidación. Un agente paga USDC en Base por una llamada a tu API. El pago ocurrió o no ocurrió. Liquidó en una billetera que controla el comercio, en unos dos segundos, y dejó un registro público, con marca de tiempo y firmado criptográficamente, que muestra exactamente qué dirección pagó qué monto a qué dirección, por qué solicitud. Nadie tiene que reconstruir intenciones meses más tarde, porque nada se puede deshacer meses más tarde.

Esto no es afirmar que el pago on-chain contesta todas las preguntas que aborda un estándar como AEP. Si el agente compró lo correcto es una cuestión de producto y de consentimiento, y merece el trabajo que le están dedicando. Pero el problema puntual que le cuesta plata a un comercio —que un pago ya liquidado se dé vuelta y encima tengas que probar algo sobre un comprador que nunca fue humano— sencillamente no aparece. Es el mismo argumento estructural que hicimos con las suscripciones que mueren por contracargo y con las tarjetas virtuales emitidas a agentes: poner un agente detrás de un instrumento reversible hereda todos los problemas del instrumento.

Cómo lo resuelve Payzum: el pago es el recibo

Payzum es un procesador de pagos cripto no-custodial. Los fondos van derecho a billeteras que controla el comercio: Payzum nunca los retiene, agrupa ni mueve. Esa sola decisión de diseño hace casi todo el trabajo en esta discusión, y vale la pena explicitar qué implica para los pagos de agentes.

La finalidad reemplaza al juicio. Cuando un agente paga una de tus llamadas de API en USDC sobre Base, el pago está on-chain y liquidado. No hay ventana de disputa, ni ciclo de representación, ni paquete de evidencia que armar, ni un emisor decidiendo meses después si tu negocio se queda con el dinero. Los reembolsos siguen siendo perfectamente posibles —devolvés fondos cuando considerás que corresponde—, pero son una decisión comercial tuya, no una reversión que te imponen.

La liquidación es verificable por cualquiera. Acá está el solapamiento silencioso con lo que persigue el trabajo de estándares. Un pago on-chain es observable (existe en un libro público), trazable (una dirección pagadora concreta financió una solicitud concreta en un bloque concreto) y auditable por cualquier parte sin pedirle permiso a una red ni a un procesador. Payzum no implementa AEP, y nadie debería afirmar que la liquidación on-chain resuelve todo lo que cubre ese estándar; pero el problema de prueba del lado del comercio —"¿podés mostrar que este pago ocurrió y no se revirtió?"— lo contesta el riel mismo.

Tu propia capa de auditoría va arriba. Payzum incluye webhooks firmados, API keys, secretos encriptados, 2FA y un audit log completo, de modo que el registro dentro de tus sistemas coincida con el registro on-chain. Para conciliación y control interno, ese par —un evento firmado que recibiste más una transacción que cualquiera puede consultar— es un rastro más fuerte que el que produce la mayoría de las integraciones con tarjeta.

Y la pregunta por la volatilidad tiene una respuesta aburrida. La auto-conversión a USDC o USDT es opcional, así que el pago del agente puede aterrizar como stablecoin en dólares en vez de como algo que se mueve de un día para el otro.

Una precisión sobre la que somos insistentes, porque el ecosistema la equivoca todo el tiempo: en x402, Payzum es el middleware/proxy delante de tu API, no el facilitator. La liquidación del pago corre por un facilitator externo (hoy, el de Coinbase). Payzum publica la URL x402, devuelve el 402 y, una vez que el pago liquidó en tu billetera, hace de proxy reenviando la llamada pagada a tu endpoint real con tu key. El protocolo fue donado a la x402 Foundation de la Linux Foundation, y los datos de adopción son públicos —Chainalysis registró que los pagos agénticos en Base superaron los 100 millones de transacciones—, que es justamente el punto: esto es un riel abierto, no un libro contable privado.

Cómo lo configurarías, paso a paso

1. Se configura, no se programa. En el panel de Payzum apuntás a tu endpoint existente, pegás la API key o el bearer que ese endpoint ya espera, y ponés un precio por llamada. No hay protocolo que implementar ni cambios en tu servicio.
2. Payzum publica una URL x402. Un agente que la llama sin pagar recibe un HTTP 402 Payment Required con el precio y los datos de pago, en el formato que los clientes agénticos ya entienden.
3. El agente paga en USDC sobre Base. La liquidación corre por el facilitator externo y aterriza directo en tu billetera: Payzum nunca toma custodia. Las confirmaciones en Base rondan los dos segundos. Alrededor de 1.000 transacciones por mes gratis y después unos US$0,001 por transacción más gas. // confirmar pricing actual
4. Payzum reenvía la llamada pagada. Tu endpoint real se invoca con tu key, el agente recibe su respuesta, y vos te quedás con un webhook firmado y una entrada en el audit log —junto a una transacción on-chain que cualquiera puede verificar—. Un proveedor de API puede estar sirviendo agentes que pagan el mismo día que lo configura.

Dónde encaja esto en la práctica

El problema de evidencia y responsabilidad muerde más fuerte donde las transacciones son muchas, chicas y las inicia una máquina: exactamente la forma del tráfico agéntico. Casos concretos:

• Una API o proveedor de datos que cobra por consulta. Una API de precios, de enriquecimiento o geoespacial cobra unos centavos por llamada. En rieles de tarjeta, cada una de esas es una microtransacción sin autenticar que jamás te convendría defender en una disputa. Con x402, cada llamada es un pago en USDC ya liquidado en tu billetera, con recibo on-chain.
• Un servidor MCP o herramienta para agentes. Construiste una herramienta que los agentes llaman dentro de Claude u otro cliente. No hay sesión humana que perfilar, ni titular de tarjeta que autenticar, ni forma razonable de darle de alta una API key a cada agente. El pago por llamada elimina el registro por completo.
• Un medio o proveedor de investigación que tarifa el acceso de máquinas. En vez de bloquear crawlers o negociar licencias masivas, ponés precio por solicitud y dejás que los agentes paguen. El registro de pagos funciona además como tu log de acceso: quién pagó por qué.
• Un negocio que le vende a personas y a agentes. Las personas siguen comprando por checkout alojado, links de pago, facturas o suscripciones; los agentes pagan por llamada vía x402. Todo liquida sin custodia en la misma billetera, con auto-conversión opcional a USDC o USDT.

Compra agéntica con tarjeta vs. pagada on-chain

Objeciones razonables

"Si los pagos son finales, mis clientes se quedan sin recurso."

Tienen el recurso que vos les des, que para casi cualquier negocio es lo que ya pasa: reembolsás. La diferencia es quién tiene la decisión. En rieles de tarjeta un emisor puede revertir un pago ya liquidado sin tu acuerdo, meses después, y vos pagás un fee de disputa ganes o pierdas. Con liquidación final, un reembolso es un pago que enviás porque decidiste que el cliente tenía razón. Los buenos comercios reembolsan en los dos esquemas; solo en uno lo puede hacer un tercero por vos.

"Necesitamos rastro auditable para contabilidad, impuestos y control interno."

Tenés dos, y se cruzan entre sí: los webhooks firmados y el audit log completo de Payzum dentro de tus sistemas, y la transacción on-chain que cualquiera puede verificar sin pedirnos nada. Es una posición de conciliación más sólida que un resumen de procesador solo. El trabajo de estándares tipo AEP apunta a otra capa —probar intención y comportamiento del agente sobre rieles reversibles— y conviene seguirlo si vendés por canales agénticos basados en tarjeta. Esto no es asesoría legal ni contable; confirmá tus obligaciones de reporte.

"¿No sirve solo para APIs? Nosotros vendemos productos físicos."

Hoy x402 brilla en acceso digital por solicitud, que es donde está realmente el tráfico agéntico. Si le vendés a personas, las superficies relevantes de Payzum son el checkout alojado, los links de pago, las facturas con expiración y detección de sobrepago, o el POS presencial con un QR nuevo por venta. Misma liquidación no-custodial, misma ausencia de contracargos: otra puerta de entrada.