AP2: Google’s trust-and-consent layer for AI checkout

The week AI checkout got real

In mid-September 2025, Google unveiled the Agent Payments Protocol, or AP2, as an open standard for agent-led checkout. The goal is simple and ambitious at once: give AI agents a secure, interoperable way to prove what a human actually wanted to buy, how they consented, and who is accountable when something goes wrong. The reference implementations and docs dropped publicly in a new GitHub organization, a clear signal that this is meant to be built in the open rather than locked to one product stack. You can explore the sample scenarios and core types in the AP2 repository on GitHub.

The pitch lands at the right moment. Agents are finally useful at shopping tasks. They can watch prices, juggle constraints, compare specs, and place orders. What they cannot do safely at scale is press the buy button like a human and expect the payments ecosystem to accept the outcome without friction or doubt. AP2 is Google’s bid to add the missing trust and consent layer so agents can transact across card rails, bank transfers, and crypto without bespoke side agreements.

Why payments need a trust and consent layer for agents

Today’s ecommerce stack assumes a human is in the loop. The buyer fills the cart, chooses a method, passes risk checks, maybe completes a step-up challenge, and clicks pay. Liability, dispute rights, and fraud controls all hinge on that handoff. Agents break this assumption. A model may decide to check out later, on a different site, under a condition the user set earlier. The traditional breadcrumbs of intent and consent are not enough. Merchants cannot tell if a purchase was truly authorized by the user. Issuers cannot reason about whether a transaction is human-present or a delegated action. Wallets cannot enforce the right limits and revocations because the consent record is not portable.

AP2 tries to fix those gaps with a portable, cryptographically verifiable record of what was intended, what was approved, and how the payment should be treated. The aim is not to replace rails. It is to standardize the proof that a human asked an agent to act, and that everyone down the line can validate that proof.

What AP2 actually proposes

At the core are signed digital mandates that travel with the transaction:

Intent Mandate: a structured, signed snapshot of what the user asked for. It captures context such as product class, constraints, timing, and price caps.
Cart Mandate: a signed approval of a specific basket as assembled by an agent. It links back to the intent and locks key details like items, quantities, total, and allowed payment rails.
Payment Mandate: a signed signal meant for wallets, networks, and issuers that indicates an agent is involved, whether a human is present at approval time, and what risk posture applies.

These mandates are tamper evident and reference each other to form an auditable chain from the user’s initial instruction to the final payment. They are designed to be exchanged between agents, merchants, and wallets using existing security primitives and standard transports. Importantly, AP2 models two common flows:

Human present: the agent assists in discovery and assembly, then the person reviews a cart and signs a mandate on device.
Delegated: the user pre-approves conditions and limits. The agent executes later when those conditions are met, carrying the signed rules and proofs forward.

On purpose, AP2 is rail agnostic. Card payments, instant bank transfers, and crypto settlement can all slot underneath. The protocol concerns itself with the trust contract carried above the rails, not the rails themselves.

AP2, A2A, and MCP: interoperable rails, different jobs

AP2 sits alongside two other fast-emerging pieces of the agent stack:

A2A, the Agent2Agent protocol, defines how agents discover each other, advertise capabilities, and converse or negotiate as peers. AP2 can use A2A for discovery and messaging between a shopping agent and a merchant checkout agent, or between a buyer agent and a wallet agent.
MCP, the Model Context Protocol from Anthropic, standardizes how agents connect to tools and data. MCP is what your buyer agent might use to call price trackers, inventory systems, or delivery APIs while building a cart.

In a typical agent checkout, MCP powers tool use during research, A2A handles the agent-to-agent negotiation in checkout, and AP2 furnishes verifiable intent and consent that the payments stack can trust. This division of labor is deliberate and practical. A2A is already moving to neutral governance, with Google donating the spec and SDKs to the Linux Foundation this summer, which strengthens the case for real interoperability across vendors. See the announcement in A2A Linux Foundation donation. That shift aligns with the broader runtime consolidation we tracked in Gemini as default runtime.

What this could unlock

For retailers

