AP2 (Agent Payments Protocol) is Google's open standard for letting AI agents transact on behalf of users, announced September 16, 2025 with 60+ launch partners including Mastercard, PayPal, Coinbase, American Express, and Salesforce. AP2 introduces two signed Mandates, a Checkout Mandate and a linked Payment Mandate, each existing in an open and a closed form and carried as SD-JWT verifiable digital credentials (ap2-protocol.org), and treats stablecoin rails as first-class citizens alongside cards and bank transfers.
​

The protocol sits between agent reasoning frameworks (MCP, A2A) and payment networks, giving merchants a cryptographically verifiable record of what the user authorized, what the agent selected, and what was charged. The full spec lives at GitHub.
​

AP2 is a vendor-neutral protocol that lets an AI agent prove to a merchant or payment network that a real user authorized a specific purchase. It solves the trust gap created when agents act autonomously: who is liable, what was actually consented to, and was the charged amount the agreed amount? Google published the spec under an open license on September 16, 2025.
​

The launch addressed a concrete problem. Agent checkout was already happening through scraped credentials and stored cards, but networks had no way to distinguish a human-driven transaction from an agent-driven one, and no way to verify the agent acted within scope. Google Cloud's announcement framed AP2 as the payments-layer companion to the Agent2Agent (A2A) protocol it shipped in April 2025, and to Anthropic's Model Context Protocol for tool access.
​

