You say “buy me those Bose headphones.” Your AI assistant does it. 1,100 milliseconds later, the purchase is confirmed — no checkout page, no card number entered, no CAPTCHA solved.
This already happened. In December 2025, a consumer dispatched an AI agent to find the best headphones at the best price. The agent evaluated options on Consumer Reports, navigated to Bose.com, authenticated itself using Skyfire’s KYAPay protocol and Visa’s Trusted Agent Protocol, and completed the checkout. The consumer received a confirmation email automatically.
This post breaks down every technical layer of what happened: the new identity protocol Visa and Cloudflare built, the exact changes to ISO 8583 for agent-initiated transactions, the VIC API sequence, and the competitive landscape across TAP, x402, and AP2.
Why this is genuinely hard
The payment industry has spent 50 years building fraud systems around one assumption: the entity initiating a transaction is a human being. Fraud signals — typing cadence, mouse movement, device fingerprinting, geolocation patterns — all rely on human behavioral baselines.
An AI agent destroys every one of those signals simultaneously. It moves at machine speed. It has no mouse. Its IP is a server in AWS us-east-1. Its device fingerprint looks like a headless Chrome instance. Its purchasing patterns are algorithmically optimal, which looks nothing like human impulse buying.
- Mouse trajectory and typing cadence
- DOM interaction timing
- Residential IP origin
- Organic conversion funnel timing
- Device fingerprint consistency
- Instantaneous programmatic requests
- No cursor or keystroke events
- AWS / GCP data center IP
- Headless browser fingerprint
- Algorithmically optimized patterns
From the perspective of every fraud system built since 2000, a legitimate AI agent shopping on your behalf is indistinguishable from a credential-stuffing attack. That’s the problem Visa’s Trusted Agent Protocol was built to solve.
The architecture: Visa Intelligent Commerce
Visa Intelligent Commerce (VIC), launched April 2025, is Visa’s complete infrastructure stack for agentic payments. Five API modules, each solving a different part of the problem.
Visa published an open-source MCP server at github.com/visa/mcp — any Claude or GPT-based agent can trigger a complete VIC payment through a standard MCP tool call, no custom integration required.
Agent-specific tokenization: how the credential model works
When a consumer onboards their Visa card to an agent platform, three things happen.
consumer → VIC enroll_card({ card_number, agent_id: "skyfire-001",
controls: { limit_per_txn: 50000, categories: ["retail"] } })
↓
Visa VTS → step_up_verification(issuer) → identity_confirmed
↓
Visa VTS → issue_agent_token({ token: "4111xxxxxxxxAGNT",
binding: { agent_id: "skyfire-001" },
controls: { limit: $500, require_passkey: true } })
↓
consumer → create_passkey(agent_token_ref) → fido2_credential_storedThe result: the agent holds a token it cannot use without consumer authentication at instruction time. If the agent’s session is compromised, the attacker has a token with no valid Passkey — useless.
The Trusted Agent Protocol: identity at the HTTP layer
Tokenization solves the credential problem. But the merchant still needs to know the incoming HTTP request is from a legitimate agent — before payment even begins. That’s TAP.
Launched October 14, 2025, developed by Visa and Cloudflare, built on two open standards: HTTP Message Signatures (IETF RFC 9421) and Web Bot Auth. Every participating agent registers a public key in Visa’s directory at tap.visa.com/.well-known/agents/.
The signed HTTP request looks like this:
POST /checkout/complete HTTP/1.1
Host: bose.com
Signature-Input: tap-sig=("@method" "@target-uri" "@authority"
"content-digest" "x-tap-agent-id" "x-tap-intent");
keyid="skyfire-agent-001"; tag="tap-purchase";
created=1742518234; nonce="a3f8c2e1d9b7"
Signature: tap-sig=:MEQCIBx7zK...base64==:
X-Tap-Agent-Id: skyfire-agent-001
X-Tap-Intent: purchase
X-Tap-Consumer-Token: eyJhbGciOiJFUzI1NiJ9...Four things in this request matter:
tag=“tap-purchase”Signals purchase intent vs. catalog browsing. Merchants can gate checkout flows on this field specifically.nonceCryptographically random, unique per request. Stored permanently after use — prevents replay attacks.createdUnix timestamp. Requests older than 60 seconds are rejected — limits the window for intercepted requests.x-tap-consumer-tokenJWT from VIC containing the consumer’s hashed identity, merchant relationship, and payment instruction reference.The merchant’s TAP SDK validates three things locally in under 5ms — no external call needed:
1. Fetch agent public key from tap.visa.com/.well-known/agents/skyfire-agent-001
(cached 5 minutes)
2. Verify Ed25519 signature over canonical request form
Check: created within 60s ✓ nonce unused ✓ agent registered ✓
3. Validate consumer token JWT against Visa's public key
Check: exp > now ✓ aud === merchant ✓ amount matches cart ✓Total TAP handshake latency: ~60ms. Cloudflare and Akamai run behavioral analysis in parallel — both signals must pass.
How ISO 8583 changes for agent transactions
Once the merchant accepts the TAP-verified request, the acquirer builds an ISO 8583 MTI 0100 authorization message. This is where the agent context enters the rail that has existed since 1987.
The critical change is F022 = 81 — a new POS Entry Mode value that propagates through the entire authorization chain. Every downstream system that sees F022=81 applies agent-specific risk rules instead of human behavioral models.
F126 carries the TAP payment instruction reference. VisaNet validates this against its registry — if the amount or merchant was tampered in transit, this check fails and the transaction is declined before reaching the issuer.
Response (MTI 0110):
F038: 123456 ← authorization code
F039: 00 ← approved
F126: agent-confirmed ← TAP reference echoed
// Total VisaNet round-trip: ~180msThe complete VIC API sequence
// 1. Enroll card — one time per consumer-agent pairing
const enrollment = await vic.tools.enroll_card({
user_id: "consumer-123",
card_number: "4111000000001111",
expiration_date: "12/27",
cvv: "123"
})
// → { token_ref: "vts-AGNT-001", passkey_challenge: "..." }
// 2. Consumer creates Passkey — client side, FIDO2
const passkey = await navigator.credentials.create({
publicKey: parsePasskeyChallenge(enrollment.passkey_challenge)
})
// 3. Initiate payment instruction — when consumer says "buy this"
const instruction = await vic.tools.initiate_purchase_instruction({
user_id: "consumer-123",
merchant_id: "bose-com",
amount: 89.99,
currency: "USD",
item_ref: "bose-qc45",
passkey_assertion: await signWithPasskey(passkey, instructionPayload)
})
// → { instruction_ref: "pi-abc123", status: "authorized" }
// 4. Retrieve payment credentials at checkout
const creds = await vic.tools.retrieve_payment_credentials({
instruction_ref: "pi-abc123",
tap_context: tapSignedContext
})
// → { tokenized_pan: "4111xxxxAGNT", expiry: "12/27" }
// 5. Submit commerce signal — not optional
await vic.tools.submit_commerce_signal({
instruction_ref: "pi-abc123",
outcome: "success",
order_id: "bose-order-78234"
})Step 5 is not optional. It creates the audit trail that makes disputes solvable: the original Passkey-authenticated instruction, the TAP credential, the ISO 8583 authorization, and the fulfillment confirmation. Without it, dispute resolution has no evidence chain.
Real deployments
Skyfire + Consumer Reports + Bose.com is the most complete example. Skyfire’s KYAPay protocol sits on top of VIC and TAP. The agent queried Consumer Reports via MCP, evaluated headphone options, navigated to Bose.com, presented TAP credentials, and completed checkout — no consumer interaction required after the initial “find me headphones” instruction.
Nekuda on Gensmo demonstrates multi-merchant checkout. When the AI stylist assembles an outfit, Nekuda’s payment layer executes purchases across multiple merchants simultaneously from a single agent instruction — each leg independently TAP-verified.
Ramp’s B2B implementation is architecturally different. Corporate agents operate with pre-authorized spending policies instead of per-transaction Passkey assertions. The policy is configured once: allowed MCCs, per-transaction limits, daily velocity. The agent then pays invoices and subscriptions autonomously within policy, capturing cashback automatically by selecting the correct card per merchant category.
Four layers of defense
TAP vs x402 vs MCP vs AP2
2025 produced four competing approaches. They are not mutually exclusive — they solve different problems.
TAP + VIC is the most complete stack for card-network payments. Agent-bound tokens, Passkey auth, spending controls, commerce signals, MCP server, VIC sandbox. ISO 8583 carries agent context through existing rails. Best for consumer retail where buyer protection matters.
x402 (Coinbase, launched May 2025) is HTTP-native stablecoin payments. The server responds with HTTP 402 Payment Required, the client pays in USDC on Base or Solana, receives proof of payment, re-requests the resource. No accounts, no subscriptions, no chargebacks — which is the point. By December 2025 it had processed 75M transactions worth $24M. Best for API micro-payments and agent-to-agent billing. Not a competitor to TAP — complementary.
MCP Payments is not a competing protocol. It’s VIC wrapped in the MCP transport layer. Visa published a remote MCP server at github.com/visa/mcp — any Claude-based agent accesses full VIC capabilities through standard MCP tool calls.
AP2 (OpenAI, Google, Stripe, Salesforce) uses OAuth-based identity rather than public key cryptography. Better for agents operating within existing OAuth ecosystems, less suitable for headless browser automation where no SSO context exists.
| Use case | Best protocol |
|---|---|
| Consumer retail, Visa card, chargeback needed | TAP + VIC |
| B2B invoicing, corporate cards | VIC payment instructions |
| API billing, per-call micro-payments | x402 |
| Agents built on Claude / ChatGPT | MCP → VIC |
| Existing OAuth ecosystem | AP2 |
What’s not solved yet
Multi-agent authorization — when a supervisor agent orchestrates subagents, who holds the TAP credential? The current spec doesn’t address this. AWS AgentCore hints at a supervisor pattern but it’s not standardized.
Cross-network interoperability — TAP and Mastercard Agent Pay launched the same week with near-identical architectures but different key directory formats. An agent building for multi-network acceptance today needs to implement both.
Consumer loyalty — whether an agent is acting for the consumer’s interest or the merchant’s is not formally defined or measurable. Identity and consent can be logged; loyalty cannot.
If you’re building agents right now
Consumer shopping: fastest path is Skyfire or Nekuda — they handle TAP registration, VIC integration, and browser automation. Direct integration: start at developer.visa.com/capabilities/visa-intelligent-commerce and github.com/visa/mcp. Budget more time for FIDO2 Passkey integration than for the payment API itself.
B2B procurement: Ramp’s architecture is the reference. Pre-authorized spending policies, not per-transaction Passkeys. Define the policy once, let the agent execute autonomously within it.
API monetization: x402. Four lines of Express middleware, first 1,000 transactions free on Coinbase’s facilitator.
Merchant checkout: TAP SDK is a no-code embed. The harder work is updating your bot detection to pass TAP-verified agents rather than blocking them.
Sources
- Visa Intelligent Commerce:
developer.visa.com/capabilities/visa-intelligent-commerce - Visa MCP Server:
github.com/visa/mcp - Cloudflare TAP + Web Bot Auth:
blog.cloudflare.com/secure-agentic-commerce - Trusted Agent Protocol announcement (Oct 14, 2025): Visa investor relations
- x402 spec:
x402.org·github.com/coinbase/x402 - Skyfire KYAPay: BusinessWire, December 18, 2025
- Consumer Reports agentic commerce prototypes:
innovation.consumerreports.org
Coming next
All diagrams built with payarch — open source tool for visualizing agentic payment architectures.