AP2: The Agent Payments Protocol
What I learned making an agent that buys FIFA tickets while I sleep
July 9, 2026 · 16 min · raw .md
This is a technical deep dive into AP2 v0.2, the cryptographic mandate system behind autonomous agent payments. I wrote it after building a real demo on Camunda 8, and I verified every claim against the spec at ap2-protocol.org, not the press coverage. Most articles from launch week use terminology the current spec has already replaced. I’ll flag that where it matters.
The problem it solves
“Would you give an AI your credit card?” That’s the question I set out to answer for EP 03 of Agents, Orchestrated. The protocol that answers it properly is AP2.
An agent that can spend money is fundamentally different from an agent that can answer questions. When an agent calls a search API and gets it wrong, you get a bad result. When it calls a payment API and gets it wrong, you’re out money.
The traditional answer is: require human presence at payment time. Click Approve. Enter OTP. Which is fine, until the agent is supposed to buy the moment FIFA ticket prices drop at 2am while you’re sleeping.
AP2 solves one specific problem: how does a human delegate spending authority to an agent in a way that is cryptographically bounded, auditable by every party in the chain, and enforceable without phoning home to any central authority?
The answer is mandates. That’s the whole protocol.
What AP2 is: key facts
AP2 = Agent Payments Protocol. Google’s open standard for agent-initiated payments, announced September 16, 2025, with 60+ launch partners including Mastercard, PayPal, American Express, Coinbase, and Salesforce.
| Fact | Detail |
|---|---|
| Current version | v0.2, released April 2026 (GitHub: google-agentic-commerce/AP2) |
| Launch partners | 60+ (Mastercard, PayPal, AmEx, Coinbase, Salesforce) |
| Standardization | FIDO Alliance (Google donated AP2 to the Agentic Auth + Payments TWG) |
| Reference implementations | 5 languages: Python, Go, TypeScript, Kotlin, Android |
Key things to know upfront:
- AP2 is an extension of the A2A protocol (Agent-to-Agent, Google’s peer messaging standard for agents). It adds payment mandate semantics on top of A2A’s transport.
- It integrates with the Universal Commerce Protocol (UCP) as the commerce/checkout layer.
- It supports x402 / stablecoins (USDC) as a first-class payment rail, not an afterthought. This matters for micro-transactions where card interchange ($0.50 to $0.80) exceeds the transaction value.
- The spec ground truth is ap2-protocol.org, not the press coverage. Most articles from September 2025 use stale terminology. I’ll flag this where it matters.
Where AP2 sits in the stack
This is the thing I wish someone had drawn clearly for me on day one. The agentic commerce stack has five distinct layers: different protocols, different organizations, different problems being solved.
| Layer | Protocol | What it does | Steward |
|---|---|---|---|
| 1 | MCP | Model Context Protocol. Discovery and tooling: how LLMs discover and invoke external capabilities | Anthropic |
| 2 | A2A | Agent-to-Agent Protocol. Transport: peer HTTP messaging between agent roles via AgentCard discovery | |
| 3 | AP2 (you are here) | Payment authorization: cryptographically signed mandate chain, SD-JWT, ECDSA P-256, W3C Verifiable Credentials | Google / FIDO |
| 4 | ACP / UCP | Checkout HTTP endpoints, cart assembly, order fulfillment semantics | Open spec |
| 5 | Cards, FedNow, x402 | Settlement rails: Mastercard, Visa, UPI, Pix, USDC stablecoins | Networks |
MCP defines what an agent can read and call. ACP defines how an agent buys. AP2 defines how the user’s intent and the merchant’s charge are cryptographically witnessed.
These layers compose. You use MCP to give an agent tools. Those tools invoke A2A endpoints to message other agents. AP2 provides the signed authorization credentials that travel with those messages. ACP/UCP defines the checkout API the merchant exposes. The rails settle the money.
Figure 1: The five-layer agentic commerce stack. AP2 sits at Layer 3, between transport and settlement, providing the cryptographic authorization chain.
The four parties
AP2 defines four named roles. Every transaction involves some or all of these:
| Role | What they do | Real-world examples |
|---|---|---|
| Shopping Agent | Monitors prices, makes decisions, acts on behalf of the user within mandate constraints | Claude Sonnet, Gemini shopping agents, any LLM agent |
| Merchant Agent | Exposes AP2-compatible cart endpoint, verifies Checkout Mandates, fulfills orders | TicketVault, any ACP-compliant merchant backend |
| Credentials Provider | Verifies both mandates, issues payment credentials to the Shopping Agent | Mastercard Agent Pay, PayPal, Visa |
| Payment Processor | Settles the transaction against the funding instrument | Card networks, FedNow, Coinbase (x402) |
The Trusted Surface is a special concept: the AP2-compatible client (wallet or app) where the user signs mandates. Think of it as the user’s digital signing authority. It holds the user’s ECDSA private key and produces the open mandates before the Shopping Agent acts autonomously.
The mandate system: the core mechanic
Terminology note: many articles still use the launch-week three-mandate framing (Intent Mandate, Cart Mandate, Payment Mandate). The v0.2 spec restructures this into two mandate types with two stages each. The old framing is stale; use v0.2 terminology.
Two mandate types
| Mandate | Shared with | What it captures |
|---|---|---|
| Checkout Mandate | Merchant Agent | Authority to purchase, item scope, price ceiling, merchant allowlist, TTL |
| Payment Mandate | Credentials Provider / Network | Authority to charge, funding instrument token, amount cap, category restrictions |
Open vs closed stages
The distinction between open and closed is the whole mechanism for Human-Not-Present payments.
| Open stage | Closed stage | |
|---|---|---|
| When created | At mandate setup, human present | At purchase time, human not present |
| Signed by | User’s wallet key (ECDSA) | Agent’s key (ECDSA) |
| Contents | Constraints, scope, TTL, allowlists | Specific cart / exact amount, checkout hash |
| Purpose | Standing authority | Transaction-specific proof |
Concrete example: FIFA ticket scenario
Checkout Mandate, open: “I authorize my agent to buy up to 2 Cat 3 FIFA tickets at TicketVault, max $1,500 each, expires in 24h.”
Checkout Mandate, closed: “I’m buying 2 × Cat 3 at $1,350 each, total $2,700, checkout_hash: 0xABC...”
The closed Payment Mandate can only be created after the Checkout Mandate is closed. It must include the checkout_hash from the closed Checkout. The spec enforces this sequential dependency.
Figure 2: Mandate lifecycle. Open mandates are user-signed at setup. Closed mandates are agent-signed at purchase time. The Payment Mandate requires the Checkout hash from the closed Checkout Mandate.
What a mandate looks like
// Simplified mandate JSON (encoded as SD-JWT in practice)
{
"id": "mandate_7A3F2026",
"type": "checkout.open",
"vct": "mandate.checkout.1", // schema version, must match exactly
"user_did": "did:key:z6Mk...", // DID of user's wallet key
"agent_did": "did:key:z6Mk...", // DID of shopping agent
"constraints": {
"item_scope": "event-tickets",
"max_unit_price": 1500,
"max_quantity": 2,
"currency": "USD",
"merchant_allowlist": ["ticketvault.com"],
"ttl": "2026-07-12T00:00:00Z"
},
"signature": "ECDSA_P256_sig_by_user_key..." // MUST be ECDSA, NOT Ed25519
}The cryptography: why this is a protocol, not just a database record
A lot of “agentic payments” solutions are just database records: user checks a box, app writes authorized=true, agent reads it. That breaks the moment you have multiple parties who don’t inherently trust each other.
AP2 mandates are SD-JWTs (Selective Disclosure JSON Web Tokens) signed with ECDSA P-256. The spec is explicit: the Checkout JWT MUST be signed using ECDSA and MUST NOT use Ed25519.
Why ECDSA, not Ed25519?
This is subtle and worth understanding. Ed25519 is deterministic: given the same message and private key, it always produces the same signature. That means two identical mandates produce the same signature hash. An attacker who collects signatures over time can build a rainbow table against the checkout_hash claim embedded in the mandate. ECDSA includes a random nonce per signing operation, so each signature is unique even for identical mandate contents. No rainbow table attack is possible.
The cryptographic formula
// From the CSA security framework for AP2
Sig_U(M) = ECDSA.Sign(K_U, Hash(M))
// Verification: any party can run this independently
Verify(M, Sig, PubKey_U) → boolean
// No API call to any central server required
// The credential is self-contained proofThe five cryptographic guarantees
- Tamper-evidence: any modification to the mandate after signing breaks the ECDSA signature. The merchant or credentials provider will reject it.
- Non-repudiation: the user cannot deny having signed the open mandate. Their private key is the signing authority.
- Portability: every party in the chain verifies independently using the user’s public key (via DID). No central authority. No phone-home.
- Scope enforcement: the closed mandate must satisfy all constraints in the open mandate or verification fails. The agent cannot exceed the user’s pre-authorized scope.
- Selective disclosure: SD-JWT allows a merchant verifying a Checkout Mandate to see item and price fields without seeing the funding instrument token. Fields are selectively revealed per party.
Sensitive payload fields (like funding instrument tokens) are encrypted with AES-GCM-256 before embedding in the JWT. For high-value transactions, the spec recommends hardware-backed key signing (TPM/HSM).
AP2 uses Decentralized Identifiers (DIDs) for issuer key discovery: no certificate authority, no PKI hierarchy to trust. Verification is purely cryptographic.
Threat model
AP2 uses STRIDE for its threat model, extended by the MAESTRO framework for multi-agent ecosystems. It’s worth knowing because it shows exactly what AP2 was designed to defeat.
| Threat (STRIDE) | Attack | AP2 mitigation |
|---|---|---|
| Spoofing | Forged mandate signatures claiming false authorization | DID-based PKI verification, HSM-backed keys |
| Tampering | Altered mandate contents in transit (change price, scope) | ECDSA signature breaks on any modification, TLS 1.3 |
| Repudiation | “I never authorized this purchase” | Non-repudiable ECDSA signature on open mandate plus audit log |
| Info disclosure | Payment instrument exposed to merchant | AES-GCM-256 on sensitive fields, SD-JWT selective disclosure |
| Elevation | Agent exceeds mandate scope (buys something not authorized) | Open mandate constraints verified cryptographically in closed mandate |
| Hallucination fraud | LLM buys wrong thing due to model error | All purchases anchored to signed user intent, not probabilistic model output |
| Agent coercion | Merchant tricks agent into buying outside mandate | DID-based merchant verification plus merchant_allowlist in open mandate |
MAESTRO extends this to emergent multi-agent threats: model poisoning, workflow hijacking, ecosystem collusion. For high-value transactions, the spec recommends multi-agent consensus requirements before mandate closure.
The flows: Human-Present and Human-Not-Present
Human-Present flow
The simpler case. The user is at the keyboard when payment happens. The Trusted Surface presents the specific cart to the user for signature before closing the mandates.
- Shopping Agent assembles cart at Merchant via ACP endpoint
- Agent presents cart plus open mandates to the Trusted Surface (user’s wallet or app)
- User reviews and signs, producing the closed Checkout Mandate (user-signed, specific cart)
- User signs the closed Payment Mandate (references the Checkout hash)
- Agent presents both closed mandates to the Credentials Provider
- Credentials Provider verifies and issues a payment credential
- Agent completes checkout at the Merchant with the credential. Settlement follows.
Human-Not-Present flow (the v0.2 flagship)
This is the one that matters for agentic commerce. The user set constraints in advance; the agent acts autonomously when the trigger fires, possibly hours or days later.
Step 0 is everything. The setup phase is when the human is present. After that, the agent acts fully autonomously. The cryptography enforces the boundary, not a human approving each transaction.
Setup (human present, once): the user signs an open Checkout Mandate (constraints, TTL, merchant scope) plus an open Payment Mandate (instrument, amount cap). Both are stored by the Shopping Agent / Trusted Surface.
… time passes. User goes to sleep. Price drops at 2am. Trigger fires …
- Shopping Agent detects the trigger condition (price at or below target)
- Agent queries the Merchant and receives a Cart Mandate (merchant-signed, specific SKU and price)
- Agent verifies the cart satisfies all open Checkout Mandate constraints (price at or below ceiling, merchant in allowlist, TTL not expired)
- Agent signs the closed Checkout Mandate (agent key, specific cart, checkout_hash)
- Agent presents the closed Checkout Mandate to the Merchant, which verifies both the open (user) and closed (agent) signatures
- Agent signs the closed Payment Mandate (references the checkout_hash from step 4)
- Agent presents both mandates to the Credentials Provider, which verifies the full chain
- Credentials Provider issues the payment credential
- Agent completes checkout at the Merchant with the credential. Settlement happens; the audit trail is complete.
Figure 3: Human-Not-Present flow. Four parties, two mandate types, nine numbered steps. The entire chain is cryptographically linked.
How it connects to the merchant: it’s not MCP
The question I kept asking early on: how does the mandate actually get from my agent to TicketVault?
The answer: via A2A HTTP calls, not MCP.
MCP is the tool and context layer. It’s how Claude (or any LLM) gets access to search_inventory or create_mandate as callable tools. What the LLM does with those tools (the messages between the Shopping Agent and the Merchant Agent) is A2A. The mandate credentials are the payload, not MCP tool results.
MCP defines what an agent can read and call. Mandates are carried alongside A2A calls as evidence artifacts, not generated by MCP itself.
In a real AP2 deployment, the flow to TicketVault would be:
- Shopping Agent POSTs a signed Checkout Mandate (SD-JWT) to TicketVault’s AP2 merchant A2A endpoint
- TicketVault’s merchant agent validates: signature verification, then constraint check, then checkout hash match
- TicketVault returns a Checkout Receipt (merchant-signed)
- Shopping Agent takes that receipt plus the Payment Mandate to the Credentials Provider’s A2A endpoint
In our demo, we simulate this within a single Node.js BFF: Camunda workers play the distributed agent roles, and SSE replaces the A2A calls between them. The mechanics are real; the distribution is simulated. Honest simplification for a demo.
Payment rails: deliberately multi-rail
AP2 doesn’t pick a winner between card rails and crypto. It defines extension points for all of them:
| Rail | How it works in AP2 | Best for |
|---|---|---|
| Card networks | Mastercard Agent Pay, Visa: tokenized card credentials issued by the Credentials Provider | High-value consumer purchases, existing bank relationships |
| Real-time payments | FedNow, UPI, Pix: bank transfer credentials | High-value B2B, markets where real-time bank transfer dominates |
| x402 / USDC | Agent holds a smart wallet directly, USDC on Base/Ethereum, instant settlement | Micro-transactions, API-to-API payments, no interchange floor |
x402 is particularly interesting for micro-transactions. Traditional card interchange costs $0.50 to $0.80 per transaction regardless of amount. An agent paying $0.01 for an API call can’t use card rails economically. x402 plus stablecoins solve this: the agent holds USDC, pays directly on-chain, and can use programmable escrow for multi-step commitments.
Three named public AP2 deployments as of April 2026: PayPal’s wallet plus the Google Cloud Conversational Commerce Agent, the Mastercard Agent Pay pilot inside PayPal, and the A2A x402 extension for crypto payments.
How our demo maps to real AP2
I built a Camunda 8 + AP2-shaped demo for EP 03 of Agents, Orchestrated. Here’s the honest mapping:
| Our demo (Camunda 8 BFF) | Real AP2 |
|---|---|
mandateService.js creates and signs mandate JSON (ES256) |
Trusted Surface plus Shopping Agent hold proper user-signed open mandates with real DID key management |
| Camunda DMN spending policy (HITL, cap, velocity) | Embedded in open mandate constraints plus the credentials provider’s policy engine |
| SSE events drive the TicketVault merchant site | Shopping Agent POSTs the Checkout Mandate to the Merchant Agent’s A2A endpoint (standard HTTP) |
merchant.completeCheckout Camunda worker |
Distinct Merchant Agent binary verifying mandates and executing ACP checkout |
credentials.issueToken Camunda worker |
Credentials Provider Agent verifying the mandate pair and issuing the payment credential |
Zeebe user task task_desk_approval (HITL) |
AP2 doesn’t prescribe HITL escalation; Camunda adds this as governance on top of the protocol |
The Camunda layer is where we add governance that AP2 itself doesn’t mandate: the DMN spending policy, the HITL escalation at 95% of cap, the full process audit trail. AP2 is the authorization protocol. Camunda is the governance orchestrator on top.
What v0.2 added (April 2026)
The headline feature is Human-Not-Present payments: agents can execute pre-authorized transactions without an interactive consent prompt, using the open/closed mandate pair.
- Restructured from three mandate types (Intent/Cart/Payment) to two (Checkout/Payment) with open and closed stages
- Formalized SD-JWT as the mandate encoding standard
- Added the ECDSA MUST / Ed25519 MUST NOT distinction explicitly in the spec
- Introduced official support for x402 / stablecoin rails as a first-class payment type
- Reference implementations in Python, Go, TypeScript, Kotlin, and Android
- FIDO Alliance standardization via the Agentic Authentication and Payments Technical Working Group
The one-paragraph version
AP2 is Google’s open protocol for agent-initiated payments. It solves one problem well: how does a human delegate bounded spending authority to an agent in a way that every party in the transaction chain can verify independently, without trusting each other or phoning home to a central authority? It does this through a two-mandate system, a Checkout Mandate (agent to merchant) and a Payment Mandate (agent to credentials provider), where each mandate has an open stage (user pre-signs constraints) and a closed stage (agent signs the specific transaction). The credentials are SD-JWTs signed with ECDSA P-256, making them tamper-evident and portable. AP2 sits at the authorization layer between the A2A transport protocol and the ACP/UCP checkout layer. It’s not MCP, and it’s not a payment gateway. It works across card rails, real-time payments, and stablecoins. The v0.2 flagship scenario is Human-Not-Present: the agent acts autonomously while the user sleeps, bounded by cryptographic constraints they set in advance.
Autonomy is table stakes. The moat is everything around the agent.
References
- AP2 Specification: ap2-protocol.org (ground truth for mandate types, SD-JWT encoding, ECDSA requirements, party roles)
- Google Cloud: Announcing AP2 (launch context, 60+ partners, FIDO Alliance donation announcement)
- AP2 GitHub: google-agentic-commerce/AP2 (reference implementations in Python, Go, TypeScript, Kotlin, Android, plus runnable scenarios)
- Cloud Security Alliance: Secure Use of AP2 (STRIDE threat model, ECDSA P-256 formula, MAESTRO framework, AES-GCM-256)
- ACP vs AP2 vs MCP: Protocol Stack Comparison (layer-by-layer breakdown of the agentic commerce stack)
- Eco: AP2 v0.2 Explained (v0.2 mandate restructure, Human-Not-Present flow, DIDs for key discovery)
- Cobo Agentic Wallet: AP2 Complete Guide (x402 details, stablecoin rails, multi-party wallet integration)
- UCP: AP2 Mandates Extension (how AP2 integrates with the Universal Commerce Protocol at the checkout layer)
- Google Codelabs: Secure Agent Commerce with AP2 and UCP (hands-on implementation against the official Google ADK)
- arXiv: Zero-Trust Runtime Verification for AP2 (academic treatment of replay attacks and context-binding failures in AP2)
- AP2: EU Perspective (European regulatory and standardization context for agentic payments)
- AP2 Technical Guide: Medium / Vishal Mysore (implementation walkthrough with code examples)
A newsletter is coming. Until then, new guides and episodes land on LinkedIn first and in the RSS feed.