Key takeaways
- Agentic payment protocols are the trust-and-authorization rails that let an AI agent actually pay. They decide whether a purchase can be completed with you, not whether you get chosen.
- AP2 (Google) structures an agent purchase around two signed Mandates, a Checkout Mandate and a Payment Mandate, and is explicitly agnostic about how agents identify or evaluate merchants.
- Visa's Trusted Agent Protocol and Mastercard's Agent Pay work the identity and card-token side: proving an agent is trusted and binding a payment credential to a specific agent and scope.
- None of these rails rank merchants. Supporting them is table stakes to be transactable; winning the pick is a separate layer decided by your product signals, which is what the rest of this handbook is about.
- Payment plumbing is fast-moving and partly announcement-stage. This page links the primary specs rather than reproducing them, and flags where a fact is reported rather than confirmed against a first-party source.
Why payment rails matter to selection
Before an AI shopping agent can buy anything on your behalf, it has to complete a payment it is authorized to make, and prove, after the fact, that it was allowed to. That is the job of the agentic payment protocols: they standardize how an agent is trusted, how its intent is captured, and how a card or account credential is scoped to a single purchase. They sit underneath the discovery-and-checkout protocols like UCP and ACP, on the "can this actually settle?" layer.
For a merchant, the strategic point is narrow and important. A payment rail an agent cannot complete a purchase over is a reason for that agent to route around a merchant entirely, which makes rail support table stakes for being selectable, even though the rail itself never decides which of several eligible merchants an agent picks.Hypothesis (our analysis) In other words, these protocols are a floor you have to be on, not a lever you pull to win. The three below are the ones worth knowing by name.
AP2: the Checkout and Payment Mandates
AP2 is the payment layer built to sit alongside the agent-interoperability standards. Google announced the Agent Payments Protocol (AP2) on 16 September 2025 as an open, payment-method-agnostic protocol that extends the Agent2Agent (A2A) and Model Context Protocol (MCP) standards to cover how an agent is authorized to pay.Spec-factGoogle Cloud: Announcing the Agent Payments Protocol (AP2) Note the exact name: it is the Agent Payments Protocol (plural), and it is designed to work across payment methods rather than being tied to one card network.
What makes AP2 worth understanding as a merchant is its accountability model. The current AP2 specification structures an agent-led purchase around two signed Mandates, a Checkout Mandate (the merchant's cryptographic proof the shopping agent is authorized to purchase the checkout) and a Payment Mandate (proof the agent is authorized to pay for it), verifiable credentials that together form an accountability trail recording what the shopper authorized and what was ultimately charged.Spec-factAP2 specification: ap2-protocol.org The terminology has moved since AP2 first shipped: Google's original September 2025 announcement described the flow as three Mandates (Intent, Cart, and Payment); the specification has since consolidated to the two Mandate types above. The practical read stays the same: AP2 is about producing a tamper-evident record that a purchase was legitimate, so that banks, networks, and merchants can accept agent-initiated transactions with confidence. It is infrastructure for trust in the transaction, not a system that steers demand toward any particular store. The full specification lives at ap2-protocol.org (opens in new tab)(opens in new tab). We link it rather than restate it, because the spec is the authoritative source for the field-level detail.
AP2's governance changed after launch. Google donated AP2 to the FIDO Alliance in late April 2026; standardization of the specification now continues inside FIDO's Agentic Authentication and Payments Technical Working Groups rather than as a single-vendor spec.ReportedGoogle: Google donates Agent Payments Protocol to FIDO Alliance (2026-04-28) That is a separate, later development from the original September 2025 announcement above, not a correction to it.
Visa Trusted Agent Protocol
Visa's contribution addresses a different question: how does a merchant know the "shopper" knocking on its checkout is a legitimate AI agent and not an abusive bot? Visa and Cloudflare announced the Trusted Agent Protocol on 14 October 2025; it lets merchants recognize and verify trusted AI agents through agent-specific cryptographic signatures, distinguishing legitimate shopping agents from ordinary bot traffic.Spec-factVisa: Trusted Agent Protocol This is an identity-and-attestation rail rather than a checkout schema. Its output is "this agent is who it says it is and is trusted to transact," which a merchant's existing fraud and acceptance logic can then act on.
Trusted Agent Protocol is a distinct announcement from Visa's earlier "Visa Intelligent Commerce" push, unveiled 30 April 2025, about six months before Trusted Agent Protocol; the two are separate initiatives with separate scopes, not the same announcement under two names.ReportedVisa newsroom: Visa Intelligent Commerce (2025-04-30)Mastercard Agent Pay
Mastercard's entry works the card-credential side of the same problem: making a tokenized payment credential safe to hand to an agent. Mastercard and Microsoft introduced Mastercard Agent Pay on 29 April 2025; it binds a tokenized card credential to a specific agent, merchant scope, and consent policy, so a payment can be traced back to the agent that was authorized to make it.ReportedMastercard newsroom (corroborated by PYMNTS) (2025-04-29) Conceptually it is close to Visa's aim from the network side: bound, scoped, revocable authority for an agent to pay, rather than a wide-open card number.
A sourcing note for this section: the date, backers, and function stated here follow PYMNTS's reporting on the announcement. Mastercard's own newsroom release, linked above, is the primary source; where any detail differs, the release is the final word.
The three at a glance
| Protocol | Backers | Announced | What it secures | Picks the merchant? |
|---|---|---|---|---|
| AP2 (Agent Payments Protocol) | Google + partners | 16 Sep 2025 | Payment authorization via two signed Mandates (Checkout, Payment); extends A2A + MCP | No: explicitly agnostic about how agents evaluate merchants |
| Visa Trusted Agent Protocol | Visa + Cloudflare | 14 Oct 2025 | Agent identity: cryptographic signatures that mark an agent as trusted vs. a bot | No: identity/attestation only |
| Mastercard Agent Pay (reported) | Mastercard + Microsoft | 29 Apr 2025 | A tokenized card credential bound to a specific agent, merchant scope, and consent policy | No: card-token scoping only |
The shared column is the last one. Whatever each protocol secures (authorization, identity, or a scoped token), none of them is in the business of deciding which store an agent recommends or buys from. That is not an oversight; it is the design.
Payment is not selection
This is the positioning line that matters, and one of the protocols says it outright. AP2 is explicitly agnostic about how agents identify or evaluate merchants beforehand.Spec-factAP2: ap2-protocol.org The payment rail hands off after the agent has already chosen you; it makes the chosen purchase completable and accountable. Getting your store onto these rails removes a reason to be skipped (an agent will not select a merchant it cannot pay), but it adds nothing to why an agent would prefer you over an equally payable competitor.
So treat payment-protocol support the way you treat SSL or a working checkout: necessary, table stakes, and invisible when it works. The actual contest (the one this handbook exists for) happens one layer up, in the product signals an agent scores when it decides whom to pick. If you have not yet mapped that layer, start with how AI shopping agents choose products, and see the per-engine playbooks on the AI shopping platforms hub.
How this relates to UCP and ACP
It is easy to blur the payment protocols together with the commerce protocols, because they are announced by the same companies and sometimes in the same breath. Keep them on two shelves. The commerce protocols, UCP (Google) and ACP (OpenAI and Stripe), cover discovery and checkout: how an agent finds a product and assembles an order. The payment protocols on this page cover the settlement and trust underneath that order. A merchant can be perfectly legible to a commerce protocol and still fail to convert if the payment and identity rails cannot authorize the agent's purchase, which is why the two layers are worth implementing and reasoning about separately.Hypothesis (our analysis)
For the head-to-head on the commerce layer (scope, which engine each reaches, and why most catalogs should support both), see UCP vs ACP: which gets you selected. For how the payment layer shows up on a specific engine, the ACP rail that powers ChatGPT's checkout is covered in ChatGPT shopping optimization, and the Google side in Gemini and Google AI Mode ranking. Two-sentence definitions of AP2, ACP, and UCP live in the glossary.