On April 29, 2025, Mastercard announced Agent Pay. On April 30, Visa announced Intelligent Commerce. One day apart, same week, same problem — and they built meaningfully different architectures to solve it. Both announced their Cloudflare partnership on the exact same day in October. That’s not a coincidence. That’s the standard converging.
This post is about the 4-party model: the settlement architecture that has moved money between consumers, merchants, banks, and networks since the 1970s. It was built around one assumption — a human is present, initiating the transaction, in real time. That assumption no longer holds.
Here is exactly what breaks at each layer when an AI agent initiates a purchase, and how each network rebuilt around it.
Why the 4-party model breaks for agents — layer by layer
The 4-party model is also a fraud prevention stack. Each participant has a specific job. The problem is that every job was designed around one assumption: a human is present, acting in real time. When that assumption disappears, the stack doesn’t degrade gracefully — it fails completely, at every layer simultaneously.
Layer 1: Merchant + Gateway
Before an authorization request ever leaves the merchant, the gateway runs behavioral checks: CAPTCHA, WAF rules, device fingerprinting, velocity limits. The point is to catch automated scripts brute-forcing card numbers before they hit the banking system.
An AI agent fails every one of these checks — not because it’s malicious, but because it’s optimal. No mouse movement. Machine-speed execution from a data center IP. Headless Chrome fingerprint. Algorithmically timed requests. A legitimate agent buying a $90 pair of headphones looks indistinguishable from a coordinated carding attack. The merchant blocks the request before payment is even attempted. Nothing downstream matters if the agent can’t get through the front door.
Layer 2: Acquirer + Processor
If something gets past the gateway, the acquirer evaluates it against the merchant’s normal transaction profile — AVS match, CVV, IP reputation, behavioral patterns.
The real issue here is F022. That’s the POS Entry Mode field in ISO 8583, set to 01 (manual key entry) by default for ecommerce since the 1990s. It tells every system downstream: apply human transaction rules. An agent transaction from an AWS IP with no AVS match, carrying F022=01, looks exactly like credential stuffing. The field that needed to change was this one — and changing it is the most precise description of what both networks actually built.
Layer 3: Card Network
The network has cross-merchant visibility that no single bank has. It runs large-scale ML models trained to catch distributed attacks. By definition, machine-speed transactions from data center IPs with no human behavioral signal are what those models were built to flag.
A Skyfire agent buying headphones gets the maximum risk score. Not because it did anything wrong, but because it matches the exact behavioral fingerprint of every attack the model was trained on. There’s also no mechanism to verify that the consumer already authorized this specific purchase before the transaction arrived.
Layer 4: Issuer Bank
The issuer receives the network’s risk score and makes the final call. When signals are ambiguous — which a maximum risk score very much is — it triggers 3DS step-up authentication: an SMS or biometric challenge sent to the cardholder in real time.
An agent cannot respond to a 3DS SMS. The transaction fails permanently. No fallback, no retry path. The sale is gone.
What each network actually rebuilt
Layer 1: replace behavioral heuristics with cryptographic identity. The WAF can’t tell a bot from a legitimate agent based on mouse movement — but it can verify a signed HTTP request against a public key. Both networks provide exactly this. Visa via the TAP JWT; Mastercard via Cloudflare verification at the CDN edge before the request reaches merchant infrastructure.
Layer 2: add new ISO 8583 fields that signal agent context. F022=81 for agent-initiated (replacing the 1990s default of 01). F048 for the agent identifier. F126 for the instruction integrity hash. The acquirer’s risk model now has a signal to work with.
Layer 3: pre-payment instruction registry. The consumer’s authorized intent is registered before the transaction. When the ISO 8583 message arrives, the network validates that amount, merchant, and agent match the original authorization. Anything tampered in transit gets declined with response code 58.
Layer 4: replace 3DS with pre-authorized spending policies. The FIDO2 Passkey assertion happens at enrollment — at instruction time, not transaction time. When F022=81 arrives, the issuer loads the agent’s spending policy and runs deterministic checks: balance, per-transaction limit, merchant category, velocity, token status. No probabilistic scoring. No step-up needed because the consumer already proved presence when they enrolled.
The layered defense is preserved. Every layer still has its job. The tools have been replaced with ones that work for a principal who isn’t physically present.
How each role changes
The consumer
In the old model: present at every transaction. Authenticates, enters credentials, approves the charge.
In the agent model: present once, at enrollment. Sets a spending policy — category limits, per-transaction cap, daily velocity — and signs a FIDO2 Passkey that pre-authorizes the agent. After that, they’re absent. The agent runs the transaction; the consumer gets a push notification when it’s done.
This is a fundamentally different trust model. The consumer isn’t approving a transaction — they’re configuring a policy that governs a class of future transactions. It’s closer to setting up a direct debit than clicking a buy button.
The AI agent
There’s a new party in the model. Not a consumer. Not a merchant’s checkout page. An autonomous entity that sits between consumer intent and merchant execution, holds its own cryptographic identity, and signs every request it makes. Both networks treat it as an independent principal — which is the only way to make the authorization chain traceable.
The issuer: two modes
When F022=81 arrives, the issuer loads the consumer’s agent spending policy instead of running the standard human behavioral model. The checks become deterministic: balance, per-transaction limit, category, velocity, token status. Citi and US Bank went live first on Mastercard Agent Pay; all US Mastercard cardholders were enabled by November 2025.
The acquirer
For agent transactions: F002 gets the agent-specific token (not the real PAN), F022=81 signals agent-initiated, F048 carries the agent identifier, F126 carries the instruction integrity hash. The ISO 8583 message is the same format — the fields that changed are these four.
The merchant: where the two architectures actually differ
Visa: TAP SDK in checkout. JWT validation local, under 5ms. Explicit integration required.
Mastercard: Web Bot Auth at the CDN layer. No merchant code change for basic verification. Agents submit a Dynamic Token Verification Code in the existing card fields. Merchants get agent support without touching their codebase.
Mastercard is optimizing for adoption at scale — 100M+ merchants is a different constraint than a fintech integration. Visa is optimizing for the richness of what the merchant learns about the agent credential.
Visa Intelligent Commerce: the TAP architecture
Consumer enrolls → VIC enroll_card() → VTS issues VCN bound to agent_id
Consumer creates FIDO2 Passkey on device
--- Transaction ---
Agent → POST tap.visa.com/v1/validate
(Ed25519 signed, RFC 9421 HTTP Message Signatures)
Visa TAP → validates signature, nonce, timestamp, wallet policy
Visa TAP → issues JWT (TTL 90s, instruction_ref: pi-abc123)
Visa TAP → registers payment instruction in VIC registry
Agent → POST merchant/checkout (Authorization: TAP-1.0 {jwt})
Merchant → validates JWT locally against cached Visa public key
Agent → VIC retrieve_payment_credentials(instruction_ref)
→ returns VCN tokenized_pan
Acquirer → ISO 8583 MTI 0100
F002: VCN
F022: 81 ← agent-initiated
F048: AGNT:agent_id
F126: pi-abc123:sha256:... ← TAP integrity hash
VisaNet → validates F126 against VIC registry (amount, merchant)
→ VTS de-tokenizes VCN → routes to issuer
Issuer → loads agent spending policy for token → approves: F039=00
Agent → VIC submit_commerce_signal(instruction_ref, outcome)The key insight: F126 creates an integrity lock. VisaNet validates that the amount and merchant in the ISO 8583 message match the original payment instruction the consumer authorized. Tampering in transit → decline with response code 58.
Visa partners: Cloudflare (WBA) · tap.visa.com/.well-known/agents/ · github.com/visa/mcp · Skyfire · Stripe · Adyen · Worldpay
Mastercard Agent Pay: the token-first architecture
Consumer enrolls → Mastercard Token Service issues Agentic Token
bound to agent_id + spending policy
Consumer creates Mastercard Payment Passkey (FIDO2)
--- Transaction ---
Agent → sends HTTP request to merchant
CDN layer (Cloudflare) → Web Bot Auth verification
→ validates agent cryptographic identity
→ blocks unregistered agents before reaching merchant
Agent → submits Dynamic Token Verification Code (DTVC)
in existing merchant checkout form
(no merchant code change required)
Acquirer (Braintree/Checkout.com/Fiserv) → builds ISO 8583
F002: Agentic Token (not real PAN)
F022: agent-initiated equivalent
Agent context in tokenization metadata
Mastercard Network → validates Agentic Token binding
→ routes to issuer with agent policy context
Issuer → loads agent spending policy → approvesThe key insight: the token itself carries the agent binding. Trust is embedded in the credential, not in a parallel identity handshake.
Mastercard partners: Cloudflare (WBA) · FIDO Alliance · Microsoft · OpenAI · Google · PayPal · Braintree · Checkout.com · Fiserv
Side by side
The deeper differences are in the design philosophy. Visa adds an identity layer before the checkout request reaches the merchant — the TAP JWT. Mastercard intercepts at the CDN layer, earlier, without involving the merchant at all. Visa’s VCN looks like a card number and lives in F002 as expected. Mastercard’s Agentic Token carries agent-binding metadata in the token lifecycle itself — trust is in the credential, not in a parallel handshake.
The merchant integration gap is the one that will matter most at scale. Visa requires explicit TAP SDK integration. Mastercard requires nothing. For most merchants, “no code change” is the end of the conversation.
What’s actually the same
The October 14, 2025 Cloudflare announcements tell you something. Both networks announced their Web Bot Auth partnerships on the exact same day — not because they coordinated, but because they both arrived at the same cryptographic primitive: IETF RFC 9421 HTTP Message Signatures. The standard converged before either company made it official.
Both also bet on FIDO2 Passkeys as the consumer authorization mechanism. The biometric challenge happens at enrollment, not at transaction time. The agent then operates within whatever the consumer authorized.
And critically: neither network replaced the rails. ISO 8583 still flows from acquirer to network to issuer. Settlement is T+1. Chargebacks work the same way. The 4-party model is extended, not abandoned. Everything that exists — thousands of acquirer integrations, billions of cards, decades of issuer infrastructure — continues to function without modification.
What’s still not solved
Multi-agent delegation. When a supervisor agent delegates to a subagent, which one holds the TAP credential or Agentic Token? Neither network has published a delegation chain protocol. This is the first hard problem as orchestration systems get more complex.
Cross-network interoperability. A consumer with a Visa card on a Mastercard-integrated platform creates ambiguity. A Visa-registered agent is not automatically recognized by Mastercard’s CDN layer. These are parallel systems with no shared registry.
Dispute evidence. What constitutes sufficient evidence in an agent-initiated chargeback where the transaction was the tenth step in a multi-agent orchestration workflow? Not formally defined.
PSD2. Strong Customer Authentication was designed for human authentication. Pre-authorized spending policies don’t map onto the SCA framework cleanly — and the EU hasn’t indicated how they will.
For engineers building in this space
On Visa: Start at developer.visa.com/capabilities/visa-intelligent-commerce. The open-source MCP server (github.com/visa/mcp) gives full VIC access through standard Claude/GPT tool calls. TAP registration and Ed25519 key pair setup take longer than expected — budget for it.
On Mastercard: developer.mastercard.com/agent-pay. Merchants take the no-code CDN path. Acquirers integrate at the Agentic Token requestor layer via Mastercard’s Secure Card on File service.
If you’re building agents, not infrastructure: Skyfire’s KYAPay handles Visa VIC + TAP registration. The PayPal partnership and Microsoft Copilot Studio are the fastest paths to Mastercard production.
If you’re building for both: The RFC 9421 layer is shared — the same Ed25519 key pair format works across both networks. Token issuance and spending policy layers are separate. Start with the identity layer; it’s the part that converges.
Sources
- Mastercard Agent Pay launch (Apr 29, 2025):
mastercard.com/news/press/2025/april/mastercard-unveils-agent-pay - Mastercard Agent Pay Acceptance Framework:
mastercard.com/global/en/news-and-trends/stories/2025/agentic-commerce-framework.html - Mastercard + Cloudflare (Oct 14, 2025): same day as Visa announcement
- Mastercard + PayPal (Oct 2025):
newsroom.paypal-corp.com/2025-10-27-Mastercard-and-PayPal - Mastercard + Fiserv:
startuphub.ai/ai-news/the-fiserv-mastercard-strategy - Visa Intelligent Commerce:
developer.visa.com/capabilities/visa-intelligent-commerce - Visa TAP + Cloudflare (Oct 14, 2025):
blog.cloudflare.com/secure-agentic-commerce - Visa MCP Server:
github.com/visa/mcp - IETF RFC 9421:
rfc-editor.org/rfc/rfc9421 - FIDO Alliance Payments Working Group:
fidoalliance.org
Coming next
All diagrams built with payarch — open source tool for visualizing agentic payment architectures.