Building Agentic Commerce #7: Card Network Adapters for Visa VIC & Mastercard Agent Pay

AI agents can search products, compare prices, and build carts across protocols like MCP, ACP, and A2A. But when it's time to pay, the agent needs access to real payment rails: Visa, Mastercard, the networks that process 80% of global card transactions. This post covers how Trusteed integrates both card networks through purpose-built adapters, giving agents tokenized payment access without ever exposing card data.

Stablecoin payments (x402) and protocol-native checkout (ACP, UCP) work well for crypto-native and platform-native flows. But most consumers still pay with Visa and Mastercard. For agentic commerce to reach mainstream adoption, agents need to interact with card networks: securely, with consumer consent, and without handling raw card numbers. Visa's Intelligent Commerce (VIC) and Mastercard's Agent Pay (MCAP) are the two card network protocols designed specifically for this use case.

VIC is Visa's direct API integration for agentic payments. The agent creates a purchase instruction with amount, currency, and merchant details. Visa's backend tokenizes the card via VTS (Visa Tokenization Service), binds it to the consumer's FIDO-enrolled device, and returns payment credentials: never exposing card data to the agent or merchant backend.

VIC's security model uses four cryptographic layers: (1) JWE token authentication: RS256 signing + RSA-OAEP-256 encryption with stale-while-revalidate caching (3600s TTL, auto-refresh 60s before expiry). (2) X-Pay HMAC: request-level integrity verification. (3) Message-Level Encryption (MLE): RSA-OAEP-256 key wrapping + A128GCM content encryption for payload confidentiality. (4) HTTPS: transport-level encryption. This means every VIC API call is signed, encrypted at message level, and transmitted over TLS: defense in depth against man-in-the-middle, replay, and data exfiltration attacks.

The settlement service exposes three operations: createInstruction(): creates a VIC purchase instruction with amount, currency, merchant category code (MCC), frequency (SINGLE or recurring WEEKLY/MONTHLY), and shipping address. retrieveAndConfirm(): obtains payment credentials from VIC without exposing card data, then confirms the transaction event. cancelInstruction(): cancels an active purchase instruction. All operations use exponential backoff retry (max 3 attempts: 2s, 4s, 8s delays) and circuit breaker protection for resilience.

MCAP takes the opposite approach to VIC. Instead of a direct API integration with multi-layer cryptography, the design centres on agent identity verification and consumer consent management, with the Agentic Token (a 16-digit network token) as the payment credential. Correction 2026-10-11: an earlier version of this article described an automatic settlement path through Stripe for any merchant with Stripe enabled. That path does not exist: there is no Mastercard settlement integration, so Mastercard Agent Pay is not available and no payment is attempted through it. The inbound HTTP Message Signatures adapter only runs where an operator has set MCAP_ENABLED=true; settlement is not offered.

MCAP verifies agent identity using HTTP Message Signatures per RFC 9421 with Ed25519 keys. Every payment request includes Signature-Input and Signature headers with tag='agent-payer-auth'. The signature service parses the input header, extracts keyid/created/expires/nonce/alg, validates the Ed25519 signature against the agent's public key, enforces clock skew tolerance (plus or minus 30 seconds), and prevents replay attacks via a nonce cache with 5-minute TTL. Key rotation is supported with a 24-hour grace period for smooth transitions.

MCAP's consent service validates every transaction against the consumer's consent scope: maximum amount per period, allowed merchant category codes (MCCs), specific merchant IDs, and time windows. Accumulated usage tracking uses optimistic locking (WHERE updatedAt condition) for concurrent safety. Consent periods (DAILY, WEEKLY, MONTHLY) auto-reset when expired. Consumers can revoke consent at any time with immediate effect, ensuring the consumer always maintains control over their agent's spending authority.

Both VIC and MCAP feed into the same AgentPaymentIntent model, the platform's universal payment abstraction. The Protocol Router detects the incoming protocol via headers (X-Protocol: VIC or Signature-Input with agent-payer-auth tag), normalizes the request through the respective inbound adapter, and routes it to the settlement service. VIC is bidirectional (inbound + outbound adapters); MCAP is inbound-only since settlement happens via Stripe. Both adapters implement the IProtocolAdapter interface (detect, normalize, translate, healthCheck) and register in the PluginRegistry at server startup.

VIC is never auto-selected as a fallback: it requires active consumer enrollment and an explicit X-Protocol: VIC header. If the header is detected but the consumer is not enrolled, the request fails with a clear error. MCAP has zero fallback friction: if a merchant has Stripe configured, MCAP payment requests are accepted automatically. Both protocols pass through the unified KYAI policy engine for spending limits, merchant verification, and agent trust scoring before settlement.

Together, VIC and MCAP provide coverage for approximately 2 billion tokenized cards globally: Visa's 1B+ and Mastercard's 1B+ cardholders. Combined with x402 stablecoin payments, ACP protocol-native checkout, and UCP standardized flows, Trusteed handles all of them through one integration. Merchants configure their preferred protocols once. The Protocol Router handles detection and routing automatically.

VIC (spec 014) is complete with 200+ tests across 14 test files covering adapter detection, API client, settlement flow, MLE/JWE crypto, token manager, circuit breaker, analytics, enrollment, recurring mandates, schemas, and config validation. Currently in sandbox awaiting Visa production credentials (external blocker). MCAP (spec 017) is complete with 78 tests across 6 files covering adapter detection, RFC 9421 signature verification, consent validation, nonce cache, schemas, and integration. MCAP is enabled in production (Railway MCAP_ENABLED=true). Both specs are fully implemented: the only remaining dependency is Visa's production credential issuance for VIC.