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 AgenticMCPStores integra ambas redes de tarjetas mediante adaptadores especificos, 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 mayoria de los consumidores siguen pagando con Visa y Mastercard. Para que el comercio agentico alcance adopcion masiva, los agentes necesitan interactuar con las redes de tarjetas — de forma segura, con consentimiento del consumidor, y sin manejar numeros de tarjeta en bruto. Visa Intelligent Commerce (VIC) y Mastercard Agent Pay (MCAP) son los dos protocolos de redes de tarjetas disenados especificamente para este caso de uso.

VIC es la integracion directa via API de Visa para pagos agenticos. El agente crea una instruccion 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 criptograficas: (1) Autenticacion JWE — firma RS256 + cifrado RSA-OAEP-256 con cache stale-while-revalidate (TTL 3600s, auto-renovacion 60s antes de expiracion). (2) X-Pay HMAC — verificacion 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 liquidacion expone tres operaciones: createInstruction() — crea una instruccion de compra VIC con monto, moneda, codigo de categoria del comerciante (MCC), frecuencia (SINGLE o recurrente WEEKLY/MONTHLY), y direccion de envio. retrieveAndConfirm() — obtiene credenciales de pago de VIC sin exponer datos de la tarjeta, luego confirma el evento de transaccion. cancelInstruction() — cancela una instruccion de compra activa. Todas las operaciones usan retry con backoff exponencial (max 3 intentos: 2s, 4s, 8s) y proteccion circuit breaker para resiliencia.

MCAP toma el enfoque opuesto a VIC. En lugar de una integracion directa via API con criptografia multicapa, MCAP usa un modelo pass-through via Stripe sin codigo 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 estandar a traves de los rieles existentes de Stripe. La complejidad se traslada a la verificacion de identidad del agente y la gestion 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, valida la firma Ed25519 contra la clave publica 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 periodo de gracia de 24 horas para transiciones suaves.

El servicio de consentimiento de MCAP valida cada transaccion contra el alcance de consentimiento del consumidor — monto maximo por periodo, codigos de categoria del comerciante (MCCs) permitidos, IDs de comerciante especificos, y ventanas de tiempo. El seguimiento de uso acumulado usa bloqueo optimista (condicion WHERE updatedAt) para seguridad en concurrencia. Los periodos 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 liquidacion. VIC es bidireccional (adaptadores inbound + outbound); MCAP es solo inbound ya que la liquidacion 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 inscripcion 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 politicas KYAI unificado para limites de gasto, verificacion de comerciante y scoring de confianza del agente antes de la liquidacion.

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 estandarizados UCP, AgenticMCPStores ofrece la cobertura de pago mas completa en comercio agentico. Los comerciantes configuran sus protocolos preferidos una vez; el Protocol Router maneja la deteccion y el ruteo automaticamente.

VIC (spec 014) esta completo con 200+ tests en 14 archivos de test cubriendo deteccion de adaptador, cliente API, flujo de liquidacion, cripto MLE/JWE, token manager, circuit breaker, analytics, inscripcion, mandatos recurrentes, schemas y validacion de config. Actualmente en sandbox esperando credenciales de produccion de Visa (bloqueador externo). MCAP (spec 017) esta completo con 78 tests en 6 archivos cubriendo deteccion de adaptador, verificacion de firmas RFC 9421, validacion de consentimiento, cache de nonce, schemas e integracion. MCAP esta habilitado en produccion (Railway MCAP_ENABLED=true). Ambos specs estan completamente implementados — la unica dependencia restante es la emision de credenciales de produccion de Visa para VIC.