What AP2 is designed to solve
Traditional payment systems assume a person is directly present at checkout. When an agent acts between the person and merchant, participants need evidence that the agent’s action reflects authentic instructions and that the final transaction stayed within them.
AP2 addresses authorization, authenticity, and accountability with cryptographically signed mandates. It is payment-method-neutral and is described for use with cards, stablecoins, and real-time bank payments. It does not itself replace those rails.
Intent, transaction, and receipt evidence
An intent mandate records what the user wants the agent to accomplish and can include limits such as merchant, price, timing, and approval conditions. A transaction-specific mandate binds approval to the exact cart or payment details. A payment receipt preserves the outcome produced by the payment system.
The value is the evidence chain: the merchant or payment participant can verify that the transaction is connected to user instructions instead of trusting a free-form agent message.
A signed mandate proves defined authority; it does not prove that fulfillment occurred.
Human-present and delegated operation
When the user is present, the agent prepares the purchase and the user signs or confirms the final transaction. When the user is absent, a prior mandate supplies bounded delegated authority. The agent can act only while the proposed transaction remains inside the encoded constraints.
Delegated operation increases the importance of revocation, expiry, risk-based step-up, and exact transaction binding. The mandate should not become a standing blank check.
How AP2 composes with the rest of the stack
Google’s protocol guidance distinguishes commerce state from payment authority. UCP can represent products, carts, and orders; AP2 answers who approved the action and supplies the audit trail. AP2 can also extend agent interoperability patterns such as A2A and MCP.
A production integration still needs principal authentication, agent identity, merchant and order state, a payment adapter, settlement verification, fulfillment events, refunds, disputes, and internal reconciliation.
Adoption questions to ask now
AP2 is evolving. Pin the schema and SDK versions you implement, validate signatures and expiry, publish interoperability tests, and avoid hard-coding the protocol directly into internal business objects. Track which partners actually accept or emit the relevant artifacts in production.
- Which mandate types and schema versions are supported?
- Who signs as principal, agent, merchant, and payment participant?
- How are keys discovered, rotated, and revoked?
- Which order fields are cryptographically bound?
- How is the receipt reconciled to the merchant order and rail record?
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.