Launch partners spanned card networks (Mastercard, American Express), processors (PayPal, Adyen, Worldpay), wallets and crypto rails (Coinbase, MetaMask, ConsenSys), enterprise platforms (Salesforce, ServiceNow, Intuit), and merchants (Etsy, Lowe's). The 60+ partner list is maintained in the GitHub README.
​

AP2 represents every agent purchase as two signed Mandates: a Checkout Mandate covering what is being purchased, and a linked Payment Mandate covering the payment for that checkout. Each exists in two forms. The open form captures the user's constraints before anything is finalized; the closed form authorizes one specific, finalized checkout. Both are secured as SD-JWTs, and both are assembled by the Shopping Agent and rendered to the user by a Trusted Surface, the one role the spec requires to be non-agentic (ap2-protocol.org).
​

The Checkout Mandate is verified by the Merchant. The Merchant supplies a merchant-signed Checkout JWT with the exact line items, prices, and totals, and the closed Checkout Mandate binds to it through a hash carried in the checkout_hash claim. That binding is the "what you see is what you pay for" guarantee: the merchant cannot change the checkout after the user signs, and the user cannot deny having seen it. The open form carries constraints instead, allowed merchants and acceptable line items with quantities (Checkout Mandate spec).
​

The Payment Mandate is verified by a different set of parties, the Credential Provider, the Network, and the Merchant Payment Processor. It carries the payment instrument and is bound to the same checkout by the same hash, so an authorization cannot be moved onto another checkout. Its open form is where standing spend limits live: a budget, an amount range, allowed payees, allowed payment instruments, an execution date range, and agent recurrence rules with a frequency and a maximum number of occurrences (Payment Mandate spec).
​

Both mandates produce receipts. The Merchant returns a Checkout Receipt once it accepts or rejects, and the Merchant Payment Processor returns a signed Payment Receipt to the Shopping Agent, the Credential Provider, and where applicable the networks. Mandates and receipts together are what the spec expects parties to bring to a dispute (AP2 v0.2 specification).
​

AP2 sits one layer below MCP and A2A. MCP gives an agent tools and context. A2A lets agents talk to each other. AP2 is the dedicated payments rail those agents call when a transaction needs to happen. The three protocols are designed to compose: an MCP-equipped shopping agent uses A2A to negotiate with a merchant agent, then invokes AP2 to settle.
​

Model Context Protocol, released by Anthropic in November 2024, standardizes how an LLM connects to data sources and tools. A2A, released by Google in April 2025, standardizes agent-to-agent discovery and task delegation. Both are payment-agnostic by design.
​

AP2 fills the gap. Where MCP might expose a "checkout" tool and A2A might route a task to a merchant's fulfillment agent, AP2 carries the actual payment instruction with cryptographic proof of user consent. Google's reference implementation in the AP2 repo shows MCP + A2A + AP2 wired together for a sample shopping flow.
​

AP2 is payment-method agnostic. The spec defines extension points for card networks, ACH and bank transfers, real-time payment systems (FedNow, UPI, Pix), and digital assets including stablecoins. Coinbase and MetaMask shipped stablecoin extensions at launch, making USDC and other stablecoin rails first-class Payment Mandate funding instruments alongside Mastercard and PayPal.
​

The stablecoin path matters for agent commerce because agents transact in small amounts, across borders, and at machine speed. Card interchange averages $0.50 to $0.80 per transaction at typical retail spreads (Federal Reserve Bank of Kansas City interchange research), which is uneconomic for sub-dollar agent purchases. Stablecoin settlement on chains like Base or Solana runs cents or fractions of cents per transfer.
​

Coinbase's AP2 extension uses the wallet-side signing key for the Payment Mandate and settles in USDC. MetaMask's extension follows the same pattern for self-custodied wallets. Both are linked from the partner section of the AP2 repo.
​

A merchant integrates AP2 by returning a merchant-signed Checkout JWT for the checkout it has priced, then verifying the Checkout Mandate the Shopping Agent presents back. The merchant checks that the hash of the Checkout JWT it sent matches the mandate's checkout_hash claim and, where open Checkout Mandates are included, that the finalized checkout satisfies every constraint. It then returns a Checkout Receipt accepting or rejecting the order (AP2 v0.2 specification). The reference TypeScript and Python implementations in the AP2 repo wrap the cryptographic work behind a simple SDK.
​

Three integration shapes are common:

The samples directory contains a working merchant, buyer agent, and payment server you can run locally.
​

AP2 is the broadest of the agent-commerce protocols: open, vendor-neutral, payment-method agnostic, and built on SD-JWT verifiable digital credentials. Mastercard Agent Pay and Visa Trusted Agent are network-specific schemes that focus on card-rail tokenization. MCP is not a payment protocol at all, but it is the tool layer agents use to reach into AP2.

The practical read: AP2 is the only one of the four that targets the full agent-commerce lifecycle (checkout binding, payment authorization, and a receipt for each) across both fiat and stablecoin rails. Network schemes like Agent Pay and Trusted Agent can plug into AP2 as Payment Mandate funding instruments. See Mastercard Agent Pay vs Visa Trusted Agent for the network-specific comparison.
​

AP2 Mandates are verifiable digital credentials, issuer-signed sets of claims whose authenticity anyone can check, and v0.2 secures them as SD-JWTs (AP2 v0.2 specification). Each mandate names its schema in a vct claim that verifiers must match exactly, including the version suffix: mandate.checkout.1 and mandate.payment.1 for closed mandates, mandate.checkout.open.1 and mandate.payment.open.1 for open ones. The SD-JWT format matters because it supports selective disclosure: the mandate's claims are individually revealable, and the spec requires a Shopping Agent to present only the disclosures from the open Mandates that evaluating the closed Mandate actually needs. Any party can verify the chain without contacting the issuer.
​

Verifiable digital credentials matter for agent commerce because they make consent auditable. A merchant facing a chargeback can show the signed Checkout Mandate and its Checkout Receipt. A network facing a dispute can show the signed Payment Mandate and its Payment Receipt. A user worried about agent overreach can audit which Mandates they signed and what constraints each one set.
​

In Autonomous mode the open Mandate also pins the agent's public key in a cnf claim, which is how a verifier knows that an agent-signed closed Mandate traces back to something the user approved (AP2 v0.2 specification). See agent identity verification for how agent credentials and directory lookups combine in practice.
​

AP2's stablecoin Payment Mandates need cross-chain liquidity to be useful: the buyer's USDC might sit on Base while the merchant accepts on Solana or Arbitrum. Eco Routes provides the routing and settlement layer that turns "the agent has USDC somewhere" into "the merchant receives USDC where it wants." Eco Routes supports 15 chains across the major stablecoins (USDC, USDT, USDS).
​

For an AP2-enabled agent, the integration is direct. When a Payment Mandate specifies a USDC funding instrument and a merchant address on a different chain, the agent calls Eco Routes to fulfill the transfer atomically. The mandate chain records what the user authorized; Eco Routes handles where the dollars actually land.
​

This is the same pattern that powers other agent-commerce stacks that need cross-chain stablecoin movement. See the agent pay implementation guide for a worked example.
​

Sources and methodology. AP2 specification, partner list, and Mandate schemas verified against the google-agentic-commerce/AP2 GitHub repository and Google Cloud's September 16, 2025 announcement. Mandate structure, roles, and the open and closed forms re-verified against the v0.2 AP2 v0.2 specification, Checkout Mandate spec, and Payment Mandate spec. Interchange figures from Federal Reserve Bank of Kansas City research.
​

The Agent Payments Protocol (AP2) defines three roles: Merchant Agent (accepts a payment on behalf of a merchant), User Agent (initiates a payment on behalf of a user), and Payment Rail (the settlement network). Where you plug in depends on your product surface.

Recommendation for most 2026 builders: start as a Merchant Agent if your revenue depends on machine-readable pricing and access. Everything else is downstream of that decision.