La brecha de confianza en el comercio agéntico: el 85% deja que la IA compare, el 10% que pague

Qué encontró de verdad el informe Signals de Mastercard

El 3 de agosto de 2026, Mastercard publicó un informe Signals titulado Encoding Trust: The Race for Intent, Consent and Control in the Agentic World. No es el lanzamiento de un producto ni de un protocolo: es investigación sobre las condiciones bajo las cuales el comercio agéntico escala, y sus números son más útiles que casi todos los lanzamientos del año.

Según la cobertura del informe, el apetito del consumidor se desploma en un punto exacto del embudo:

Lee las filas en orden y la forma es inconfundible. La gente no está rechazando la IA en el comercio — 85% es un número entusiasta. Está rechazando el gasto sin supervisión. La caída del 74% al 10% ocurre íntegramente en el momento en que la persona deja de ser quien le dice que sí al dinero.

La conclusión del propio informe es directa: el crecimiento «no vendrá impulsado por la autonomía en sí misma, sino por experiencias útiles que faciliten las decisiones cotidianas manteniendo a las personas informadas y en control». Viniendo de la compañía que construye Agent Pay, es algo notable de poner por escrito.

Hay otro hallazgo del mismo trabajo que conviene guardar: de unos 2.400 productos analizados en tiendas Shopify, solo el 11% tenía datos estructurados suficientes para que un agente de IA los reconociera y recomendara correctamente. Incluso donde el agente tiene permiso para actuar, casi todo el catálogo le resulta ilegible. Los compradores máquina necesitan ofertas legibles por máquina, y casi nadie publicó una.

El número debajo del número: B2B al triple del consumo

La proyección de portada del informe es de 3 a 5 billones de dólares de gasto de consumo asistido por agentes para 2030. La frase inmediatamente posterior es la que hay que releer: el gasto entre empresas se proyecta potencialmente en el triple.

Pon las dos cifras una al lado de la otra y la estrategia se cae sola. La mitad de consumo del comercio agéntico está topeada, por ahora, por un problema de permiso que ninguna cantidad de ingeniería resuelve del todo: no puedes programar tu salida de la resistencia de alguien a que un software gaste su dinero sin supervisión. La mitad más grande es el gasto empresarial, donde el comprador es una compañía, la aprobación ocurre una sola vez cuando se fija un presupuesto, y nadie necesita tranquilidad emocional para liberar $0,04 por una consulta de datos.

Ya tenemos evidencia de cómo se comporta cada mitad bajo carga. En marzo de 2026, OpenAI archivó Instant Checkout a menos de seis meses de lanzarlo, y pasó de «comprar dentro del chat» a «descubrir en el chat, transaccionar en el sitio del comercio». La compra dentro del chat retrocedió hacia la compra controlada por el consumidor: exactamente la brecha 74%/10%, expresada como decisión de producto.

Mientras tanto, la mitad máquina-a-máquina siguió componiendo. La semana del 17 de agosto de 2026 fue la más activa del año para x402: 8,7 millones de pagos de agentes, con un ticket promedio de unos cuatro centavos, según Token Terminal. Nadie encuestó a nadie sobre su nivel de comodidad. Los agentes tenían presupuesto, los endpoints tenían precio, y ocurrieron 8,7 millones de transacciones en siete días.

Por qué existe la capa de confianza — y qué está compensando

El remedio que propone el informe es una «capa de confianza» entre la decisión del agente y la ejecución del pago: antes de que el dinero se mueva, verifica quién actúa, qué autorizó el usuario y qué límites aplican, y mantiene un registro auditable de la actividad del agente. Los tokens agénticos pueden portar autoridad específica para una tarea, acotada por agente, comercio, categoría, tope de gasto, plazo o reglas de uso.

Es buen diseño y hace falta de verdad — en el riel para el que fue pensado. Vale la pena ser preciso sobre por qué hace falta ahí.

Un pago con tarjeta es una credencial que se presenta, no dinero que se entrega. La credencial funciona porque una red de reglas decide, después del hecho, si la presentación fue legítima — y la revierte si no. Esa arquitectura tiene un requisito estructural: alguien tiene que poder reconstruir, meses más tarde, si una persona autorizó la transacción. Cuando quien presenta la credencial es software, todos los insumos de los que depende el proceso de disputa — huella de dispositivo, IP, ruta de navegación, tiempo en página — pasan a generarlos un programa. Por eso la intención hay que capturarla, firmarla y guardarla aparte, por adelantado, en una capa nueva. Escribimos sobre el otro extremo del mismo problema cuando un grupo de la industria empezó a redactar un estándar de evidencia para transacciones de agentes, y sobre la propia vía de pagos-máquina de Mastercard este año.

