AP2 Explained: The Agent Payments Protocol

The Agent Payments Protocol (AP2) tackles the hardest question in agentic commerce: when a piece of software buys something for you, how does a merchant or bank know you actually authorized that specific purchase, and who is liable if it goes wrong? AP2 is the payment-authorization and trust layer, not a checkout or discovery protocol.

Who is behind it, and the move to FIDO

AP2 was announced by Google on 16 September 2025, presented as the work of a diverse group of “more than 60 organizations” and licensed under Apache 2.0. Named partners in the announcement included Mastercard, American Express, PayPal, Coinbase, Adyen, Worldpay, Salesforce, Intuit, JCB, and UnionPay International, among others. Neither Visa nor Stripe was named in that launch group.

The governance has since shifted. On 28 April 2026, Google donated AP2 to the FIDO Alliance, releasing v0.2 on GitHub the same day. The specification now advances through two FIDO working groups: the Payments Technical Working Group, chaired by members from Mastercard and Visa, which is where AP2 itself is being developed into a specification, and a new Agentic Authentication Technical Working Group, chaired at launch by members from CVS Health, Google, and OpenAI and vice-chaired by members from Amazon, Google, and Okta. Alongside AP2, Mastercard contributed Verifiable Intent, an AP2-compatible framework it co-developed with Google that creates a tamper-evident record of user-authorized agent actions. Google still maintains the reference implementation and SDK, but the normative standard now sits with a neutral body. So calling AP2 “a Google protocol” today is imprecise: it originated at Google and is now under FIDO stewardship.

One nuance is easy to miss and worth stating plainly: FIDO has not published an agentic payments specification of its own. Its announcement describes AP2 and Verifiable Intent as initial contributions that “will be reviewed and further developed through the FIDO Alliance’s collaborative standards process.” So what exists today is still AP2 v0.2 on GitHub, not a FIDO standard, and whatever FIDO eventually publishes may draw on both contributions rather than adopting either as written. If you are choosing what to build against now, build against v0.2 and expect movement.

Where Visa and Stripe actually sit

The “Visa and Stripe are absent” reading was accurate for the September 2025 launch list and is worth handling carefully now, because the two companies are in different positions.

Visa is no longer outside AP2’s governance. It co-chairs the FIDO Payments Technical Working Group that is developing the AP2 contribution, and Visa gave a supporting statement in FIDO’s own announcement. Visa also runs its own program, Visa Intelligent Commerce, whose Intelligent Commerce Connect on-ramp is described as network, protocol, and token-vault-agnostic; Visa’s announcement names the Trusted Agent Protocol, MPP, ACP, and UCP as supported agent protocols, and does not name AP2.

Stripe remains outside AP2. It is not in the launch group, not in the FIDO contribution, and it backs different layers: ACP with OpenAI for checkout, and MPP with Tempo for machine payments.

Both companies are, however, premier members of the x402 Foundation, which the Linux Foundation launched operationally on 14 July 2026 with 40 members. So are Google, Mastercard, American Express, Adyen, AWS, and Shopify. The practical read is that the major players are not lining up behind one authorization standard and against another; they are joining several bodies at once and hedging across rails.

The mandate model

The core idea is a mandate: a cryptographically signed, tamper-evident verifiable credential that captures authorization in a way a merchant or network can verify and later use as dispute evidence. The exact model has evolved, and it is worth knowing both versions because secondary write-ups often quote the old one as if it were current.

The original (v0.1) model used three mandates. An Intent Mandate captured the user’s high-level instructions and constraints, such as a category, a price ceiling, and timing, and was used especially for purchases made when the user is not present. A Cart Mandate captured the finalized cart, the exact items and amount, signed by the user for purchases made when they are present. A Payment Mandate was shared with the network and issuer to signal that an agent was involved and whether a human was present.

The current (v0.2) model reorganizes this into verifiable digital credentials with two primary types, each having an open and a closed stage. A Checkout Mandate covers pre-cart constraints (open) and authorization of a finalized cart (closed). A Payment Mandate covers instrument and budget constraints (open) and authorization of a specific amount bound to a finalized checkout (closed). If you describe the older “Intent, Cart, Payment” framing, label it as the launch model.

