Visa Intelligent Commerce is best understood as a set of trust primitives around existing card payments, not as a new rail. The public Visa material describes AI agents that can search, select, and purchase with user-defined preferences, tokenized credentials, passkeys, and merchant-visible trust signals.
The safest architecture map is therefore three-layered:
- VIC handles the consumer, tokenized credential, passkey, and agent-payment lifecycle.
- TAP handles agent identity and request integrity at the HTTP layer.
- The card network still carries authorization, clearing, disputes, and settlement through existing participants.
The first two layers are public enough to discuss concretely. The third should be discussed carefully, because Visa has not published a complete field-level VisaNet mapping for agentic transactions.
- enroll card
- create scoped instruction
- retrieve tokenized credential
- record outcome
- Ed25519 key
- RFC 9421 signature
- nonce check
- edge verdict
- device ID
- IP address
- email hash
- AVS billing data
The public sources support tokenized credentials and richer authorization context, but they do not publish exact ISO 8583 fields, private data elements, or response-code rules for agentic transactions.
System 1: VIC
Visa’s public VIC material describes a lifecycle for agentic payments:
- A consumer opts into agentic commerce.
- The payment credential is tokenized rather than exposing the underlying PAN.
- Strong authentication, including passkeys, can bind the consumer to enrollment or purchase authorization.
- The agent receives enough credential context to complete the authorized checkout.
- The outcome can be tied back to the original instruction for audit, risk, and support.
That design keeps the AI reasoning layer away from the raw payment credential. The agent can decide what to buy, but the payment system decides whether a credential should be released for that merchant, amount, consumer, and policy.
consumer preference + passkey
|
v
VIC instruction / mandate
|
v
agent-bound tokenized credential
|
v
merchant checkout and ordinary card authorizationSystem 2: TAP
TAP answers a different question: did this request come from a registered agent, and did the signed request change in transit?
Visa and Cloudflare’s public descriptions line up with RFC 9421 HTTP Message Signatures. The agent signs request components. The verifier checks the public key, timestamp, nonce, tag, signature base, and cryptographic signature. Cloudflare’s write-up says Visa TAP and Mastercard Agent Pay both build on Web Bot Auth and let merchants distinguish legitimate approved agents from malicious bots.
The public material supports these statements:
- TAP was unveiled by Visa on October 14, 2025.
- Visa developed TAP in collaboration with Cloudflare.
- TAP uses HTTP Message Signatures and registered public keys.
- Agent requests include freshness and replay controls such as timestamps and nonces.
- The request can carry intent, such as browsing versus purchasing.
The public material does not support hard-coded production claims such as a specific Visa registry path, a required bearer-credential lifetime, or a fixed millisecond verification budget. Those are implementation-shaped examples, not facts to present as Visa specifications.
Extract covered components and signing base.
Read the registered public key for the signing key id.
fresh within verifier policy
not seen before
@authority matches Host
Ed25519.verify(sig, base)
Forward an implementation-specific agent trust result to origin.
System 3: existing payment rails
The strongest part of the architecture is compatibility. The merchant still uses a checkout flow, the acquirer still submits an authorization, the network still routes it, and the issuer still approves or declines. Agentic commerce adds evidence around the payment rather than throwing out the payment stack.
The evidence can include:
- Agent identity from TAP or a similar signed-request protocol.
- A tokenized credential from the card network or issuer ecosystem.
- A consumer-authorized instruction, mandate, or spending policy.
- Merchant, amount, category, and timing context.
- Post-purchase evidence useful for dispute handling.
Public Visa sources do not publish the exact ISO 8583 fields and values used for all of this. It is reasonable to talk about additional data fields, private-use fields, tokenization fields, and authorization metadata. It is risky to state exact field numbers, exact response codes, or exact issuer behavior unless Visa has published them.
Issuer step-up, spending controls, agent-bound token reference.
FIDO2 credential stays in the secure enclave.
Passkey assertion creates a scoped payment instruction for merchant, amount, and item.
Signed HTTP request is verified at the edge before merchant origin.
Merchant receives tokenized credential (VCN) and enriched DCAP authorization context.
Tokenized credential and agent context travel as network-specific authorization metadata.
Issuer evaluates agent credential and mandate evidence; pre-authorized agent instructions may follow a low-friction path.
Order outcome feeds dispute evidence and fraud intelligence.
agent-bound VCNThe PAN field carries a network token (VCN) rather than the real account number. Merchant and acquirer never see the underlying PAN.
network-specificIllustrates that downstream systems may need a way to select agent-specific risk rules.
agent identity + enriched contextMay carry agent and transaction evidence where the network implementation permits it.
implementation-specificConceptually binds authorization to a consumer-authorized instruction without claiming a public field number.
00 = approved / decline codeIssuer returns a two-character response code (00 for approval). Agent-specific decline codes for mandate violations are not publicly specified.
What is verified versus illustrative
Verified public facts
- Visa announced VIC in April 2025.
- Visa unveiled TAP on October 14, 2025.
- TAP was developed with Cloudflare.
- The TAP reference repository includes an agent, merchant frontend/backend, CDN proxy, and agent registry.
- TAP uses HTTP Message Signatures concepts, including signed request components, timestamps, key identifiers, algorithms, and session identifiers.
- Cloudflare describes Web Bot Auth checks including signature headers, key lookup, timestamp, nonce, tag, canonical signature base, and Ed25519 verification.
Architecture inferences
- Agentic card payments need a way to pass agent context into authorization and risk systems.
- Tokenized credentials and registered instructions are the natural bridge between the HTTP identity layer and the payment rail.
- Merchant, PSP, network, and issuer implementations will differ until the field-level standards are public and broadly adopted.
Illustrative only
- Any exact ISO 8583 field value for “agent-initiated.”
- Any exact private data element carrying a TAP instruction reference.
- Any exact VisaNet validation latency, response code, or issuer policy rule.
- Any claim that every Visa merchant can accept agent payments without integration work today.
Integration paths
There are three practical paths, with different control tradeoffs.
Direct Visa integration. Best for agent platforms that need control over enrollment, tokenization, instruction creation, request signing, and merchant partnerships.
Visa examples and MCP-style tooling. Visa’s public AI repository includes VIC examples, documentation MCP references, tokenization demos, and passkey-oriented flows. That is useful developer scaffolding, but it should not be described as universal production payment access for any chatbot.
Platform or PSP integration. Merchants and agent builders may adopt agentic commerce through PSPs, cloud edge providers, wallets, or checkout platforms. This path will likely be more common than every merchant integrating directly with a card network.
What VIC does not solve by itself
Prompt injection. VIC and TAP can verify requests and credentials. They do not prove the agent’s browsing decision was immune to manipulation.
Multi-agent delegation. Public specs do not yet define a universal way to propagate authority from a supervising agent to a checkout subagent across networks.
Cross-network identity. Visa TAP, Mastercard Agent Pay, AP2, ACP, and x402 use overlapping but different trust models. Shared agent identity is still an ecosystem problem.
Public field-level specification. The biggest documentation gap is still the handoff from agent identity and mandate evidence into authorization, clearing, disputes, and issuer servicing.
Related Reading
The transaction narrative is in How an AI agent buys something. The protocol competition across TAP, Mastercard Agent Pay, AP2, ACP, and x402 is in The agentic payment stack nobody is mapping.