Skip to main content
LearnGlossaryAP2 protocol
GLOSSARY

What is AP2 protocol.

DEFINITION

AP2 is Google's Agent Payments Protocol, an open specification for how AI agents pay merchants programmatically. It standardizes three pieces: how a user grants a payment mandate, how an agent presents that mandate to a payment processor, and how the settlement happens across whatever rail the merchant accepts. AP2 sits at the mandate layer; the underlying rails can be fiat or stablecoin.

WHY IT MATTERS

Google's agentic-commerce wager.

AP2 is Google's bet on the agentic-commerce category. Where Coinbase's x402 takes a per-call HTTP approach, AP2 takes a mandate-based approach: pre-authorize the agent for an envelope of payments, then let it execute within that envelope without further user involvement. The two protocols target slightly different shapes of agent activity. x402 fits per-API-call billing; AP2 fits agent-driven shopping, subscriptions, and procurement.

For developers, AP2 matters because it is the first agent-payment protocol from a hyperscaler with the distribution to mainstream-adopt it. If Gemini agents (consumer and enterprise) and Google Pay merchants both speak AP2 natively, then "agent paying via Google Pay" becomes a default capability rather than a custom integration. The stack rapidly expands beyond the developer-tooling ecosystem.

HOW IT WORKS

Mandate, presentation, settlement.

  1. Mandate grant. The user authorizes the agent via Google's mandate UI (in Wallet or via a developer surface for enterprise). The mandate specifies max amount, frequency window, allowed recipients or recipient categories, and an expiration.
  2. Mandate presentation. When the agent needs to pay, it bundles the mandate into the payment request to the merchant's processor. The processor validates the mandate's signature and parameters; if the request fits, the payment proceeds.
  3. Settlement. The actual settlement happens over the merchant's rail of choice (Google Pay, a card network, ACH, stablecoin). AP2 is settlement-agnostic; what it standardizes is the agent's authorization to draw against the user's account.
  4. Audit and revocation. Every payment against the mandate is logged. The user can revoke the mandate from their wallet at any time. Subsequent presentations fail validation; in-flight settlements at the moment of revocation may or may not complete depending on the rail.
EXAMPLES

Where AP2 fits.

EXAMPLE 1

Agent paying via Google Pay rails

A Google-stack agent (running inside Gemini, Agentspace, or Vertex AI) presents an AP2 mandate to a merchant's processor. The processor validates the mandate, settles the payment over Google Pay's existing rails, and returns confirmation. The merchant's integration is identical to a normal Google Pay transaction; the difference is on the buyer side, where the agent stood in for a human.

EXAMPLE 2

Cross-protocol agent commerce

An agent has an AP2 mandate for fiat payments through Google Pay AND a Blockchain0x wallet for USDC payments on Base. When it needs to pay a merchant that takes both, it picks the rail with lower fees for that transaction shape. The user granted both authorizations once; the agent routes per-payment.

EXAMPLE 3

Enterprise procurement via AP2

A corporate procurement agent has an AP2 mandate from the finance team authorizing payments up to $10,000/month to a defined supplier allowlist. The agent processes purchase orders, validates against the mandate, and settles payments without a human approving each one. The audit trail (mandate plus per-payment events) goes into the company's ERP system.

FAQ

Three common questions.

Is AP2 a competitor to x402, or do they coexist?

They coexist, with overlapping but distinct design choices. AP2 is mandate-based: the user pre-authorizes a payment envelope, and the agent draws against it. x402 is request-based: the merchant returns 402 with a payment URL, and the agent pays per-call. AP2 fits subscription and recurring patterns better; x402 fits per-call and pay-as-you-go patterns better. A sophisticated agent can use both protocols depending on the payment shape. We expect both to be production-grade by mid-2026.

Does AP2 require crypto, or does it work on traditional rails?

Works on traditional rails. AP2 is rail-agnostic; the protocol specifies how the mandate is granted, presented, and validated, not how the underlying settlement happens. Google's reference implementation targets Google Pay (cards, bank transfers, regional payment methods). Independent implementations could settle on stablecoins. In practice, AP2 deployments today are predominantly fiat-rail because Google's ecosystem leans there.

Does Blockchain0x support AP2?

Not yet. Our current spend-control model (a per-agent per-period allowance and a per-transaction cap, enforced at the API layer) is mandate-equivalent for the common cases but does not implement the AP2 wire protocol. Formal AP2 support is on the roadmap once the spec stabilizes and adoption signals are clearer. In the meantime, the gap between our approach and AP2 is the formal mandate document the agent carries; the policy outcomes are very similar.
Last reviewed: 2026-05-15. Published under CC BY 4.0.

Build your agent's payment surface today.

AP2 support is on the roadmap. The core capabilities (mandate-equivalent spend controls, per-agent identity, audit logs) are live now.