AP2 and the agent payments protocol, explained

What problem AP2 is trying to solve

Traditional online checkout assumes a person is present to select a product, review the final amount, authenticate, and approve the payment. An agent-led journey can split those moments across different systems and times. The user may give a broad instruction first, while the agent discovers a merchant and assembles a cart later.

That creates a proof problem. A merchant or payment participant needs to know which agent is acting, whether the user delegated the task, what constraints were granted, and whether the final checkout still matches that authority. AP2 makes those claims portable and verifiable.

The protocol does not make model output authoritative. The official AP2 specification explicitly requires deterministic code for validation or processing performed by a role.

The AP2 mandate types

AP2 supports different journeys. In a human-present flow, a person can review a completed checkout before signing. In a delegated flow, an earlier intent can define what the agent may pursue, and later evidence can show that the resulting checkout remained within scope.

One AP2-style journey

1. 01Delegate intentA company authorizes an agent to renew approved software within a defined limit and time window.
2. 02Build checkoutThe shopping agent finds the renewal and obtains merchant-signed checkout details.
3. 03Evaluate constraintsDeterministic code verifies identity, scope, amount, merchant, expiration, and any required human review.
4. 04Bind authorizationThe checkout and payment mandates are signed and tied to the specific checkout rather than a reusable vague instruction.
5. 05Verify and respondRelevant participants verify the mandate and return signed receipts for acceptance or rejection.

The cryptographic details matter because they reduce ambiguity and replay. A permission for one checkout should not become a transferable approval for a different merchant, cart, or amount.

AP2, UCP, A2A, and MCP are not the same thing

These protocol names appear together because agent systems often need several kinds of interoperability. They solve different problems.

• AP2 carries authorization and payment-related mandate evidence.
• UCP provides a shared language for commerce capabilities and checkout journeys.
• A2A helps agents communicate and coordinate tasks with other agents.
• MCP helps models and agents connect to tools, data, and external capabilities.

Google's developer guide to AI-agent protocols explains the division succinctly: commerce protocols can handle what is being ordered, while AP2 adds evidence about who approved it and the applicable guardrails.

AP2 does not replace internal authorization policy

Protocol evidence must originate from an actual authority decision. A small business still needs a source of truth for which agents exist, their status, budgets, approval thresholds, permitted categories, merchant rules, countries, and expiration. It also needs roles for the people allowed to change those rules.

An internal authorization layer can evaluate those facts and produce a decision. AP2 can then help represent and convey appropriate proof to other parties in the commerce and payment flow. The two layers answer connected but distinct questions: internal policy decides whether the business permits the action; protocol mandates help other participants verify the relevant delegation and transaction binding.

What a serious implementation must verify

• The signer, agent, user, merchant, and payment participants have authenticated identities.
• The mandate type and schema version match exactly what the verifier supports.
• Signatures, keys, timestamps, expiration, audience, and replay protections are valid.
• The mandate is bound to the intended checkout, amount, currency, merchant, and operation.
• The underlying business policy still has sufficient budget and has not been paused, revoked, or superseded.
• Receipts preserve the outcome without rewriting the original request or authorization evidence.

Where human approval belongs

Human review should occur before an authorization is signed or released when a rule requires it. Examples include a new merchant, an amount above an autonomous threshold, a category exception, or elevated risk.

The reviewer needs the final checkout facts and the policy evidence—not only an agent-generated summary. Approval should be scoped to the specific request unless the person separately changes the standing policy. This prevents one exception from silently becoming a broad permission.

How AP2 relates to Mandate

Mandate's terminology shares an architectural idea with AP2: agents should operate under explicit, inspectable authority. Mandate currently implements its own simulated business authorization workflow; it is not an AP2 implementation and does not claim protocol interoperability.

A future adapter could map an approved internal decision into the appropriate protocol artifact, provided the integration follows the live specification, cryptographic requirements, identity model, and participant obligations. Until then, it is important to distinguish architectural compatibility from a working integration.

For the broader category, start with how agentic payments work. For the internal control object, read what an AI-agent payment mandate contains.