AP2 vs Network Tokens: An Open Standard or the Card Networks' Own Rails?
Depth · Core
AP2 and the card networks’ agent-payment programs both answer the same hard question, how a merchant or bank can trust that an agent is genuinely authorized to pay for a specific purchase, but they come at it from different directions. AP2, the Agent Payments Protocol, is an open, network-agnostic standard: it proves consent with cryptographically signed mandates, and it does not care which rails the money rides. The network programs, Visa Intelligent Commerce, Mastercard Agent Pay, and American Express’s agentic offering, are each network’s own end-to-end approach, built on their existing tokenization and verification and tied to their own rails. The neat framing of “open standard versus proprietary networks” is real, but the more important story is that the two are converging.
At a glance
| AP2 | Network programs | |
|---|---|---|
| What it is | Open authorization standard | Each network’s own agent-payment rails |
| Backers | Google, now the FIDO Alliance | Visa, Mastercard, American Express (separately) |
| Scope | Proving the user approved the purchase | Tokenization, verification, and settlement on the network |
| Approach | Network-agnostic, open spec | Network-specific, proprietary |
| Mechanism | Signed mandates (verifiable credentials) | Agentic and network tokens, passkeys, registered agents |
| Status | Pre-production (v0.2) | Mostly pilot or closed beta |
| Liability | A framework, not a binding contract | Amex has made the most concrete pledge |
What each one is
AP2 is a layer, not a network. It defines how a user’s authorization is captured and proven: signed mandates, expressed as verifiable credentials, that a merchant, network, or bank can check to confirm a real person consented to this specific charge. It is deliberately network-agnostic, so the same authorization can in principle work across any rail. For the detail, see AP2 explained and, for the credential mechanics, AP2 mandates in practice.
The network programs are broader and proprietary. Visa Intelligent Commerce opens Visa’s network to agents through tokenized “AI-Ready Cards” and, since April 2026, an “Intelligent Commerce Connect” on-ramp. Mastercard Agent Pay uses Mastercard Agentic Tokens, built on the tokenization behind contactless and Mastercard Payment Passkeys, and requires agents to be registered and verified. American Express entered with a developer kit and an explicit Agent Purchase Protection pledge. Each bundles agent verification, tokenization, and settlement on its own rails. The directory of who does what is in the landscape, and the mechanics are in how AI agents pay.
The key difference: a layer versus a network
AP2 occupies one layer, authorization, and stops there. The network programs span authorization-like verification, tokenization, and settlement, all inside one network. So they are not strictly like-for-like: AP2 is a piece that composes with rails, while a network program is the whole pipe for that network. The reason they get compared is that both are trying to own “how an agent proves it is allowed to pay,” and a merchant choosing how to support agent payments has to weigh an open standard against the networks’ own end-to-end offerings.
Where they overlap, and why they are converging
This is the part that gets missed. AP2 and the networks are moving toward each other, not away. Google donated AP2 to the FIDO Alliance, where the payments working group is chaired by members from Mastercard and Visa, so the open standard’s stewardship now includes the networks themselves. And Visa’s Intelligent Commerce Connect is explicitly protocol-agnostic, designed to work across AP2, ACP, and other agent protocols. In other words, the networks are helping steward the open standard while also running their own programs. Expect interoperability, not a clean either-or.
Status and liability
Both are early, but in different ways. AP2 is pre-production: it ships an SDK, schemas, and sample scenarios, but the public materials are reference implementations rather than documented live deployments, and its liability guidance is a framework rather than a binding contract. The network programs are mostly in pilot or closed beta, but they come with the networks’ existing rules and, in American Express’s case, the most concrete consumer-protection pledge any player has made so far. For the unsettled liability picture across the board, see agentic commerce risks and readiness.
Which matters for you
For a builder, AP2 is the open authorization layer you can target without committing to a single network, and it is the safer bet for cross-network portability. For a merchant, the network programs are how agent payments actually reach Visa, Mastercard, and Amex cardholders, and they carry the verification requirements and liability terms you will live with. The practical posture is to treat AP2 as the open standard worth building toward and the network programs as the rails you read the fine print on, while watching the two converge through FIDO and protocol-agnostic on-ramps.
FAQ
What is the difference between AP2 and network tokens? AP2 is an open, network-agnostic standard for proving a user authorized an agent’s purchase, using signed mandates. The network programs are each network’s own end-to-end approach, built on their tokenization and verification and tied to their rails.
Do they compete? Less than it appears. AP2 went to the FIDO Alliance, where Mastercard and Visa chair the payments group, and Visa’s on-ramp is protocol-agnostic. The open standard and the network rails are converging.
Which matters for a merchant? Both. AP2 is the open authorization layer to build toward; the network programs are how agent payments reach cardholders and carry the concrete liability and protection terms.