Nada de esto es una crítica. Es la cantidad correcta de trabajo para rieles reversibles basados en credenciales. También es trabajo que tienen que adoptar plataformas de IA, bancos, comercios y redes al mismo tiempo para que signifique algo — por eso es un programa de varios años y no un interruptor. En América Latina, Mastercard ya completó transacciones agénticas en vivo en la región en marzo de 2026 integrando su capa de intención verificable: el rumbo es claro, el calendario de adopción masiva no.

Los pagos agénticos que ya funcionan no tienen consumidor adentro

Saca al consumidor de la transacción y cada punto de la lista de la capa de confianza o desaparece o se convierte en un campo de configuración.

• ¿Quién actúa? Un proceso que desplegó el propio equipo de ingeniería del comprador, con una wallet que fondeó su propio equipo de finanzas. No hay identidad que federar entre plataformas.
• ¿Qué autorizó el usuario? Un presupuesto, fijado antes de que la tarea arrancara. Ese es todo el evento de consentimiento, y ocurrió una sola vez.
• ¿Qué límites aplican? El saldo de la wallet del agente, más los topes por llamada y por período que imponga la plataforma. Un techo que no se puede exceder le gana a un permiso que hay que demostrar.
• ¿Hay registro auditable? La propia liquidación: con timestamp, verificable, y apuntando al endpoint exacto que se pagó.

Por eso las curvas de crecimiento divergen. El checkout agéntico de consumo espera un marco de confianza compartido entre cuatro industrias. Un agente comprando una consulta de datos no espera nada, salvo un endpoint que conteste con un precio.

Y esa última cláusula es el cuello de botella. Todos los anuncios del lado comprador de este año — nubes repartiendo wallets de agente, plataformas de gastos repartiendo wallets de agente, proveedores de modelos documentando cómo paga un agente — sumaron máquinas fondeadas buscando qué comprar. Ninguno sumó un vendedor. Hay millones de APIs comerciales, feeds, archivos y herramientas que todavía le contestan a una máquina con un formulario de registro, y para un agente con presupuesto en medio de una tarea, un formulario de registro es un callejón sin salida. No va a crear una cuenta. Se va a otro lado, o vuelve sin el dato.

Dónde encaja Payzum: middleware delante de tu API, no el facilitator

Aquí la precisión importa, porque los roles en x402 se confunden todo el tiempo. Payzum es el middleware/proxy que se sienta delante de tu API existente. Payzum no es el facilitator. La liquidación on-chain la maneja un facilitator externo — hoy el de Coinbase. Lo que Payzum elimina es la ingeniería que si no terminaría en tu roadmap: implementar el handshake 402, verificar el pago, protegerte de replay y reenviar la llamada pagada a tu servicio real.

Tú configuras el endpoint que ya corres, la API key o bearer token que ya espera, y un precio. Payzum publica una URL x402, contesta a los agentes con el 402 y las condiciones, espera la liquidación, y luego hace de proxy reenviando la llamada pagada a tu endpoint real con tu propia key y devolviendo la respuesta. x402 es un estándar HTTP abierto, hoy bajo gobernanza de la Linux Foundation: no estás adoptando el protocolo de un proveedor.

Los fondos son no-custodiales: USDC en Base aterriza directo en una wallet que controlas, con confirmaciones de unos dos segundos. Payzum nunca retiene, agrupa ni enruta tu dinero — la liquidación es el pago, lo que además significa que el pago es final cuando se sirve la llamada: sin contracargos, sin ventana de reversa, sin nada esperando uno a tres días en el balance de un procesador. El pricing sigue el uso: alrededor de 1.000 transacciones al mes gratis, luego unos $0,001 por transacción más gas. Tu servicio conserva su autenticación, sus rate limits y su pipeline de deploy. Si quieres la mecánica de liquidación en detalle, escribimos por qué USDC en Base encaja con el precio por request y cómo es el handshake de x402.

Cómo funciona, paso a paso

