AP2 vs ACP vs Visa TAP: The Agent Authorization Protocols Compared

_Last updated: 2026-06-07_

Three protocols are racing to define how an AI agent proves it's allowed to spend: AP2 (Google's cryptographically signed mandates), ACP (the OpenAI- and Stripe-backed Agentic Commerce Protocol), and Visa TAP (Trusted Agent Protocol, proving agent identity at the merchant's front door). All three are live or rolling out as of mid-2026. Here's the part most coverage misses: they don't really compete. They sit on different layers, and a serious stack ends up using all three.

Key takeaways

What is AP2 and how does it work?

AP2 (Agent Payments Protocol) is Google's framework for issuing cryptographically signed mandates that prove an agent is authorized to act for a user. It launched in September 2025 with 60+ partners, Mastercard among them, and Google donated it to the FIDO Alliance in April 2026 to put it under neutral governance.

Each mandate is a W3C Verifiable Credential, the same open standard behind digital identity. It carries an issuer (usually the user or org granting authority), a subject (the agent), a payload (what it can buy, how much, under what conditions), and a signature that makes the whole thing tamper-proof.

the authorization chain travels with the transaction. A merchant or processor can verify an AP2 mandate is genuine and unmodified without calling back to Google. For the mechanics, see [AP2 verifiable mandates explained](/blog/ap2-verifiable-mandates-explained).

AP2 lives at the application and merchant layer. It's the signed proof of authorization, not the rail that moves the money.

What is ACP and how does it work?

ACP (Agentic Commerce Protocol) is a joint OpenAI–Stripe effort, released September 2025 under Apache 2.0. It's a messaging standard: how an agent states purchasing intent, presents payment credentials, and gets confirmation back from a merchant. It's the protocol behind Instant Checkout in ChatGPT, and Stripe's Shared Payment Tokens are its payment primitive, a token scoped to one merchant and one cart total, so the agent never holds the raw card.

If AP2 is the signed document, ACP is the envelope and the courier. It handles the checkout conversation for agent transactions, token presentation, and responses, mapped onto API patterns teams already know.

The catch: ACP's reach is tightest around Stripe today, though the token side opened up in March 2026 to Mastercard Agent Pay, Visa Intelligent Commerce, and BNPL providers. If you run payments across multiple processors, confirm coverage before you treat ACP as the whole answer.

What is Visa TAP and how does it work?

Visa TAP (Trusted Agent Protocol) attacks the problem at the merchant's front door. Published with Cloudflare in October 2025 as an open spec, it lets an agent cryptographically sign its identity into HTTP headers (the HTTP Message Signatures standard), so a merchant can verify it's dealing with a known, registered agent at or before checkout.

The insight: merchant defenses are trained on human behavior. A legitimate agent hitting a checkout flow at 3am looks exactly like a bot attack to a legacy system, and gets blocked. TAP gives the agent a way to prove who it is, and gives the merchant a key directory to check that proof against, instead of forcing a guess.

TAP sits beside AP2 and ACP, at the web and checkout layer rather than on the card rails. It doesn't replace them. AP2 proves authorization, ACP carries the checkout conversation, TAP keeps the merchant's defenses from turning a legitimate agent away.

AP2 vs ACP vs Visa TAP, comparison table

| Dimension | AP2 (Google) | ACP (OpenAI + Stripe) | Visa TAP |

|---|---|---|---|

| Layer | Application / credential | Application / messaging | Web / checkout |

| Core function | Signs and verifies agent authorization | Structures agent-to-merchant checkout communication | Proves agent identity to merchants via signed HTTP requests |

| Credential format | W3C Verifiable Credentials | Open spec (Apache 2.0); Shared Payment Tokens | HTTP Message Signatures against registered agent keys |

| Key partners | 60+ at launch (Sep 2025), incl. Mastercard | OpenAI, Stripe; token support extended to network programs Mar 2026 | Cloudflare; acquirers incl. Adyen (Jan 2026) |

| Scope | Authorization proof; cross-platform | Transaction messaging; Stripe-centric | Agent identity at checkout; web-level |

| Replaces legacy auth? | Extends it with cryptographic proof | Extends it with a structured protocol | Extends it with agent identity verification |

| Multi-protocol compatible? | Yes | Yes | Yes (complements AP2/ACP) |

| Maturity (mid-2026) | Live; FIDO Alliance governance since Apr 2026 | Live (ChatGPT Instant Checkout) | Live pilots; early acquirer support |

Why is the future multi-protocol?

Each one solves a different layer of the same purchase. An agent needs proof it's authorized (AP2), a standard way to run the checkout conversation (ACP), and a way to show the merchant it's a legitimate agent rather than a hostile bot (TAP).

Bet on one and you get gaps. AP2 without TAP: a well-authorized agent that still gets blocked at the merchant's door. ACP without AP2: a fluent agent-merchant exchange with no tamper-proof authorization behind it. TAP without either: an agent the merchant trusts, with no proof of what it's actually allowed to spend.

The human-payments parallel is instructive. ISO 20022 messaging, the card network rails, and 3D Secure authentication all coexist. No single protocol does everything. Agent payments are heading the same way.

What should an operator actually do?

Start from the payment stack you already have.

On Stripe: ACP is the lowest-friction first step. Add AP2 mandate generation to establish the authorization chain. Confirm TAP support with your Stripe team. Stripe was in TAP's early signatory cohort.

Not on Stripe: check AP2 first; it has the broadest non-Stripe partner base. Then ask whether your acquirer verifies TAP signatures. Adyen shipped support in January 2026; others are following.

The real call isn't picking a winner. It's choosing infrastructure that won't strand you when these protocols evolve and new ones show up. Flexibility wins.

Frequently asked questions

What is the difference between AP2 and ACP?

AP2 (Google) is a credential system, cryptographically signed proof of an agent's authorization, built on W3C Verifiable Credentials. ACP (OpenAI/Stripe) is a messaging standard for how an agent communicates that authorization to merchants and processors. AP2 is the signed document; ACP is the protocol that carries it. They're built to work together.

What is Visa TAP?

Visa's Trusted Agent Protocol, an open spec published with Cloudflare in October 2025. Agents cryptographically sign their identity into HTTP requests so merchants can verify a legitimate agent at or before checkout, instead of blocking it as a bot. It works at the web layer and complements AP2 and ACP.

Does Mastercard support AP2?

Yes. Mastercard was a launch partner when Google announced AP2 in September 2025, and it co-developed the Verifiable Intent standard that was donated to the FIDO Alliance alongside AP2 in April 2026. That matters because it gives AP2 reach beyond Google's own platforms.

Do I have to choose one protocol?

No, and you shouldn't. The three operate at different layers and are designed to complement each other. A complete stack uses all three, the only question is sequencing given your current setup.

Is ACP only for Stripe customers?

It has the deepest Stripe integration today, but it's an open protocol and adoption is broadening. On a non-Stripe stack, confirm support with your processor before leaning on it as a primary layer.

---

For how AP2 mandates are structured and verified, read [AP2 verifiable mandates explained](/blog/ap2-verifiable-mandates-explained).