Faster, consistent agent checkout: accept signed mandates from buyer agents and reduce brittle scraping and autofill hacks.
Lower abandonment: let agents handle comparison shopping and couponing while giving humans a single, portable consent moment.
New traffic sources: marketplace agents, OEM assistants, and superapp agents can become new top-of-funnel channels that still end in your native checkout, not a reseller.
Better fraud signals: human-present vs delegated flags, mandate provenance, and revocation status should reduce false positives while catching genuine abuse.

For wallets

Agent-native consent: richer UI for limits, categories, and time windows. Mandates make delegated spending safe to implement without awkward one-off controls.
Multi-rail orchestration: route transactions to cards, bank rails, or on-chain settlement while preserving a consistent consent record.
Smarter risk: treat agent-initiated payments differently, with mandate type and signature strength as first-class features in decisioning.

For issuers and networks

Clearer liability posture: mandate types can map to new transaction indicators so rules can evolve beyond binary card-not-present.
Step-up that fits agents: when challenges are needed, bind them to the mandate chain rather than the ephemeral web session.
Dispute clarity: signed context reduces he said she said, and issuers can request the same structured record across merchants.

Where the gaps remain

Identity

Who is the human behind the agent, and how do we bind their identity to the device and the agent runtime without over-collecting PII? AP2 assumes verifiable credentials, but the issuance, storage, and recovery mechanics are still work in progress for most wallets and platforms.

Liability

Mandates improve evidence, not laws. Networks, acquirers, and issuers will need to publish rule updates that clarify fault lines when an agent buys the wrong SKU, violates a user’s cap, or misreads availability. Expect transitional rules and carve-outs before a clean steady state emerges.

Dispute flows

Reason codes and representment packages need to absorb agent context. Merchants will need SDKs to fetch and package the right mandate chain. Issuers will need training and tooling to interpret it. This is nontrivial work.

User experience

Consent cannot become a nag storm. Wallets have to craft simple controls that feel like card controls grew up for agents: per-merchant caps, category caps, spend windows, and easy kill switches. The signature gesture should be familiar, and revocation must feel immediate.

How AP2 differs from today’s human-in-the-loop payments

Consent that travels: today’s consent is a web session and a click. With AP2, consent is a signed object that moves with the transaction and can be verified by any party.
Delegation with constraints: people can safely grant autonomy with caps and conditions because those rules are encoded and signed, not implied in chat logs.
Presence made explicit: risk systems can see whether the human was present at approval time. That unblocks new decisioning tiers beyond one size fits all card-not-present.

How incumbents might respond

Networks

Expect new indicators for agent involvement, guidance on interpreting mandate types, and pilots that treat agent-present transactions with more nuance than legacy 3DS flags. Tokenization will remain the default on cards to keep PANs out of agent runtimes.

Wallets

Google Pay and PayPal are natural first movers to expose agent controls in consumer UIs. Apple will likely take a risk-first stance and enter when liability and privacy are crisp. Crypto wallets have an opening to showcase x402 style flows for on-chain settlement, but they will still need friendly consent UX.

Acquirers and PSPs

Merchant SDKs are the kingmaker. PSPs that ship drop-in libraries to ingest mandates, verify signatures, and translate them into existing gateway fields will control early adoption. They can also monetize value-added risk features around mandates.

Merchants

Early wins will be in categories with high consideration and time sensitivity: tickets, travel, high stock volatility retail. Merchants will run dual-path checkouts where agent flows are AP2-native and human flows remain unchanged. Expect aggressive A B testing on abandonment and fraud.

Regulators

AP2 lines up conceptually with the idea of strong customer authentication and dynamic linking. But mapping mandates to local obligations will take formal work. In the US, ACH and card disputes will need clarifications on agent delegation and error resolution rights.

A builder’s guide to experimenting safely

What to clone and run

Pull the AP2 repo and start with the human-present card scenario. That path walks through generating an intent mandate, assembling a cart, and signing a cart mandate with a simple wallet agent. The sample includes a merchant agent and a mock checkout.
Try the delegated scenario. Set a spend cap and a time window, then let the buyer agent execute when conditions are met. Inspect the full mandate chain your merchant receives.
Explore the crypto sample if you are comfortable with on-chain testnets. It shows how an AP2 mandate can accompany an on-chain settlement without mixing concerns.

