# AP2 Protocol Explained: How Agent Payments Get Authorized > A practical guide to AP2, the Agent Payments Protocol: checkout and payment mandates, open versus closed authorization, verifiable digital credentials, and what it means for merchants. - **Author**: Ayush Agarwal - **Published**: 2026-09-13 - **Category**: AI, Payments - **URL**: https://dodopayments.com/blogs/ap2-protocol-agent-payments --- An AI agent clicks "buy" on a $279.99 order. Six weeks later the cardholder disputes it and says they never approved that purchase. Now answer two questions with evidence: who authorized the transaction, and what exactly did they see when they authorized it? Card networks were built for a human tapping a card at a terminal, not to answer "was this software agent permitted to spend this money on this cart". That gap is what the AP2 protocol tries to close. It does not move money and it does not replace your processor. It produces a cryptographic paper trail proving an agent had permission, what that permission covered, and what each party saw at authorization time. ## What Is the AP2 Protocol? AP2 stands for Agent Payments Protocol. It is a protocol to secure agent-performed payment transactions, published by Google, with documentation at ap2-protocol.org and the specification maintained in the google-agentic-commerce/AP2 repository. The documentation site was published in September 2025. AP2 is an authorization and evidence layer, not a settlement rail. It defines how an AI agent obtains, carries, and presents cryptographic proof that a human authorized a purchase, and how every participant in the chain can independently verify that proof. Standardization continues within the Agentic Authentication Technical Working Group and the Payments Technical Working Group at FIDO, which is where much of the modern authentication stack got hardened before reaching production scale. The core primitive is the Verifiable Digital Credential, or VDC: a tamper-evident, cryptographically signed digital object. AP2 specifies SD-JWTs, meaning Selective Disclosure JSON Web Tokens, for securing the mandates that carry authorization. The framing is simple. AP2 answers "was this agent allowed to buy this, and can we prove it later". It is a natural companion to the shift toward [agentic commerce](https://dodopayments.com/blogs/agentic-commerce), where software initiates purchases rather than merely recommending them. ## The Two Mandates: Checkout and Payment AP2 splits authorization into two objects rather than one blob of consent. The merchant needs to know what was bought; the payment chain needs to know which instrument was authorized and for how much. Different audiences, different privacy needs. The Checkout Mandate captures the reference to the specific items and purchase details negotiated between the agent and the merchant, and is shared with the merchant. The Payment Mandate authorizes payment against a specific payment instrument, and is shared with the Credential Provider, the Networks, and the Merchant Payment Processor. | Mandate | Created by | Verified by | What it proves | | --- | --- | --- | --- | | Checkout Mandate | User signs on the Trusted Surface, based on the checkout negotiated by the Shopping Agent | Merchant | The user agreed to these specific items and purchase details | | Payment Mandate | User signs on the Trusted Surface | Credential Provider, Network, and Merchant Payment Processor | The user authorized payment against a specific payment instrument for this transaction | The roles map onto infrastructure you already run or integrate with: - Shopping Agent: the AI agent negotiating and executing the purchase. - Trusted Surface: where the user actually sees the transaction and signs it. This is the human consent point. - Merchant: the seller, responsible for verifying the Checkout Mandate. - Credential Provider: the source of payment credentials. - Network: the card or payment network. - Merchant Payment Processor: verifies the Payment Credential is correctly scoped to the checkout. Verification duties do not overlap by accident. The Merchant verifies the Checkout Mandate. The Credential Provider and Network verify the Payment Mandate. The Merchant Payment Processor verifies the Payment Credential is correctly scoped to the checkout it claims to cover. If you have wired [payments into an agent workflow](https://dodopayments.com/blogs/mcp-payments-ai-agents) before, the shape will feel familiar. What is new is that consent becomes a portable, verifiable artifact rather than a session cookie and a log line. ## Open vs Closed Mandates This is the part most explanations get wrong. Each mandate type exists in two stages, open and closed. They are not two different mandates but two stages of the same authorization, capturing consent at different moments. An open mandate captures the user's constraints and goals before a specific cart is finalized. The user authorizes autonomous execution within boundaries, such as an amount range and a set of allowed payees, rather than a line-item cart. A closed mandate captures authorization for a specific, finalized checkout and transaction amount. The cart exists, the total is known, and the user signs off on exactly that. The distinction maps to two commerce patterns. "Buy this cart now" produces a closed mandate directly. "Watch for this item and buy it if it drops under $200 from these three sellers" produces an open mandate the agent later exercises. Because an open mandate is not yet bound to a specific transaction, it must be constrained to the agent holding it. The specification requires open mandates to include the agent's public key as a "cnf" claim. Without that binding, an open mandate would be a bearer token any party could exercise. It is also RECOMMENDED to set the "exp" claim to the smallest value that still lets the agent finish its task. A price-watch mandate living three days is a far smaller blast radius than one living a year. One subtlety matters for verification logic: verifiers always receive a closed Payment Mandate and a closed Checkout Mandate regardless of which mode the transaction started in. Only the procedure differs. An open mandate is the upstream constraint, not the thing validated at transaction time. If you are designing spend limits for autonomous agents today, this mirrors the problem space covered in [negotiating usage-based billing for AI agents](https://dodopayments.com/blogs/negotiate-usage-based-billing-ai-agents) and in [agentic billing](https://dodopayments.com/blogs/agentic-billing). The hard question never changes: how do you grant enough autonomy to be useful without granting unbounded spend? ## How an AP2 Transaction Flows The flow below shows a closed-mandate purchase: the user authorizes a specific finalized cart. The key detail is that the merchant issues a signed Checkout JWT, and both mandates get cryptographically bound to it. ```mermaid sequenceDiagram participant U as User participant TS as Trusted Surface participant SA as Shopping Agent participant M as Merchant participant CP as Credential Provider participant MPP as Merchant Payment Processor U->>SA: State purchase intent SA->>M: Negotiate cart and purchase details M-->>SA: Merchant-signed Checkout JWT SA->>TS: Present checkout for human review TS->>U: Display items, total, payee U->>TS: Approve and sign TS-->>SA: Closed Checkout Mandate (hash-bound to Checkout JWT) TS-->>SA: Closed Payment Mandate (hash-bound to Checkout JWT) SA->>M: Submit Checkout Mandate M->>M: Verify Checkout Mandate M-->>SA: Checkout Receipt SA->>CP: Submit Payment Mandate CP->>CP: Verify Payment Mandate CP->>MPP: Forward for processing MPP->>MPP: Verify credential scoped to checkout MPP-->>SA: Signed Payment Receipt MPP-->>CP: Signed Payment Receipt ``` Three details do the heavy lifting. The merchant MUST provide a merchant-signed JWT containing the checkout to the Shopping Agent, so the merchant is not a passive recipient of consent; it produces the canonical object consent points at. The Trusted Surface is where the human sees and signs. The Shopping Agent negotiates but does not manufacture consent, and that separation is the entire security argument. And receipts flow back out, so verification is not fire-and-forget. ## The Cryptography That Makes It Hold Up AP2 uses SD-JWTs to secure mandates. Selective disclosure matters because the merchant and the payment chain need different slices of the same authorization: the merchant should not need full instrument context to verify the cart, and the network should not need the itemized cart to verify the instrument. The binding model is where the protocol earns its keep. The closed Checkout Mandate is bound to the merchant-signed Checkout JWT by cryptographic hash, and the Payment Mandate is bound to a particular checkout using the hash of that same Checkout JWT. That means you cannot take a valid authorization for one cart and replay it against another. Change any part of the checkout and the hash no longer matches, so the mandate no longer validates. The Checkout JWT MUST be signed using a digital signature scheme such as ECDSA, and specifically NOT a deterministic scheme such as Ed25519. The reason is rainbow table attacks: a deterministic signature over predictable, low-entropy content is itself predictable, letting an attacker precompute and match signatures for common checkout shapes. If you reach for Ed25519 because it is your crypto library's default, you are outside the spec. Versioning is handled through the "vct" claim. Each mandate type identifies its schema with a vct value carrying a numeric version suffix, for example "mandate.payment.1" or "mandate.checkout.open.1". Implementations MUST match the exact string including the suffix, which is stricter than semver-flavored API versioning: there is no "accept anything in the 1.x line" behavior. The payment_amount object carries an ISO 4217 currency code and an integer amount in minor units, so 27999 with a currency of USD means $279.99. Minor units avoid floating point rounding, and our [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide) uses the same convention. ## Receipts and Dispute Evidence For merchants, this is the genuinely useful part of AP2, and most coverage underplays it. Once the merchant accepts or rejects a Checkout Mandate it MUST return a Checkout Receipt. Once the Merchant Payment Processor accepts or rejects a Payment Mandate, a signed Payment Receipt MUST be returned to the Shopping Agent, the Credential Provider, and possibly the Networks. Receipts are not courtesy confirmations. A mandate proves the user authorized something; a receipt proves a specific party received it, evaluated it, and decided. At dispute time, the Checkout Mandate, Checkout Receipt, Payment Mandate, and Payment Receipt are verified together as evidence of what the user and each role actually saw. Receipt "reference" values must match the hash of the corresponding closed mandate, so a receipt cannot be quietly reassociated with a different transaction later. A typical agent-initiated dispute today gives you server logs, a session identifier, maybe an email confirmation, and an argument. AP2 replaces argument with signed artifacts any party can independently verify, which matters because winning a chargeback comes down to showing, unambiguously, what the customer agreed to. Our breakdown of [chargebacks versus refunds](https://dodopayments.com/blogs/chargeback-vs-refund) covers why evidence quality drives outcomes, and [how a merchant of record handles chargebacks](https://dodopayments.com/blogs/merchant-of-record-chargebacks) covers who carries that work. None of this makes disputes disappear. It makes the evidence trail deterministic instead of reconstructed. ## AP2 vs x402: Different Layers, Not Competitors These two get compared constantly, usually as if one will beat the other. They solve different problems at different layers. x402 is a settlement protocol: it defines how value moves, typically stablecoins transferred over HTTP 402 responses. AP2 is an authorization and evidence protocol: it defines how you prove an agent was permitted to transact and preserve a verifiable audit trail afterward. | Dimension | AP2 | x402 | | --- | --- | --- | | What it solves | Proving an agent was authorized to buy, and preserving verifiable evidence | Moving value for a request without a pre-existing account relationship | | Where value moves | Nowhere. Existing rails and processors still settle the payment | On-chain, directly between payer and payee | | Settlement asset | Whatever the underlying instrument uses (cards, bank rails, wallets) | Typically stablecoins | | Dispute story | Signed mandates and receipts verified together as evidence | Settlement is final; disputes are handled outside the protocol | | Maturity | Early. Specification work continuing in FIDO working groups | Early. Emerging pattern for machine-to-machine payments | | Who it is for | Merchants and processors needing authorization proof on agent purchases | APIs and services charging agents per request | They are complementary in principle. An agent could hold an AP2 mandate constraining what it may spend, settling some purchases over conventional rails and others over a machine-native rail. We covered the settlement side in our walkthrough of the [x402 protocol](https://dodopayments.com/blogs/x402-protocol). Together they map the two halves of the agent payment problem: permission and movement. Neither removes your existing obligations. Tax, invoicing, refunds, and merchant-of-record duties do not change because a protocol standardized the authorization step. ## What Merchants Should Do Now The honest position: AP2 is early, adoption is unproven, and nobody should rebuild their checkout around it this quarter. But almost everything that makes you AP2-ready is good engineering regardless of whether AP2 wins. Clean, machine-callable checkout APIs. If an agent cannot programmatically build a cart, get a canonical total, and receive a stable identifier for that checkout, no authorization protocol helps you. Agent traffic assumes your checkout is an API surface, not a rendered page. Durable order and receipt records. Store what the customer saw, not just what you charged: line items, totals, currency, timestamps, and the identity of whatever initiated the request. AP2 formalizes this as signed receipts; keep the equivalent today. Idempotency on every write path. Agents retry and networks time out. Without idempotency keys you will double-charge, and a double charge on an agent purchase is a dispute you will lose on principle. This is table stakes for [AI agent billing integration](https://dodopayments.com/blogs/ai-agent-ai-billing-integration). Strong dispute evidence trails. Assemble evidence at transaction time, capturing the authorization context while it is fresh rather than reconstructing it from logs eight weeks later. [Fraud protection tooling](https://dodopayments.com/payments/fraud-protection) helps on prevention, but the evidence discipline is on you. A clear, published refund policy. Agent purchases will generate more "I did not mean to buy that" conversations, and a refund policy that is easy to find and execute converts a chargeback into a refund, which is materially cheaper. Explicit spend boundaries in your own product. If your product lets agents trigger charges, define limits now: per-transaction caps, daily caps, allowed categories, allowed payees. AP2's open mandates formalize this idea, and building it yourself teaches you which constraints you need. The patterns in [usage-based billing for SaaS](https://dodopayments.com/blogs/usage-based-billing-saas) and across [AI billing platforms](https://dodopayments.com/blogs/ai-billing-platforms) are a useful starting point. To be direct: Dodo Payments does not implement AP2, and we will not hint at a roadmap we have not committed to. What we provide is the layer underneath, which does not change no matter which authorization protocol wins. As a [merchant of record](https://dodopayments.com/payments/merchant-of-record), we take on tax compliance across 190+ countries, invoicing, and dispute handling, with support for 40+ payment methods, 80+ currencies, and 220+ countries and territories. Pricing is 4% + 40c per domestic US transaction, plus 1.5% international and 0.5% for subscriptions, with $30 per dispute and no fixed monthly cost. Full details sit on the [pricing page](https://dodopayments.com/pricing), and [what a merchant of record actually is](https://dodopayments.com/blogs/what-is-a-merchant-of-record) covers the model. For the agent side, we publish an [MCP server for AI agents](https://docs.dodopayments.com/developer-resources/mcp-server) so agents can work with payment operations through a structured interface, plus [agent skills](https://docs.dodopayments.com/developer-resources/agent-skills) for common workflows. That is complementary to AP2, not a substitute: AP2 would govern whether an agent is permitted to buy, while an MCP server governs how it interacts with billing operations. ## Open Questions and Limitations Adoption is uncertain. A specification with documentation published in September 2025 and ongoing standardization inside FIDO working groups is not a settled ecosystem. Payment standards succeed on network effects, and network effects take years. Liability rules are unresolved. If an agent exercises a valid open mandate and buys the wrong thing within its constraints, who eats the cost? The cryptography proves the mandate was valid; it does not establish whether the user, the agent operator, the merchant, or the issuer is responsible for a bad outcome inside valid bounds. That work is ongoing in the FIDO working groups. Trusted Surface implementation is a real dependency. The security model assumes a surface where the user genuinely sees and signs, meaning wallet apps, OS layers, or browser components that do not uniformly exist yet. Open mandate scoping is hard to get right. The spec requires the "cnf" claim binding to the agent's public key and recommends minimal "exp" values, but choosing the right constraints for a real shopping task is a product design problem, not a cryptography problem. Most importantly for merchants: AP2 changes nothing about tax obligations, VAT and GST registration, invoicing, or merchant-of-record duties. A signed mandate does not file a tax return or issue a compliant invoice. Those obligations sit exactly where they sat before. ## FAQ ### What does AP2 stand for? AP2 stands for Agent Payments Protocol. It is a protocol published by Google to secure agent-performed payment transactions, with documentation at ap2-protocol.org and the specification maintained in the google-agentic-commerce/AP2 repository. ### What is the difference between an open and a closed mandate in AP2? An open mandate captures the user's constraints and goals before a specific cart is finalized, allowing autonomous execution within boundaries such as an amount range and allowed payees. A closed mandate captures authorization for a specific, finalized checkout and transaction amount. ### Does AP2 replace my payment processor? No. AP2 is an authorization and evidence layer that proves an agent was permitted to transact and preserves a verifiable audit trail. Settlement still happens over your existing payment rails, and your processor, tax, and merchant-of-record obligations are unchanged. ### How is AP2 different from x402? x402 is a settlement protocol that defines how value actually moves, typically stablecoins over HTTP 402 responses. AP2 is an authorization and evidence protocol that proves an agent was permitted to transact, so the two operate at different layers rather than competing. ### Does Dodo Payments support AP2? Dodo Payments does not implement AP2. Dodo Payments operates as a merchant of record handling tax compliance, invoicing, and disputes, and publishes an MCP server so AI agents can interact with payment operations through a structured interface. ## Final Take AP2 is a well-designed answer to a question that will not go away: when software spends money on a person's behalf, how do you prove it was allowed to? The mandate split, the hash binding to a merchant-signed Checkout JWT, the ECDSA requirement, and the receipt-based dispute evidence are careful choices made by people who have clearly handled real payment disputes. Whether AP2 becomes the standard is open. Early payment standards have a poor survival rate, and the liability model is still being worked out inside FIDO working groups. The direction is not. Agents will initiate more purchases every year, and the authorization and evidence problem gets harder as volume grows. Merchants who build clean checkout APIs, durable receipt records, idempotent write paths, and disciplined dispute evidence will be ready for AP2 if it wins and better off if it does not. The infrastructure underneath does not change either way. Someone still has to collect the right tax in 190+ countries, issue compliant invoices, and fight the chargebacks. If you want that handled while you focus on the agent experience, start with our [developer documentation](https://docs.dodopayments.com). --- - [More AI articles](https://dodopayments.com/blogs/category/ai) - [All articles](https://dodopayments.com/blogs)