The headline change in v0.2 is Human Not Present payments: the open mandates let an agent execute a purchase autonomously, within constraints the user signed earlier, when the user is not in the session. Google’s example is buying limited-run tickets the moment they go on sale. Each mandate is now also paired with a signed receipt, so the verifier’s accept or reject decision is itself part of the record.

Across both versions the mechanism is the same: signatures use hardware-backed device keys with in-session authentication, and the chain from intent through cart to payment forms a non-repudiable audit trail used for authorization, authenticity, and resolving disputes. For the credential structure, the SD-JWT signing and verification, and a worked SDK example, see AP2 mandates in practice.

How it relates to the other standards

AP2 is built as an extension of A2A, the agent-to-agent protocol, and is positioned to work with MCP as well. For the commerce side of a transaction, Google pairs AP2 with its Universal Commerce Protocol (UCP): AP2’s own FAQ describes UCP as orchestrating the broader purchase lifecycle while AP2 is the specialized layer that authorizes and signs the payment. For how AP2 compares with the card networks’ own agent-payment programs, see AP2 vs network tokens.

For crypto and machine-to-machine payments, Google built the A2A x402 extension with Coinbase, the Ethereum Foundation, and MetaMask, aligning AP2 with the x402 stablecoin approach. Regarding ACP, the OpenAI and Stripe checkout standard, no primary AP2 source mentions it directly; the popular “AP2 versus ACP” framing comes from commentary rather than the standards bodies themselves.

Status and honest limitations

As of mid-2026, AP2 is best understood as pre-production. Primary sources describe reference implementations, SDKs, and sample scenarios that mock real payment providers, not documented live, real-money deployments. With the standard now mid-flight into FIDO, the normative spec is early-stage and actively in committee.

The primary materials are also candid about open problems.

Trust bootstrapping is still being worked out. v0.2 defines two models for deciding whose signature a verifier should trust: a User Credential model, where an external issuer the verifier already trusts vouches for the surface that captured consent, and a Trusted Agent Provider model, where the verifier trusts the agent’s provider directly. The specification is explicit that the second model is simpler but “requires Verifiers to establish trust with every Agent Provider,” which is the allow-list problem in a new form.

AP2 does not allocate liability, and does not claim to. Its own executive summary lists accountability as an open question, asking whether the user, the agent’s developer, the merchant, the network, or the PSP is responsible when something goes wrong. What the protocol offers instead is evidence: the stated objective is “to provide supporting evidence that helps payment networks establish accountability and liability principles,” and the specification puts dispute resolution, retention, and retrieval explicitly out of scope. Actual liability still rests on each network’s rules.

Payment-type coverage is partial. Cards are supported and stablecoins are handled through the x402 extension. v0.2 added constraint types for recurring agent use (payment.agent_recurrence, payment.budget) and for open-banking payment initiation providers (payment.allowed_pisps), but AP2’s own documentation still describes e-wallets and push payments such as real-time bank transfers (UPI, PIX) as roadmap rather than shipped.

What it means for you

If you are a merchant or a payments team, AP2 is the leading candidate for the authorization-and-trust layer, and its move to FIDO makes it more likely to become a genuine cross-industry standard rather than one vendor’s framework. If you are a builder, treat AP2 as the proof-of-authorization layer that sits underneath a checkout protocol, and watch the FIDO working groups for where the spec actually lands. Either way, do not assume it is in production yet.

FAQ

Is AP2 still a Google protocol? It originated at Google in September 2025, but Google donated it to the FIDO Alliance on 28 April 2026, where the spec is now developed. Calling it simply a Google protocol is out of date.

What is a mandate? A cryptographically signed verifiable credential that records authorization. The model moved from Intent, Cart, and Payment mandates to a Checkout Mandate and a Payment Mandate, each with open and closed stages.

Does AP2 compete with ACP? They sit at different layers, authorization versus checkout, and the standards bodies do not frame them as rivals. Neither Visa nor Stripe was in AP2’s September 2025 launch group, but Visa now co-chairs the FIDO working group developing AP2, and both are premier members of the x402 Foundation.