Every payment system in use today quietly assumes a human is present at the moment of purchase — standing at a terminal, or at least sitting at a keyboard clicking Buy. AP2, Google’s Agent Payments Protocol, exists because that assumption stops holding the instant an AI agent does the shopping. When software initiates the transaction, the questions the payments industry has spent fifty years answering — who authorized this, what did they agree to, and who pays when it turns out they didn’t — all lose their usual answers at once. AP2’s response is a single primitive: the mandate, a signed, verifiable statement of what the user actually authorized, produced before the agent goes shopping and carried alongside the payment. This article is the map: the problem, the primitive, the cast of parties, where AP2 fits among the rails it rides on, and what is genuinely unsolved.

The cardholder is not at the keyboard

Card payments are sorted into two worlds. Card-present transactions happen with the physical card and usually the cardholder at a terminal; the chip and the PIN are evidence that the right person was there. Card-not-present covers everything remote — e-commerce, phone orders — where that evidence is missing, so the ecosystem substitutes for it: address checks, card security codes, device fingerprints, 3-D Secure step-up challenges, and a fraud model leaning heavily on the observation that a human sat at a browser and behaved like one.

An agent-initiated purchase fits neither box. The card is not present. Nor is the classic card-not-present picture, because there is no browser session, no human typing rhythm, no device the issuer has seen before, and often no fixed price or basket when consent was given. To a fraud engine, a competent shopping agent looks exactly like a competent bot attack. Declining every such transaction is safe and useless; approving them blindly is neither. The industry needs a third category, and something to put in it.

Advertisement

What AP2 is, and what it deliberately is not

AP2 is an open protocol for authorizing and evidencing payments that an agent initiates on a user’s behalf. Google introduced it with a broad group of payments and technology partners, designed as an extension to the agent-interoperability stack: it composes with A2A for agent-to-agent communication and with MCP for tool access rather than inventing a parallel messaging world.

What it is not matters just as much. AP2 is not a payment rail: it does not move money, hold funds, clear, or settle. It is not a wallet, not a processor, not a replacement for your acquirer, and it defines no new fraud scoring or dispute rights. It is a thin, rail-agnostic consent and evidence layer sitting above whatever instrument you were already going to use, answering one narrow question in a machine-verifiable way: what did the human agree to, and can anyone downstream check that claim without taking the agent’s word for it?

Mandates: the primitive everything else rests on

The single idea worth carrying away from AP2 is the mandate: a structured, cryptographically signed statement of user authorization, scoped to a purpose, bounded in amount and time, and verifiable by anyone holding the corresponding key. It is built on verifiable-credential style constructs, so it travels as data rather than as a session or a cookie, and survives being handed between parties.

The shift is worth naming plainly. In today’s flows, authorization is implied by the channel: you were logged in, you were on the merchant’s checkout page, therefore you consented. That inference collapses when an agent is driving. A mandate makes authorization explicit, portable and checkable instead of inferred — consent becomes an artifact you can hand to a merchant, a processor or a court. How mandates are structured, signed, scoped and chained is a subject in its own right; the companion mandate-architecture article takes it apart.

Intent mandate, cart mandate, and the agent signal

AP2 distinguishes two shapes of authorization because agents shop in two very different modes. An intent mandate is what a user signs before the details exist: “buy me a flight to Lisbon in March under 600 euros.” The user is not present at the moment of purchase, so the mandate must carry the constraints — category, ceiling, expiry, merchant limits — that make the later decision legitimate.

A cart mandate is signed once the specifics are known: this merchant, these line items, this total, this currency. It is the machine-readable equivalent of a human reviewing a checkout page and pressing confirm, the artifact a merchant can point to and say the buyer agreed to exactly this basket at exactly this price. A third credential accompanies the transaction toward the network and issuer to signal that an agent was involved at all, which is how the issuer ever learns to treat the payment as agentic rather than as anomalous card-not-present traffic.

The cast: who signs, who verifies, who carries the loss

AP2 is only interesting because of how many parties must agree on one story. The user is the human with the money and the legal right to dispute. The agent acts for them and must never be the sole source of truth about what they wanted. The credentials provider — the wallet or issuer-side service actually holding the payment instrument — is kept deliberately distinct from the agent, so the agent never holds raw card data.

On the other side, the merchant (increasingly represented by its own agent) decides whether to accept; the acquirer or PSP processes on its behalf; the card network carries the message; and the issuer approves or declines and ultimately adjudicates disputes. The mandate travels across all of them. The order in which it moves is the subject of the payment-flow article; the identity and onboarding obligations each regulated party carries are covered in the KYC article.

