Definition
AP2, the Agent Payments Protocol, is an open protocol introduced by Google with industry partners for authorizing AI agent payments. It uses cryptographically signed mandates as verifiable credentials to prove a payment was authorized by the user, and is designed to be payment-method-agnostic, spanning cards, bank transfers, and crypto. It complements settlement protocols like x402 rather than replacing them.
Put plainly, AP2 is about authorization, proving that an agent's payment was genuinely approved by the person on whose behalf it acts, in a way any counterparty can verify and that works across payment types. Because it is an evolving open protocol, the authoritative description lives in its public specification, and the details here are at the level of its public positioning, which you should confirm against the current spec. The concept worth taking away is that AP2 addresses the trust-and-authorization question for agent payments, distinct from the question of how the money actually moves.
What problem it addresses
AP2 addresses a specific problem in agentic commerce: how does a merchant or counterparty know that an agent's payment was actually authorized by the user, and not the result of an agent acting beyond its remit or being manipulated? As agents begin to transact on people's behalf, this authorization question becomes central, because the counterparty cannot see the human and must rely on the agent's claim of authority.
AP2's answer is to make authorization verifiable. Rather than trusting an agent's assertion that the user approved a purchase, AP2 captures the user's authorization as a signed mandate that the counterparty can check cryptographically. That turns who approved this into something provable rather than asserted, which is what a merchant needs before fulfilling an agent-initiated purchase. The problem AP2 tackles is therefore trust in the authorization of agent payments, which is adjacent to but distinct from the mechanics of settling them.
How it works
At a high level, AP2 works by representing a user's authorization as signed mandates that act as verifiable credentials. Public descriptions of the protocol discuss capturing intent and the specifics of a purchase as distinct signed artifacts, so the chain of authorization from the user's intent through to a concrete transaction can be verified. A counterparty receiving an agent payment can check these credentials to confirm the payment was authorized as claimed.
Because this is a verification-and-authorization layer, it is designed to be payment-method-agnostic: the same authorization model can sit in front of card payments, bank transfers, or crypto settlement. That separation, authorization handled by AP2, settlement handled by whatever rail, is a deliberate design choice that lets AP2 work across the payment landscape. For the exact structure of its mandates and message flow, the current AP2 specification is the authoritative source, and since the protocol is evolving, it is the place to confirm specifics rather than relying on a summary.
AP2 and x402
AP2 and x402 are best understood as addressing different layers, which is why they can work together rather than compete. x402 is a settlement protocol: it defines how a client pays for a request over HTTP, commonly settling stablecoins, answering how the money moves. AP2 is an authorization protocol: it defines how a payment is proven to be authorized by the user, answering whether the payment was approved and by whom.
Because AP2 is payment-method-agnostic and includes support for crypto, an AP2-authorized payment can settle through a crypto rail, which is where a protocol like x402 fits. In that arrangement, AP2 carries the verifiable authorization and x402 carries the stablecoin settlement, each doing the layer it is built for. So rather than asking AP2 or x402, the more accurate framing is often AP2 for authorization and x402 for settlement, with the two composing. For what x402 itself is, see what-is-x402, and confirm AP2's crypto specifics against its current spec.
AP2 and payment mandates
AP2 is a concrete, formalized expression of the payment-mandate concept. A payment mandate, in general, is delegated, bounded authorization to pay on a principal's behalf. AP2 takes that idea and makes it cryptographically verifiable: the user's authorization is captured as signed mandates that serve as credentials a counterparty can check, rather than as a private setting only the platform knows about.
So if you understand payment mandates, AP2 is in large part a standardized way to represent and verify them across parties. The general concept answers what is the agent authorized to do; AP2 answers how do we prove and verify that authorization in an interoperable way. This is why the two terms appear together: the mandate is the idea, and AP2 is one prominent protocol for expressing it as verifiable credentials in agentic commerce. For the underlying concept, see what-is-a-payment-mandate.
Why it matters
AP2 matters because authorization is one of the hard problems of agentic commerce, and a shared, open way to handle it lowers the barrier for agents and merchants to transact. If every platform invented its own way to prove an agent's payment was authorized, counterparties would face a patchwork; an open protocol backed by many partners offers a common approach instead, which is how ecosystems tend to scale.
It also matters because it clarifies the layering of agent payments. By focusing on authorization and being payment-method-agnostic, AP2 helps separate the question of who approved a payment from how it settles, which makes the whole stack easier to reason about. For builders, the practical takeaway is that AP2 addresses the authorization layer and can coexist with a settlement protocol like x402, so the two are complementary tools rather than competing choices. As always with an evolving open protocol, treat its specifics as something to verify in the current specification rather than fixed.
Where Blockchain0x fits
It is worth being clear about how a settlement-focused platform like Blockchain0x relates to AP2, since the two operate at different layers. Blockchain0x is about settlement and per-agent control: an agent pays per call in USDC over x402, bounded by a server-side spend limit, with a verifiable identity. AP2 is about authorization: proving, across payment methods, that a payment was approved by the user. These are complementary concerns, not competing products.
In a stack that uses both, AP2-style verifiable authorization could establish that an agent's payment is approved, while the actual stablecoin settlement happens over x402 on a platform like Blockchain0x, and a spend limit bounds the agent regardless. So adopting x402 settlement does not put you at odds with AP2; the authorization layer and the settlement layer are designed to coexist. As AP2 evolves, the practical question for a builder is which layer a given tool addresses, and to compose the authorization and settlement pieces that fit, rather than expecting one protocol to do everything.
Related terms
AP2 connects to several concepts. A payment mandate is the underlying idea AP2 formalizes as verifiable credentials. x402 is a settlement protocol AP2 can work alongside for crypto payments. Agentic commerce is the broader setting both serve. Agent payment identity is the related question of who an agent is, distinct from what it is authorized to do, which AP2 addresses.
Understanding AP2 helps you place the authorization layer of agent payments, distinct from settlement and identity. For the underlying concept it formalizes, see what-is-a-payment-mandate; for the settlement protocol it can compose with, see what-is-x402. For Blockchain0x specifically, payments settle over x402 in USDC, and the pricing is on the pricing page.