The one-line version: Visa's Trusted Agent Protocol, Mastercard's Agent Pay, and Google's AP2 are not three competing checkout buttons — they are an identity layer, a card-tokenization layer, and a portable-authorization layer, and a real agent payment can use all three at once. The decision that matters isn't "which brand wins"; it's which liability and lock-in model you're signing when your agent — or your storefront — starts moving money without a human's thumb on the button.
If you're building an agent that spends, or a store that wants to accept spending agents, this is the map.
What each one actually does#
Visa Trusted Agent Protocol (TAP) — part of the broader Visa Intelligent Commerce program — answers a narrow, important question: is this agent allowed to be here? It's an agent-to-merchant trust layer. The agent presents a cryptographic signature with each interaction so the merchant can verify its identity and its scope before anything gets charged. Under the hood it's built on HTTP Message Signatures (RFC 9421) and aligns with WebAuthn, and the specifications, merchant guidance (key retrieval, signature verification), and reference code are already published in the Visa Developer Center and on GitHub (Visa, Visa Developer). Scope is enforced at the network level — "appliances under $100 only" can be rejected before it ever settles.
Mastercard Agent Pay answers a different question: how does the card get charged, safely? Announced April 29, 2025, it issues Agentic Tokens — an extension of Mastercard's existing tokenization service (MDES) — that bind a tokenized card credential to a specific agent, a specific merchant scope, and a specific consent policy. The agent completes a card checkout without ever touching the real card number, and the token itself carries the guardrails.
Google AP2 (Agent Payments Protocol) answers the question underneath both: can you prove a human authorized this exact purchase? Announced September 16, 2025 with 60+ partners — Mastercard, American Express, PayPal, and Coinbase among them — AP2 is open and rail-agnostic. It chains three signed Mandates: an Intent mandate (the human delegates authority), a Cart mandate (the human approves this cart at this price), and a Payment mandate (the derived credential the network sees). Each is carried as a W3C Verifiable Credential — a tamper-evident, portable proof. Crucially, AP2 doesn't move money; it produces the authorization record, and cards, bank transfers, or stablecoins (via the A2A x402 extension, built with Coinbase, the Ethereum Foundation, and MetaMask) settle against it (Google Cloud, AP2 docs).
Why "versus" is the wrong question#
Look at the layers and the overlap disappears:
Identity (who is this agent?) → Authorization (did a human approve this?) → Settlement (how does the money actually move?). Visa TAP owns the first, AP2 owns the second, and the network tokens own the third.
Mastercard and American Express are AP2 launch partners. Visa settles over both fiat and a stablecoin program. These are not walled gardens fighting over your checkout — they're increasingly composable pieces of one emerging stack. A production flow could plausibly verify the agent with a TAP-style signature, carry an AP2 mandate as the proof of consent, and settle on a Mastercard Agentic Token. The "vs" is what founders type into a search box; the answer is "you'll likely use more than one."
The decision that actually matters#
So don't start from the brand. Start from your role and your liability tolerance.
- You're building an agent that buys (procurement, subscriptions, restocking). Your center of gravity is the mandate and the spend caps. AP2's signed Intent/Cart/Payment chain gives you a portable, auditable record of exactly what the human authorized — independent of any single network — which is the artifact you'll want when a purchase is disputed. Scope every mandate to one merchant and one purpose, and set caps lower than feels necessary.
- You're a merchant accepting agent checkouts. Your problem is verifying the agent at the door before you trust anything it says. Visa's TAP is built for exactly this and is available to implement today. This is where the identity layer earns its keep.
- You're settling on cards at scale. The network tokenization schemes plug into dispute, chargeback, and reach that already exist. You inherit mature machinery — and network-specific rules.
The liability trade is the part people skip. A network scheme routes an agent transaction into the card networks' existing chargeback rails: mature, but network-bound. An AP2 mandate is a proof of consent you hold and can present anywhere: portable, but it shifts more of the "was this really authorized?" burden onto how well you scoped and stored it. Stablecoin settlement via x402 is fast and rail-neutral but has weaker built-in reversal than a card. None of these is wrong. But each one is a different answer to "who eats the loss when an agent buys the wrong thing," and you should choose it on purpose.
What to do this week#
If agent payments are anywhere on your 2026 roadmap: read the AP2 mandate schema and map your own "human approved X" moment onto Intent → Cart → Payment (and if you're weighing the open protocols against each other, we compared AP2 vs x402 vs ACP separately); skim Visa's TAP spec if you take checkouts; and decide, before you write a line of integration code, which reversal path you're comfortable owning. The rails are arriving faster than the case law. The founders who win here are the ones who picked their liability model deliberately — not the ones who found out what they'd signed after the first bad charge.
Rollout timelines, partner lists, and availability move quickly and are largely vendor-reported — verify the current status of each protocol against its own documentation before you build.
