The Card Networks Split on How Agents Pay

PSD2's Strong Customer Authentication requires two of three factors for electronic payments: a PIN or password, a phone or hardware token, a fingerprint or face scan. Every factor assumes a person is present when the payment happens.

What happens when the payer is software?

On September 24, Cleverbridge processed France's first passkey-authenticated card-rail agent payment through Visa and Revolut. Nobody typed card numbers, entered a PIN, or tapped "approve." A FIDO2 passkey, set up days earlier, authenticated the transaction. In Spain, BBVA completed a similar pilot.

The card networks see what's coming. Visa and Mastercard have both shipped agent payment infrastructure. But they've made fundamentally different architectural bets on where spending constraints live in the stack.

Visa's bet: verify the agent, trust the edges

Visa's Trusted Agent Protocol identifies agents to merchants. An agent presents cryptographic signatures verified against Visa's Agent Directory, using HTTP Message Signatures (RFC 9421) aligned with WebAuthn. The merchant knows which agent is transacting and which consumer is behind it.

Authentication uses Payment Passkeys. The cardholder sets up a FIDO2 biometric credential beforehand. At checkout, the passkey authenticates the transaction. No OTP, no manual approval. Visa presents this as satisfying PSD2's SCA requirements: "something you are" (biometric) plus "something you have" (device).

The Intelligent Commerce platform underneath is protocol-agnostic. It supports TAP, the Machine Payments Protocol, Stripe's Agentic Commerce Protocol, and the Universal Commerce Protocol. Visa partnered with OpenAI in June 2026 for agentic commerce experiences. By July, 30 European issuers had activated agent checkout.

But TAP is fundamentally an identity layer. Visa's network knows which agent made the payment. Spending constraints, merchant restrictions, and category limits are enforced by the merchant and the issuer, not by Visa's authorization stack. If a merchant doesn't check, and the issuer's fraud models are calibrated for human spending patterns, the constraint falls through.

A passkey set up last week proves the cardholder exists and once consented to this payment method. It doesn't express the cardholder's intent for a transaction happening right now. The question of what the user told the agent it was allowed to buy lives outside the protocol.

Mastercard's bet: bake the mandate into the token

Mastercard's Agent Pay takes a structurally different approach. Instead of verifying the agent at the edge and trusting merchants to enforce constraints, Mastercard encodes the spending mandate inside the token and enforces it at the network layer during authorization.

The flow: a consumer enrolls a card and grants an agent a policy with a spending ceiling, allowed merchant categories, geographic restrictions, and an expiration. Mastercard's Digital Enablement Service mints an Agentic Token cryptographically bound to that policy. The agent never holds the raw PAN.

At checkout, the agent presents the token. The acquirer processes it through the normal card rail.

The enforcement happens at the Mastercard network, not at the merchant or issuer. During authorization, Mastercard validates the policy signals before releasing approval. A scope violation, wrong merchant category, exceeded cap, transaction outside the allowed geography, is rejected by the network itself.

That's the architectural difference. Visa verifies who the agent is and leaves enforcement to merchants and issuers. Mastercard carries the user's spending mandate inside the credential and enforces it before the issuer even sees the transaction.

Revocation is granular. A consumer can revoke one agent's token without affecting the underlying card or other agents' tokens. Each agent gets its own scoped credential.

Verifiable Intent

Mastercard went further than the token. In early 2026, co-developed with Google and donated to the FIDO Alliance, they introduced Verifiable Intent: a tamper-resistant signed artifact that links three things.

The identity of the cardholder who authorized the agent, the cardholder's specific instructions (merchant, amount, parameters), and the interaction between agent and merchant that produced the purchase. It uses Selective Disclosure (RFC 9901) so no single party in the chain sees the full profile.

This is the authorization-scope artifact that the delegation gap analysis identified as missing from the open protocols. Mastercard built one. It maps to the AP2 mandate model: signed verifiable credentials carrying exact bounds, amount, payee, instruments, recurrence, budget.

The consent model follows from the architecture. Mastercard authenticates at the mandate level, not per-transaction. The consumer approves parameters once via biometric, and all agent transactions within those parameters proceed without additional human approval.

Visa authenticates per transaction via passkey, which means the cardholder's identity is confirmed on every payment. But those passkey ceremonies don't carry information about what the user intended the agent to do.

Verifiable Intent is still early. The wire-level specifications are gated. Revocation is deferred to a later version. A reference implementation exists at verifiableintent.dev.

Where the regulator isn't

Neither approach has a regulatory blessing.

PSD2 requires two of three factors for electronic payments. All three factors, knowledge, possession, and inherence, assume a human is performing the authentication. A German law firm's September 2026 analysis found that major payment providers are calling on lawmakers to amend payment services regulations to address agent-initiated transactions.

Visa claims passkeys satisfy SCA. No independent ruling confirms this for payments where no person is present at checkout. Mastercard's mandate-level authentication is closer to the existing merchant-initiated transaction (MIT) exemption, where a consumer pre-authorizes recurring charges. But MIT exemptions were designed for subscriptions with known merchants and fixed amounts, not for an agent shopping autonomously across unknown merchants at variable prices.

PSD3 and the Payment Services Regulation were reportedly finalized in April 2026. Expected to come into force in 2027. Whether there will be an agent-specific SCA exemption is unknown. The EBA will issue new regulatory technical standards, but none of the published materials indicate agent payments are addressed.

The FIDO Alliance launched an Agentic Authentication Technical Working Group on April 28, 2026, drawing from Google's AP2 and Mastercard's Verifiable Intent contributions. The working group exists. The specifications don't, yet.

The card networks are building faster than the regulators are defining.

Agent Pay for Machines

In June 2026, Mastercard extended the architecture further. Agent Pay for Machines (AP4M) is a network service for machine-to-machine payments: AI agents and software orchestrating high-frequency, micro-value transactions.

AP4M launched with over 30 partners including Coinbase, Ripple, Stripe, and the Solana Foundation. It's multi-rail: cards, bank accounts, and stablecoins through one unified layer. Agent permissions and credentials are recorded on Polygon, Solana, and Base blockchains as a registry, though settlement can happen in ordinary money.

Mastercard is acquiring stablecoin startup BVNK to build out the stablecoin settlement capability.

This is the card network moving into territory that x402, MPP, and the crypto-native protocols currently occupy. The mandate enforcement that applies to a consumer agent buying groceries extends to software agents making 200 API calls per minute.

What's still missing

Both networks have solved agent identity. Mastercard's mandate-level enforcement goes further, checking what the agent was allowed to buy against the token's constraints during authorization. That's a meaningful architectural advance over identity-only verification.

But chargeback rules for agent-initiated transactions haven't been published by either network. When an agent buys the wrong thing within its authorized scope, the closest matching reason code was designed for human buyers. An agent that buys the most expensive option when the user said "find me the cheapest" hasn't committed fraud and hasn't exceeded its mandate. The product was delivered as described. The failure is in the agent's interpretation of intent, and no reason code covers that.

Liability for agent-initiated transactions is, as one payments infrastructure company put it, "still being written."

The policy engine patterns that exist in open-source address the application-layer gap. Mastercard's Agentic Tokens address the network-layer gap. The regulatory gap sits above both. Until PSD3 or the FIDO working group produces specifications, every agent payment pilot is operating on the assumption that existing exemptions apply to a use case they were never designed for.