What is AP2?
AP2, the Agent Payments Protocol, is an open standard that lets an AI agent prove it was authorized to make a specific purchase. It does that with mandates: cryptographically signed credentials that record what a person agreed to, signed on a surface the person actually saw, and passed along with the transaction so the merchant, the processor and the card network can each verify them independently. The problem it exists to solve is stated plainly in the spec: today’s payment systems assume "a human user directly interacting with a trusted interface", and "autonomous agents shatter this assumption". Once software is doing the buying, every party downstream faces the same four questions. Was this agent authorized? Is the request authentic? What happens when the agent gets it wrong? And who is accountable? AP2 is an attempt to answer those with evidence rather than trust.
Who created Google AP2, and when?
Google announced AP2 on September 16, 2025, alongside more than 60 payments and technology organizations. It is open source under Apache 2.0, with the specification at ap2-protocol.org and code samples, a Python SDK and demos in the google-agentic-commerce/AP2 repository on GitHub. The more important date for anyone evaluating it is April 28, 2026, when Google donated AP2 to the FIDO Alliance and published version 0.2 at the same time. Mastercard donated its AP2-compatible Verifiable Intent standard in the same announcement. Core specification work now happens in FIDO’s agentic authentication and payments technical working groups, which is Google’s way of saying the protocol is meant to outlive its author. That handover is the reason AP2 is worth taking seriously as a standard rather than as one vendor’s framework, and it is also why a lot of the AP2 material online is now out of date.
What are AP2 mandates?
This is where most AP2 explainers are wrong, and it is worth being precise. The September 2025 launch blog described two mandates: an Intent Mandate capturing what you asked for, and a Cart Mandate capturing your approval of a specific cart. Almost every article written about AP2 since then repeats that pairing, because almost every article is a rewrite of that blog post. The specification has moved on. As of version 0.2 the model is a Checkout Mandate, which authorizes the completion of a checkout, and a Payment Mandate, which authorizes the payment for that checkout. Each exists in an open and a closed variant, identified by a credential type claim: mandate.checkout.1 and mandate.checkout.open.1, mandate.payment.1 and mandate.payment.open.1. Both are verifiable digital credentials, meaning tamper-evident signed objects that chain together so anyone holding the set can reconstruct exactly who agreed to what. If you are reading a guide that still frames AP2 around intent and cart, it is describing the protocol as it looked at launch, not as it is specified today.
What is the difference between an open and a closed mandate?
A closed mandate is fully specified. A closed Checkout Mandate wraps a merchant-signed checkout as a JWT plus a hash of it, so the order is pinned to exactly those items at exactly that price. A closed Payment Mandate names the transaction, the payee, the amount and currency, and the payment instrument. Nothing is left to interpretation. An open mandate carries constraints instead of specifics: which merchants are acceptable, which line items qualify, what amount range is permitted, whether the authorization may recur. The open variant is what makes delegated buying possible. You sign the constraints while you are present, and later, when the conditions are met, a closed mandate is generated inside those constraints without you being there. The two are cryptographically bound, so a closed mandate cannot quietly exceed the open one it claims to derive from. That binding is the clever part of the design and the reason AP2 is more than a signed receipt.
How does the AP2 protocol work?
Six roles appear in the spec. The Shopping Agent discovers products, builds the checkout and executes the purchase. The Merchant owns the catalog and fulfills the order. The Merchant Payment Processor processes the payment and checks that the credential was authorized for this checkout. The Credential Provider verifies the agent may use a given payment credential and scopes it appropriately. The Trusted Surface is the interface trusted to obtain informed consent from the person before any user-signed mandate exists. The Network and Issuer provide the rails and issue the credential. With a human present the flow is short: the agent assembles a cart, the merchant signs the checkout, the agent builds both mandate contents and asks for approval, the Trusted Surface renders them and signs both with the user’s key, the Credential Provider verifies the Payment Mandate and returns a token, and the merchant and processor each verify the mandates and the hash binding them before money moves. Every party checks the evidence rather than taking the agent’s word for it.
How does AP2 handle a purchase when nobody is watching?
Version 0.2 added the human-not-present flow, which is the case most businesses actually care about. Up front, while the person is there, the Trusted Surface signs open Checkout and Payment Mandates that describe the boundaries of what may happen later, and the agent’s public key is recorded so only that agent can act on them. The person leaves. When a matching opportunity appears, the agent assembles a cart, picks the open mandates whose constraints the checkout satisfies, and signs the corresponding closed mandates with its own key. A selective-disclosure hash binds each closed mandate to the open one it came from, so the merchant and the processor can verify both that the user authorized the boundaries and that the agent stayed inside them. It is a genuinely good design for the problem it is scoped to. The limitation is the scope, and it is worth reading the next section before assuming this covers your risk.
Who are the AP2 partners?
Google published more than 60 collaborating organizations at announcement, and the list is unusually broad for a protocol that launched with no shipping product. It spans networks and issuers (Mastercard, American Express, JCB, UnionPay International), processors and acquirers (Adyen, Worldpay, Checkout.com, Payoneer, dLocal, EBANX), wallets and fintechs (PayPal, Revolut, Airwallex, Intuit), enterprise software (Salesforce, ServiceNow, Adobe, Dell), marketplaces (Etsy, Shopee), risk (Forter, Okta, 1Password), and crypto infrastructure (Coinbase, Mysten Labs, MetaMask, Lightspark, BVNK). Treat that list as directional rather than as a roster of live integrations. Endorsing a specification at launch and shipping it in production are different commitments, and in August 2026 the honest summary is that AP2 has strong institutional backing and a thin production footprint.
What is the difference between AP2 and UCP?
They are complementary layers, and the spec is explicit about which to reach for. The Universal Commerce Protocol orchestrates the broader purchase lifecycle and is what you implement for inline checkout on Google’s AI surfaces. AP2 is the narrower payment-authorization layer, and it is what you reach for when an agent buys autonomously, when two agents transact with each other, or when you want verifiable credentials on transactions happening outside Google’s surfaces. AP2 is described as an extension for A2A, MCP and UCP rather than a competitor to any of them. In practice a full stack can carry all of it: UCP or the Agentic Commerce Protocol to complete the checkout, AP2 to prove the buyer authorized it. We compare all three standards side by side, plus x402, in AP2 vs ACP vs x402.
Does AP2 work with x402 and stablecoins?
AP2 is deliberately payment-agnostic. The specification’s initial focus is on pull payment methods, meaning credit and debit cards, with e-wallets, push payments such as real-time bank transfers, and digital currencies on the roadmap. Google’s launch material described support ranging from cards to stablecoins and real-time bank transfers, and crypto partners were involved from day one, which is unusual for a protocol coming out of a payments incumbent. On x402 specifically, the two are complementary rather than competing: x402 is an HTTP-native settlement scheme for small, high-frequency machine payments, while AP2 is an authorization layer that can sit above whichever rail settles the money. An x402 extension for A2A exists separately and closer alignment is planned. The useful mental model is that x402 answers how value moves and AP2 answers who said it could.
Does AP2 limit how much an agent can spend?
Not in the way a finance team means it. An open Payment Mandate can carry an amount range and recurrence rules, and an open Checkout Mandate can restrict acceptable merchants and line items, so each authorization has a ceiling. What the protocol does not do is keep a running total. Nothing in AP2 tracks cumulative spend across several open mandates, across the fleet of agents your company runs, or across the rails your agents touch that never go anywhere near AP2. The spec is candid about where that responsibility lands: to prevent double spending, the Shopping Agent "MUST NOT create multiple overlapping Mandates until it receives an Action Receipt indicating an error". That is a correctness requirement placed on the exact component you were trying to constrain. It is the same structural gap you find in x402, where the seller caps one call and nothing tracks the total, and in scoped checkout tokens, which cap a single transaction. Twenty individually compliant purchases still add up to a number nobody approved.
What AP2 does not cover, and what you still have to build
AP2 is written around a shopper. The roles are a Shopping Agent, a Trusted Surface where a person consents, and a Credential Provider holding that person’s instrument. Map that onto a company running agents in procurement, infrastructure or ad buying and several things have no home. There is no notion of an organizational policy that says this agent may spend five thousand dollars a month across any merchant and anything above five hundred routes to a named approver. There is no cross-agent budget, no approval workflow for the exceptions, no single audit trail spanning card, stablecoin and invoice spend, and no answer for the agent that never touches AP2 at all because it is calling a metered API. Those are policy-plane concerns, and AP2 is a protocol, not a policy plane. It was never trying to be one. The mistake is assuming a signed mandate is a budget.
Should you implement AP2 today?
Adopt it if you are a merchant, processor or credential provider who will need to verify agent-initiated purchases, because the FIDO handover makes AP2 the most likely candidate for the authorization layer and building against a moving Google project is riskier than building against a FIDO working group. Watch it, rather than build on it, if you are a business deploying agents that buy things: as of August 2026 the production footprint is thin, most of your agents will be paying over ordinary card rails and metered APIs for a while yet, and AP2 support will arrive through your processor rather than through code you write. In either case do not wait on the protocol to answer the budget question, because it is not scoped to. Set per-agent limits, route exceptions to a human and record every decision at the layer that issues credentials, and AP2 becomes one more verifiable input to a control plane you already run.