Non-repudiation: what a signature actually buys

The technical payoff of signing is non-repudiation: the signer cannot later credibly deny having produced the statement. This converts the central dispute of agent commerce from an argument into a verification. Instead of a merchant asserting “your agent ordered this” and a user asserting “I never approved that,” there is a signed artifact that either verifies against the user’s key, with the amount and constraints inside it, or does not.

That artifact also produces something the industry lacks today: a coherent audit trail from human intent to settled transaction, each hop attributable. Be precise about the limits, though. A signature proves who authorized what. It does not prove the user understood the purchase, that the goods arrived, that the agent chose sensibly within its bounds, or that the key was not compromised. Those failure modes are the threat model, examined in the companion security article.

Advertisement

Liability is the real question, and it is not settled

Underneath the cryptography is an economic question the protocol cannot answer by itself: when an agent buys the wrong thing, who eats the loss? For cards, the answer is set by scheme rules, not by technology. The liability shift that comes with 3-D Secure authentication exists because Visa and Mastercard wrote rules saying it does; the cryptography merely supplies the evidence those rules key on.

Understand AP2 the same way. A signed mandate does not, on its own, move liability anywhere. It supplies the evidentiary basis a liability framework could rest on — making “the user authorized this, within these limits” provable rather than merely assertable, which is the precondition for any rule allocating loss on that basis. Whether issuers and networks will write such rules for agentic transactions, and on what terms, is an open commercial question — and the dispute machinery a mandate would feed into is covered in the chargeback and dispute articles.

Where AP2 sits relative to the existing rails

It is tempting to read a new payments protocol as an attempt to displace the incumbents. AP2 is explicitly not that. Money still moves over the rails it always moved over: card networks, bank transfers such as ACH and SEPA, real-time payment schemes, and, where parties choose it, stablecoin transfer. Authorization, capture and settlement work exactly as they do now, same participants, same timings.

AP2 layers above that stack. It standardizes the consent artifact and the evidence accompanying a transaction into the rail, then gets out of the way. That is a shrewd design choice: a protocol requiring new clearing infrastructure would need decades of adoption before it did anything, whereas one that rides existing rails is useful the moment two parties support it. Rail-by-rail characteristics are compared in the payment-rails article; what happens after authorization is the province of the settlement article.

Adoption: the part technology cannot solve

A protocol like this is worth exactly as much as the number of counterparties who honour it. A mandate a merchant cannot verify is a signed file nobody reads; an issuer that does not recognize the agent signal will keep scoring these transactions as suspicious card-not-present traffic and declining them. Value arrives only when the user’s agent, the merchant’s systems, the processor and the issuer all understand the same artifact — a classic multi-sided adoption problem.

That is why the composition of the launch coalition matters more than the specification’s elegance: networks, processors, issuers and platforms must move roughly together, and none will move far ahead of demonstrated consumer demand. Expect the near-term path to be narrow and vertical — a few high-trust merchant categories, a few large processors, conservative limits — rather than general-purpose agentic checkout everywhere at once.

What remains unsolved

Several problems are visible and genuinely open. Liability allocation is the largest, unresolved until scheme rules speak to agentic transactions. Key and delegation management is second — a compromised signing key is worse than a stolen card number, because it authorizes rather than merely identifies, and revoking or narrowing a delegation after the fact is not a solved user-experience problem.

Then there is intent ambiguity: natural language does not bound cleanly, and a mandate can be perfectly valid while authorizing something the user would not have chosen. Add regulatory divergence across consumer-protection regimes, the fraud-model gap while issuers have no history for agentic traffic, and the unanswered question of what a refund means when nobody was watching. AP2 is best read as a serious, well-shaped proposal for the consent layer — not a finished answer to agent commerce.

AP2 exists because agent-initiated payments break the one assumption both card-present and card-not-present flows are built on: that a human is there at the moment of purchase. Its answer is the mandate, a signed statement of what the user authorized, in two shapes — an intent mandate for “buy me X under these limits” before the details exist, and a cart mandate for this exact basket at this exact price. That signature buys non-repudiation and an audit trail from human intent to settled transaction, which is the evidentiary basis a liability framework could rest on — but AP2 does not itself shift liability, because scheme rules do that, and they have not been written for agentic commerce. Read AP2 as a thin, rail-agnostic consent layer above the rails you already use, whose hardest problems are commercial rather than cryptographic.