# Agentic Payment Protocols, Explained

> AP2, Visa Trusted Agent Protocol, and Mastercard Agent Pay decide whether an agent can complete a purchase with you: table stakes for being a selectable merchant, but explicitly agnostic about which merchant gets chosen.

<!-- AP2, Visa Trusted Agent, and Mastercard Agent Pay decide whether an agent can complete a purchase with you: table stakes to be selectable. -->
<!-- Canonical: https://agentmint.net/agentic-payment-protocols/ · By Abdalsalaam Halawa · Published 2026-07-07 -->
<!-- Evidence tags below are load-bearing: <Claim type="spec-fact|reported|hypothesis"> marks how each factual claim is sourced. -->

<KeyTakeaways
  items={[
    "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. <Claim type="hypothesis">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.</Claim> 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. <Claim type="spec-fact" source="Google Cloud: Announcing the Agent Payments Protocol (AP2)" href="https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol">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.</Claim> 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. <Claim type="spec-fact" source="AP2 specification: ap2-protocol.org" href="https://ap2-protocol.org/ap2/specification/">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.</Claim> 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](https://ap2-protocol.org). 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. <Claim type="reported" source="Google: Google donates Agent Payments Protocol to FIDO Alliance" href="https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/" date="2026-04-28">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.</Claim> 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? <Claim type="spec-fact" source="Visa: Trusted Agent Protocol" href="https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx">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.</Claim> 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.

<Claim type="reported" source="Visa newsroom: Visa Intelligent Commerce" href="https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21361.html" date="2025-04-30">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.</Claim>

## 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. <Claim type="reported" source="Mastercard newsroom (corroborated by PYMNTS)" date="2025-04-29" href="https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html">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.</Claim> 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

<ComparisonTable
  caption="Backers, dates, and functions are cited in the sections above. Mastercard Agent Pay's row is reported (PYMNTS), pending confirmation against a Mastercard primary. 'Picks the merchant?' asks whether the protocol itself influences which store an agent chooses."
  idKey="protocol"
  columns={[
    { key: 'protocol', header: 'Protocol' },
    { key: 'backers', header: 'Backers' },
    { key: 'announced', header: 'Announced' },
    { key: 'secures', header: 'What it secures' },
    { key: 'selection', header: 'Picks the merchant?' },
  ]}
  data={[
    {
      protocol: 'AP2 (Agent Payments Protocol)',
      backers: 'Google + partners',
      announced: '16 Sep 2025',
      secures: 'Payment authorization via two signed Mandates (Checkout, Payment); extends A2A + MCP',
      selection: 'No: explicitly agnostic about how agents evaluate merchants',
    },
    {
      protocol: 'Visa Trusted Agent Protocol',
      backers: 'Visa + Cloudflare',
      announced: '14 Oct 2025',
      secures: 'Agent identity: cryptographic signatures that mark an agent as trusted vs. a bot',
      selection: 'No: identity/attestation only',
    },
    {
      protocol: 'Mastercard Agent Pay (reported)',
      backers: 'Mastercard + Microsoft',
      announced: '29 Apr 2025',
      secures: 'A tokenized card credential bound to a specific agent, merchant scope, and consent policy',
      selection: '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. <Claim type="spec-fact" source="AP2: ap2-protocol.org" href="https://ap2-protocol.org">AP2 is explicitly agnostic about how agents identify or evaluate merchants beforehand.</Claim> 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](/how-ai-agents-choose-products/), and see the per-engine playbooks on the [AI shopping platforms hub](/platforms/).

## 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. <Claim type="hypothesis">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.</Claim>

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](/ucp-vs-acp/). 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](/chatgpt-shopping-optimization/), and the Google side in [Gemini and Google AI Mode ranking](/gemini-shopping-ranking/). Two-sentence definitions of [AP2](/glossary/#ap2), [ACP](/glossary/#acp), and [UCP](/glossary/#ucp) live in the glossary.