1. Conecta el endpoint que ya tienes. En el dashboard de Payzum pegas la URL de tu API existente y la key o bearer token que espera. Sin SDK, sin implementar protocolo, sin redeploy de tu servicio.
2. Define un precio y una wallet de destino. Eliges cuánto cuesta una llamada en USDC y la wallet en Base donde deben aterrizar los fondos. Como la liquidación es no-custodial, esa wallet es tuya desde el primer pago.
3. Payzum publica la URL x402. El agente que la golpea recibe un HTTP 402 con el precio y las condiciones — una oferta legible por máquina, justo lo que le faltaba al 89% de aquella muestra de Shopify — y paga en USDC. La liquidación se verifica a través de un facilitator externo.
4. La llamada pagada se te reenvía. Payzum manda el request a tu endpoint real con tu key y devuelve la respuesta dentro del mismo ciclo. Webhooks firmados, audit log completo, 2FA y secretos encriptados cubren cada llamada, y puedes ver la primera aterrizar desde el playground de integración y la API REST.

Dónde ya está pasando hoy

Tres formas concretas, todas B2B, todas fuera del techo del 10%:

• Un proveedor de datos con una cola larga que no puede vender. Una firma vende licencias corporativas de su feed de precios pero rechaza a todo el que queda debajo del mínimo de contrato. Publica esa misma consulta a tres centavos la llamada por x402. Agentes de research, bots de pricing y scripts puntuales pagan por consulta; nadie negocia, nadie firma, y el segmento que era antieconómico de facturar pasa a ser el que paga al instante.
• Una herramienta MCP que los agentes descubren en plena tarea. Una herramienta de geocodificación, enriquecimiento o parseo de documentos se expone a los runtimes de agentes. Cuando un agente la necesita, recibe un precio en vez de una pantalla de registro, paga de su presupuesto y obtiene la respuesta en el mismo ciclo. Primer ingreso de un comprador del que el proveedor nunca oyó hablar, sin onboarding alguno.
• Un proveedor de API en LATAM sin cuenta de cobro internacional. Un equipo en Buenos Aires, Bogotá o Ciudad de México factura en dólares pero no puede abrir con facilidad una cuenta de comercio en EE. UU., y su banco local le cobra spread y demoras por cada cobro del exterior. Los agentes, estén donde estén, pagan USDC en Base directo a la wallet del equipo — sin adquirente, sin comisiones cruzadas de tarjeta, sin reserva rodante, y sin ningún payout que puedan congelar, porque no hay saldo retenido en ningún lado que congelar.

Checkout agéntico de consumo vs. pagos entre máquinas

Objeciones que vale la pena tomarse en serio

«¿Entonces el comercio agéntico de consumo es un callejón sin salida?»

No, y esa sería la lectura equivocada. El 85% dice que los consumidores quieren agentes en el proceso de compra; el 10% dice que quieren conservar la decisión del pago. Las dos cosas pueden ser ciertas, y el trabajo de capa de confianza que hacen las redes es cómo ese segundo número eventualmente se mueve. El argumento de aquí es más acotado y es de secuencia: si vendes algo que una máquina puede consumir, puedes capturar ingresos de agentes ahora, sin esperar a que termine un programa de estandarización de cuatro industrias. Si le vendes zapatillas a personas, vas a seguir necesitando ese programa, y conviene que lo sigas de cerca.

«Nuestra API ya tiene API keys y facturación. ¿Para qué cambiar?»

No cambies nada. x402 es aditivo, no una migración: tus clientes actuales conservan sus keys, sus contratos y sus facturas. Lo que agrega una URL x402 es una segunda puerta para compradores que no pueden entrar por la primera: un proceso autónomo, en plena tarea, con presupuesto y sin capacidad de completar un registro, cargar una tarjeta o esperar un ciclo de compras. Hoy ese comprador ve una pantalla de login y se va. El cambio no es en tu modelo de facturación; es en tu mercado direccionable.

«¿No es riesgosa la liquidación final si algo sale mal?»

La finalidad corta para los dos lados, y conviene decirlo con honestidad. Tú no puedes recuperar un pago por la fuerza, y el comprador tampoco — por eso importa el precio por llamada: la unidad en riesgo, de cualquiera de los dos lados, son centavos y no un contrato mensual. Si necesitas dejar entero a un comprador, devuelves como un pago que tú inicias, en tus términos. Lo que la finalidad elimina es esa ventana de reversa de meses que es justamente la razón por la que un procesador convencional retiene reservas contra tu facturación.