The payments industry already has a primitive for "I authorize this charge later." It's called a mandate, and it's how recurring billing works, how SEPA direct debit works, how ACH works at scale. A mandate is the user's signed permission for some future charge to happen, scoped to specific conditions, with a paper trail.
For decades, mandates have been mundane infrastructure. A user enrolls for a subscription, signs once, and the merchant can charge the agreed amount on the agreed schedule. The mandate is the audit trail.
In 2025, Google's Agent Payments Protocol (AP2) put mandates back at the center of the conversation, and not by coincidence. Agent payments need a new primitive for "the user authorized this," and the existing mandate model, extended for the agent context, turns out to be exactly the right shape.
This post is about what those mandates look like, why they're the right shape for agent payments, and what their adoption will mean for the consumer products built on top.
What AP2 actually defines
AP2 introduces three mandate types as verifiable digital credentials (VDCs): cryptographically signed, tamper-evident, portable digital objects that any party in a transaction can verify. They're signed with hardware-backed keys on the user's device, and they describe specific permissions the user has granted.
Cart Mandate
The Cart Mandate is for human-present purchases. The user is sitting at their device when the agent finalizes a cart. It captures:
- Payer and payee identities
- A specific tokenized payment method
- Transaction details: products, destination, amount, currency
- Refund conditions
- A merchant signature confirming the merchant will fulfill
- A user signature on top, confirming the user authorizes the cart
The mandate gets signed twice. First the merchant signs to commit to fulfilling the order at the agreed price. Then the user signs to authorize the actual purchase. The result is a non-disputable record: the merchant promised to deliver this exact cart, and the user agreed to pay for it.
Intent Mandate
The Intent Mandate is for human-not-present purchases. The user delegates a goal to the agent and walks away. The agent acts on its own when conditions are met. The mandate captures:
- Payer and payee information
- A list of allowed payment methods
- The shopping intent: product categories or SKUs, price ceilings, decision criteria
- A "prompt playback": the agent's natural-language understanding of what the user asked for, played back for the user to confirm
- A time-to-live that bounds how long the mandate is valid
The user signs the Intent Mandate after the agent plays back what it understood. The agent can then act in the user's absence. The merchant gets the Intent Mandate as evidence of what the user authorized, and at dispute time, the gap between what the Intent Mandate said and what the agent actually purchased becomes the basis for liability.
Payment Mandate
The Payment Mandate is the third leg, and the one most people skip. It's a separate credential that travels with the transaction to the payment network and issuer, signaling that an AI agent was involved, what modality the transaction was (human-present or not), and any other consented metadata the merchant or network needs for risk assessment. Crucially, it doesn't carry the full cart. That stays private inside the Cart or Intent Mandate. The Payment Mandate is just enough for the network to know "this is an agent-initiated transaction" and adjust its risk model accordingly.
This separation matters. PCI sensitive data and merchant cart details stay where they belong, while the network gets only what it needs. At dispute time, the full Cart or Intent Mandate becomes available as evidence.
Why three mandates and not one
The mandate split exists because different agent scenarios need different friction profiles.
A user buying a specific item right now needs the precision of a Cart Mandate: "yes, this exact cart, at this exact price." A user delegating a long-running task to an agent ("buy two tickets to any Thom Yorke show in NYC under $200, here's my payment method, you have 30 days") can't sign a Cart Mandate because there's no cart yet. They sign an Intent Mandate that bounds the conditions and lets the agent act when those conditions are met.
A simpler model would force every agent purchase through a human-present approval, which is exactly what some payment-for-AI products do today. That works for the easy cases and breaks for the interesting ones. The whole reason we're building agent payments is to enable purchases that don't happen with the user sitting at the screen.
The three-mandate model is the bridge. It gives the user the precision of a cart approval when precision is appropriate, and the delegation of an intent authorization when delegation is what's needed, without losing the audit trail in either case.
Why three primitives keep showing up
The interesting thing about AP2's mandate split isn't that it's one possible model. It's that any consumer agent-payments product is going to converge on something that looks like it, whether or not the product knows the AP2 spec exists.
To give an agent the ability to spend money on someone's behalf, you need to capture three things in the user's product surface. You need to capture what the user is willing to authorize when they're not present (the rules and conditions). You need to capture what they've explicitly approved when they are present (the cart confirmation). And you need to capture what the network and issuer should know about the fact that an agent was involved (the metadata that travels with the transaction).
These three things are the same shape as Intent, Cart, and Payment Mandates. They're the same shape because they're load-bearing for the same problem. AP2 just gives them a name and a wire format.
This convergence matters because it suggests the mandate model isn't an arbitrary choice that Google made. It's the implicit architecture of agent payments, finally written down. Products that already capture these three things in their UI will find AP2 adoption straightforward. Products that don't will end up inventing the same primitives anyway, just without the benefit of an industry spec to point to.
Where this is going
AP2 has 60+ launch partners and a coherent technical spec. Mastercard Verifiable Intent extends similar primitives into the existing card-network rails. ACP has production traction in ChatGPT Instant Checkout. Visa's Trusted Agent Protocol gives merchants a way to verify they're talking to an agent. None of these will be the only standard. All of them are pushing toward the same shape: a world where agent purchases come with cryptographic, structured, disputable records of what the user actually authorized.
The mandate model is going to outlast any specific protocol fight. It's the right shape because it cleanly separates three things that have always been muddled in card-network UX: the boundaries the user set, the specific thing they approved, and the metadata the network needs to assess risk. Once those three are separate, agent payments get a lot less scary, both for the people whose money is at stake and for the merchants who are going to have to handle disputes.
The thing worth watching over the next eighteen months isn't whether AP2 wins. It's how quickly the consumer products that touch agent payments adopt the mandate vocabulary, in their UI if not yet in their wire format. The first products to do that are going to set the consumer expectations for what an agent payments product should feel like. Everything that comes after will have to live up to those expectations.