How to wire it into your stack

Merchant integration: place a checkout agent service behind your existing checkout. It should verify incoming intent and cart mandates, enforce your own policy, and translate approval to your PSP’s API. Keep a copy of the mandate chain for disputes and analytics.
Wallet integration: build a consent UI that treats mandates like recurring controls, not just one-off approvals. Offer caps by merchant, category, and time. Surface a clear kill switch.
Agent integration: your buyer agent should use MCP for tools and A2A for peer negotiation. Isolate payment logic into a dedicated module that never handles raw PANs and never caches secrets. For security considerations, see our guide on securing agentic AI.

Compliance mapping you can do today

PCI DSS: if you accept cards, keep PANs out of your agents and out of your own services. Use tokenized credentials from wallets or your PSP. AP2 does not change scope by itself, but it makes it easier to architect agents that never touch card data.
Strong Customer Authentication: treat mandate signing as your primary SCA event. Bind a challenge or biometric to the mandate and ensure the signed object includes amount and payee so you meet dynamic linking principles. For delegated flows, require SCA at setup and make limit bumps an SCA event.
Record keeping and disputes: store the full mandate chain and signature verification logs. Build a simple API to retrieve them by transaction ID so your PSP or issuer partners can request them during disputes.

Guardrails to design before pilots

Spend governance: implement caps, time windows, and SKU or category constraints. Express them in policy that your agent can check locally before proposing a cart. Align the UI with your policy so users see exactly what will be enforced.
Human-in-the-loop hooks: for higher risk categories, require an out-of-band nudge before the cart mandate is signed. Keep it one tap.
Revocation and recovery: design instant revocation for a mandate and a visible ledger of agent actions. Offer an obvious pause all agents control.
Injection and spoofing defenses: treat mandate payloads like any external input. Validate schemas, check signatures, verify issuers, and pin trusted keys where possible. Log every verification event.
Observability: trace every mandate step with correlation IDs that tie intent, cart, and payment together. Use these spans to debug early false declines and CX breakage.

A 6 to 12 month outlook

Real talk: this is day one. AP2’s design is thoughtful, but adoption will depend on three hard things happening at once: wallets shipping agent-native controls, networks publishing rule updates that recognize mandate context, and PSPs delivering merchant SDKs that hide complexity.

What to watch between now and mid 2026

Pilot coverage: number of pilots, industries involved, and whether they are human-present, delegated, or both. Track geographic spread and any public regulator engagement.
Wallet support: which consumer wallets and crypto wallets expose agent controls and support mandate signing in production. Look for spend caps, category caps, and revocation UX.
Merchant SDKs: availability from major PSPs and gateways. Quality matters: one call verify mandate, one call authorize, all in your language of choice.
Network rule bulletins: updates that introduce agent-present indicators, recommended treatment, and liability guide rails.
Issuer readiness: number of issuers capable of parsing mandate context in risk engines and disputes. Early parity with existing 3DS signals would be a big step.
Fraud and chargeback deltas: in pilot cohorts, watch for false positive reductions and any spike in new failure modes like mandate spoofing. The early goal is lower abandonment without a fraud penalty.
Consent completion rate: how often human-present flows reach cart mandate signature on the first try. If this stalls, iterate UX fast.
Dev momentum: stars and commits on the AP2 repos, volume of issues and PRs, and new community samples that exercise more rails and geographies.

Bottom line

AP2 does not magically solve agent payments. It gives the ecosystem a clean place to stand and a language to agree on. If wallets, PSPs, and networks meet in the middle, agent-led checkout can move from demos to durable growth channels. If they do not, agents will keep filling carts and running into brittle paywalls. The next year is about proving that a portable proof of human intent can lower risk and friction at the same time. If that happens even in a few categories, adoption will compound quickly. For the broader shift to at-scale agent commerce, track progress in cloud-scale agent operations.