Building Agentic Commerce #7: Card Network Adapters — Visa VIC y Mastercard Agent Pay

Los agentes de IA pueden buscar productos, comparar precios y construir carritos a traves de protocolos como MCP, ACP y A2A. Pero cuando llega el momento de pagar, el agente necesita acceso a rieles de pago reales — Visa, Mastercard, las redes que procesan el 80% de las transacciones globales con tarjeta. Este post cubre como Trusteed integra ambas redes de tarjetas mediante adaptadores específicos, dando a los agentes acceso tokenizado sin exponer nunca los datos de la tarjeta.

Los pagos con stablecoins (x402) y el checkout nativo de protocolo (ACP, UCP) funcionan bien para flujos crypto-nativos y de plataforma. Pero la mayoría de los consumidores siguen pagando con Visa y Mastercard. Para que el comercio agéntico alcance adopción masiva, los agentes necesitan interactuar con las redes de tarjetas — de forma segura, con consentimiento del consumidor, y sin manejar números de tarjeta en bruto. Visa Intelligent Commerce (VIC) y Mastercard Agent Pay (MCAP) son los dos protocolos de redes de tarjetas diseñados específicamente para este caso de uso.

VIC es la integración directa via API de Visa para pagos agénticos. El agente crea una instrucción de compra con monto, moneda y datos del comerciante. El backend de Visa tokeniza la tarjeta via VTS (Visa Tokenization Service), la vincula al dispositivo FIDO del consumidor, y devuelve credenciales de pago — sin exponer nunca datos de la tarjeta al agente o al backend del comerciante.

El modelo de seguridad de VIC usa cuatro capas criptográficas: (1) Autenticacion JWE — firma RS256 + cifrado RSA-OAEP-256 con cache stale-while-revalidate (TTL 3600s, auto-renovacion 60s antes de expiración). (2) X-Pay HMAC — verificación de integridad a nivel de request. (3) Message-Level Encryption (MLE) — key wrapping RSA-OAEP-256 + cifrado de contenido A128GCM para confidencialidad del payload. (4) HTTPS — cifrado a nivel de transporte. Esto significa que cada llamada a la API de VIC esta firmada, cifrada a nivel de mensaje, y transmitida sobre TLS — defensa en profundidad contra ataques man-in-the-middle, replay y exfiltracion de datos.

El servicio de liquidación expone tres operaciones: createInstruction() — crea una instrucción de compra VIC con monto, moneda, código de categoría del comerciante (MCC), frecuencia (SINGLE o recurrente WEEKLY/MONTHLY), y dirección de envio. retrieveAndConfirm() — obtiene credenciales de pago de VIC sin exponer datos de la tarjeta, luego confirma el evento de transacción. cancelInstruction() — cancela una instrucción de compra activa. Todas las operaciones usan retry con backoff exponencial (max 3 intentos: 2s, 4s, 8s) y protección circuit breaker para resiliencia.

MCAP toma el enfoque opuesto a VIC. En lugar de una integración directa via API con criptografia multicapa, MCAP usa un modelo pass-through via Stripe sin código adicional. Si un comerciante ya tiene Stripe configurado, MCAP funciona automaticamente — el Agentic Token (un token de red de 16 digitos) se procesa como un token de tarjeta estándar a traves de los rieles existentes de Stripe. La complejidad se traslada a la verificación de identidad del agente y la gestión de consentimiento del consumidor.

MCAP verifica la identidad del agente usando HTTP Message Signatures segun RFC 9421 con claves Ed25519. Cada solicitud de pago incluye headers Signature-Input y Signature con tag='agent-payer-auth'. El servicio de firmas parsea el header de entrada, extrae keyid/created/expires/nonce/alg, válida la firma Ed25519 contra la clave pública del agente, aplica tolerancia de clock skew (mas o menos 30 segundos), y previene ataques de replay via cache de nonce con TTL de 5 minutos. La rotacion de claves esta soportada con un período de gracia de 24 horas para transiciones suaves.

El servicio de consentimiento de MCAP válida cada transacción contra el alcance de consentimiento del consumidor — monto máximo por período, códigos de categoría del comerciante (MCCs) permitidos, IDs de comerciante específicos, y ventanas de tiempo. El seguimiento de uso acumulado usa bloqueo optimista (condición WHERE updatedAt) para seguridad en concurrencia. Los períodos de consentimiento (DAILY, WEEKLY, MONTHLY) se reinician automaticamente al expirar. Los consumidores pueden revocar el consentimiento en cualquier momento con efecto inmediato, asegurando que el consumidor siempre mantiene control sobre la autoridad de gasto de su agente.

Tanto VIC como MCAP alimentan el mismo modelo AgentPaymentIntent — la abstraccion universal de pago de la plataforma. El Protocol Router detecta el protocolo entrante via headers (X-Protocol: VIC o Signature-Input con tag agent-payer-auth), normaliza la solicitud a traves del adaptador inbound respectivo, y la rutea al servicio de liquidación. VIC es bidireccional (adaptadores inbound + outbound); MCAP es solo inbound ya que la liquidación ocurre via Stripe. Ambos adaptadores implementan la interfaz IProtocolAdapter (detect, normalize, translate, healthCheck) y se registran en el PluginRegistry al iniciar el servidor.

VIC nunca se auto-selecciona como fallback — requiere inscripción activa del consumidor y un header explicito X-Protocol: VIC. Si el header se detecta pero el consumidor no esta inscrito, la solicitud falla con un error claro. MCAP tiene friccion cero de fallback — si un comerciante tiene Stripe configurado, las solicitudes de pago MCAP se aceptan automaticamente. Ambos protocolos pasan por el motor de políticas KYAI unificado para límites de gasto, verificación de comerciante y scoring de confianza del agente antes de la liquidación.

Juntos, VIC y MCAP proporcionan cobertura para aproximadamente 2 mil millones de tarjetas tokenizadas globalmente — los 1B+ de Visa y los 1B+ de Mastercard. Combinado con pagos stablecoin x402, checkout nativo ACP, y flujos estándarizados UCP, Trusteed ofrece la cobertura de pago mas completa en comercio agéntico. Los comerciantes configuran sus protocolos preferidos una vez; el Protocol Router maneja la detección y el ruteo automaticamente.

VIC (spec 014) esta completo con 200+ tests en 14 archivos de test cubriendo detección de adaptador, cliente API, flujo de liquidación, cripto MLE/JWE, token manager, circuit breaker, analytics, inscripción, mandatos recurrentes, schemas y validación de config. Actualmente en sandbox esperando credenciales de producción de Visa (bloqueador externo). MCAP (spec 017) esta completo con 78 tests en 6 archivos cubriendo detección de adaptador, verificación de firmas RFC 9421, validación de consentimiento, cache de nonce, schemas e integración. MCAP esta habilitado en producción (Railway MCAP_ENABLED=true). Ambos specs estan completamente implementados — la única dependencia restante es la emisión de credenciales de producción de Visa para VIC.