AP2 (Agent Payments Protocol) is Google's open protocol for authorizing purchases an AI agent makes on a user's behalf. Instead of an agent simply holding a payment credential and charging it, AP2 requires a chain of cryptographically signed Mandates — Intent, Cart, and Payment — that record exactly what the user authorized, so a merchant, card network, or auditor can later verify the agent acted within the bounds the user actually agreed to. As of this writing, AP2 is versioned 0.2 (pre-1.0) and mid-transition from sole Google stewardship to the FIDO Alliance.
Why agent purchases need a protocol at all
The problem AP2 addresses is specific to agents, not payments generally: when a human clicks "buy," the payment network can reasonably infer consent from the click itself. When an agent initiates a purchase — possibly across multiple steps, possibly without a human watching the final action — that inference breaks down. A merchant or card network has no native way to distinguish "the agent is faithfully executing what the user asked for" from "the agent misread an ambiguous instruction" or "the agent's context was manipulated." AP2's answer is to move the authorization evidence out of an implicit click and into an explicit, signed, inspectable record.
This is a different problem from the one covered in credit wallets for agent payments, which addresses internal spend controls and ledgers for agent-consumed resources generally. AP2 is a public, cross-vendor protocol specifically for consumer- and business-facing purchases an agent makes with real payment instruments, and it sits alongside the broader discipline of FinOps for AI agents rather than replacing it — AP2 governs authorization for a single external purchase; FinOps governs an organization's overall AI spend posture.
The Mandate chain: Intent, Cart, Payment
AP2 structures authorization as three signed Mandates that together form a tamper-evident record:
| Mandate | What it captures | Answers |
|---|---|---|
| Intent Mandate | What the user asked the agent to do, and the constraints they set (budget, category, timeframe) | "What did the user actually authorize the agent to pursue?" |
| Cart Mandate | The specific items, price, and merchant the agent selected to fulfill that intent | "What is the agent proposing to buy, exactly?" |
| Payment Mandate | Authorization to execute payment against the specific cart, using a specific payment method | "Is this exact purchase approved for payment?" |
Because each Mandate is signed and references the one before it, a party inspecting the chain after the fact — a card issuer investigating a dispute, or a merchant validating a claim — can verify that the payment that executed matches a cart the agent proposed, which in turn matches an intent the user actually expressed. That chain is the core mechanism differentiating AP2 from an agent simply being handed a stored card number and told to use its judgment.
Human Not Present: agents transacting without a live approval
AP2 shipped its first major version bump on April 28, 2026 — v0.2 — introducing Human Not Present payments. Under the original model, a live user could be expected to approve or at least be reachable at the moment of purchase. Human Not Present payments extend AP2 to cases where that is not true: an agent executing a pre-authorized instruction with no user actively in the loop at the moment the purchase happens, for cases like securing a limited-availability item the instant it becomes purchasable.
The mechanism does not remove the Mandate chain — it changes when the Intent Mandate is created relative to the purchase. A user pre-authorizes the intent and its constraints in advance; the agent later executes the Cart and Payment Mandates against that standing authorization when its trigger condition is met, without requiring a synchronous approval at execution time. This is the same category of problem addressed conceptually in human-in-the-loop approvals for agents — AP2's Mandate model is one concrete, standardized way to handle the case where a human cannot realistically be in that loop at execution time.
Google also announced, alongside v0.2, a companion standard called Verifiable Intent, co-developed with Mastercard, that creates a tamper-proof log of user-authorized agent actions specifically for accountability purposes — also being donated to the FIDO Alliance alongside AP2.
Governance: mid-transition from Google to the FIDO Alliance
AP2 launched under Google's stewardship in September 2025. On April 28, 2026, Google announced it is donating AP2 to the FIDO Alliance — the same industry body behind passkeys and WebAuthn — to keep the protocol platform-agnostic and community-led rather than controlled by a single vendor. As of this writing, that transition is in progress: AP2 is published on GitHub at v0.2, and governance is moving to FIDO Alliance stewardship rather than having already completed the move. Treat both the version number and the governing body as facts to re-check at the time you evaluate the protocol, not settled long-term state.
This trajectory mirrors how other agentic-AI protocols have moved from single-vendor origin toward multi-stakeholder governance — the same pattern seen with Anthropic's Agent Skills standard, covered in the Agent Skills security vetting checklist.
AP2 versus a payment credential your agent just holds
The alternative to AP2 — an agent holding a card number or tokenized credential directly and charging it on its own judgment — is simpler to implement but leaves no structured, verifiable record of what was actually authorized versus what the agent decided to do. If a dispute arises, the merchant and issuer are reconstructing intent from logs and support tickets rather than inspecting a signed chain. For any organization letting agents transact with real money, that difference is the whole argument for adopting a Mandate-based protocol instead of an ad hoc integration, and it is the same reasoning behind budget policies and hard spend caps for internal agent spend — external payment authorization and internal spend governance are solving structurally related problems from opposite ends.
What AP2 changes for engineering and risk teams
Adopting AP2, whether as a merchant, a payment processor, or a platform whose agents make purchases, is not a drop-in integration on top of an existing checkout flow. It requires generating, signing, and verifying three distinct Mandate types, deciding where the signing keys for each party live, and building the verification logic a merchant or issuer needs to check a Payment Mandate against its referenced Cart Mandate before settling. For a platform-side team, the practical questions worth resolving before adoption are: which of your agents are permitted to hold a standing Intent Mandate at all, what constraints (spend ceiling, category, expiry) get attached to each one, and how you audit that an executed Payment Mandate actually matches the Cart and Intent it claims to descend from. None of this is exotic engineering, but it is a meaningfully different integration surface than a traditional payments API, and it should be scoped as such rather than treated as a checkbox on an existing checkout integration.
The FIDO Alliance transition also matters operationally, not just as a governance detail. A protocol still moving between stewards is more likely to see spec changes than a settled 1.0 standard — version-pin your integration deliberately, track the GitHub repository for breaking changes, and treat AP2 the way you would any actively-developed dependency rather than a fixed interface, a discipline that applies equally to fast-moving protocols like MCP's 2026-07-28 revision.
How AP2 compares to the other agentic commerce protocol
AP2 is not the only protocol in this space. OpenAI and Stripe co-developed a structurally different approach, the Agentic Commerce Protocol (ACP), which uses a scoped checkout token rather than a signed Mandate chain. The two protocols solve overlapping problems differently enough that they are worth comparing directly — see ACP vs AP2: comparing the two agentic commerce protocols for that comparison.
Common questions
Is AP2 a finished, production-ready standard? Not yet by version number. As of this writing AP2 is versioned 0.2, pre-1.0, and Google's April 2026 announcement of donating it to the FIDO Alliance means its governance model is actively in transition rather than settled. Treat it as an actively evolving protocol with strong industry backing, not a finished spec.
What is a Mandate in AP2? A cryptographically signed record capturing one link in the authorization chain: an Intent Mandate captures what the user asked for and the constraints they set, a Cart Mandate captures the specific purchase the agent proposes, and a Payment Mandate authorizes payment against that specific cart. Together they let a third party verify what was actually authorized after the fact.
What does "Human Not Present" mean in AP2? It describes a purchase where no user is actively approving the transaction at the moment it executes — the user pre-authorized an Intent Mandate in advance with defined constraints, and the agent later completes the Cart and Payment Mandates against that standing authorization when a trigger condition is met, added in AP2 v0.2 (April 2026).
Who is backing AP2? Google announced AP2 on September 16, 2025 with more than 60 launch partners spanning card networks, payment processors, and platforms, including Mastercard, PayPal, Coinbase, American Express, and Salesforce. As of April 2026, Google is transitioning governance of the protocol to the FIDO Alliance.
Does AP2 replace internal agent spend controls like budgets and rate limits? No. AP2 governs authorization for external, real-money purchases with third-party merchants and payment networks. Internal controls over how much an agent can consume in compute, API calls, or tool usage are a separate concern, covered in budgets vs rate limits and threat modeling runaway agent spend.