AP2 is an open protocol that gives an AI agent a verifiable, cryptographically signed permission slip from a human before it can spend money on that human's behalf. Google announced the Agent Payments Protocol on September 16, 2025 with more than sixty payments and technology partners, PayPal, Mastercard, American Express, Adyen, Coinbase, Salesforce, ServiceNow, Worldpay, JCB, UnionPay International, Etsy among them. AP2 separates two questions that traditional payment rails fold together. The first is "did the user authorize this purchase," answered by a chain of cryptographically signed mandates. The second is "is the payment valid," answered by whatever rail moves the dollars, a card network, a real-time bank transfer, or a stablecoin. AP2 standardizes the first answer in a format that any merchant, processor, or network can verify. This piece is the technical primer: the two mandate types and their open and closed forms, the ECDSA signing path, the credential-provider role, the composition with the broader Google agentic commerce stack, and how AP2 stacks up against Visa's TAP, OpenAI's ACP, and Coinbase's x402.
​

AP2 is an open, payment-method-agnostic protocol that lets an AI agent prove to a merchant that a human authorized a specific purchase. It uses cryptographically signed mandates as the proof. The protocol does not move money itself, it produces a verifiable record that a payment is authorized, which any rail (card, bank, stablecoin) can settle against.
​

AP2 is governed by the google-agentic-commerce/AP2 repository under Apache 2.0 and a separate Ap2-protocol documentation site. The latest release is v0.2.0, shipped in April 2026, with a Python-majority codebase plus reference implementations in TypeScript, Kotlin, and Go. The protocol's core types (mandate SD-JWT schemas, signature primitives) sit in the SDK; samples use Google's Agent Development Kit and Gemini 3.1 Flash Lite Preview, but the protocol does not require those tools.
​

The launch coalition was unusually broad for a Google-led specification. Sixty organizations endorsed AP2 at announce, growing past one hundred by the time PayPal and Google Cloud co-announced their Conversational Commerce Agent on October 27, 2025. The same day, PayPal and Mastercard expanded their partnership so PayPal would pilot Mastercard's Agent Pay Acceptance Framework, designed to be interoperable with AP2 and other named agentic protocols. The endorsement set spans card networks (Visa runs its own TAP), stablecoin rails (Coinbase, Ethereum Foundation, MetaMask), and shopping surfaces (Etsy, Shopee, Global Fashion Group). The breadth positions AP2 as a cross-network authorization standard, not a single-vendor product.
​

AP2 sits at a specific layer of the agentic commerce stack and does not try to be everything. Agentic commerce as a category breaks down into discovery (MCP), agent-to-agent transport (A2A), authorization (AP2 + TAP), checkout (ACP, UCP), and settlement (card rails, real-time bank, x402 stablecoins). AP2 owns the authorization slot. Cart-level commerce flow runs through the Universal Commerce Protocol, which is "compatible with Agent Payments Protocol (AP2) to provide secure agentic payments support" per Google's UCP launch post.
​

AP2 defines two cryptographically signed mandate types, each existing in an open and a closed stage. The Checkout Mandate captures the specific items and purchase details negotiated between the agent and the merchant, and is shared with the merchant. The linked Payment Mandate authorizes a payment against a specific payment instrument, and is shared with the Credential Provider, the networks, and the Merchant Payment Processor (ap2-protocol.org). The open stage captures the user's constraints before a checkout is finalized; the closed stage authorizes one finalized checkout. Together with their receipts they form a non-repudiable audit trail of who authorized what, within what limits.
​

The human-present case is what the spec calls Direct mode, and it runs in five steps. (1) The user asks an agent for something, say white running shoes under $150. (2) The Shopping Agent shops, returns options, and the user picks one; the Merchant returns a merchant-signed Checkout JWT describing that checkout. (3) The Shopping Agent assembles closed Checkout and Payment Mandate Content and passes it to a Trusted Surface, the non-agentic UI role whose job is to render the mandate to the user and obtain the signature. (4) The agent forwards the signed Payment Mandate to the Credential Provider, and to the Network where one applies, for verification, and on success receives a payment credential. (5) The agent hands that payment credential and the Checkout Mandate to the Merchant, which verifies the checkout matches the one it created and initiates payment with the Merchant Payment Processor. A Checkout Receipt and a Payment Receipt close the loop and become the evidence either side can produce in a dispute (AP2 v0.2 specification).
​

The human-not-present flow, Autonomous mode in the spec, runs differently. The user signs open Checkout and Payment Mandates upfront, and those carry constraints rather than a finalized checkout: allowed merchants and acceptable line items on the checkout side, and budget, allowed payees, allowed payment instruments, an amount range, an execution date range, and agent recurrence rules on the payment side. Open Mandates must carry the agent's public key in a cnf claim, and the spec recommends setting the shortest expiry that still lets the agent finish the assigned task. When a checkout materializes, the Shopping Agent signs the closed Mandates with its own agent key instead of returning to the Trusted Surface, then presents both the user-signed open Mandate and the agent-signed closed Mandate to the verifying parties, who check the closed Mandate against every constraint (AP2 v0.2 specification).
​

Two things sit outside this flow. The first is payment movement, AP2 does not move dollars. AP2 is a security layer that operates inside a commerce protocol, and it is built to be compatible with the Universal Commerce Protocol; once the Merchant Payment Processor holds the payment credential, settlement runs on whatever rail that payment instrument belongs to (AP2 v0.2 specification). If the payment method is a stablecoin, settlement happens through the A2A x402 extension Google co-developed with Coinbase, the Ethereum Foundation, and MetaMask. The second is agent identity. AP2 binds a mandate to a user's signature, or in Autonomous mode to an agent key that a user-signed open Mandate authorizes; it does not itself attest who the agent is. Agent identity attestation is the job of Visa's Trusted Agent Protocol, which signs the agent's identity into HTTP request headers. AP2 and TAP are complementary, not competing.
​

Mandates are verifiable digital credentials secured as SD-JWTs, a format that lets the holder reveal only the claims a given verifier actually needs (AP2 v0.2 specification). The Cloud Security Alliance's AP2 security analysis from October 6, 2025 confirms ECDSA P-256 as the minimum curve and applies STRIDE plus MAESTRO frameworks to map threat coverage. The spec adds one signing constraint of its own: the merchant-signed Checkout JWT must use a randomized signature scheme such as ECDSA rather than a deterministic one such as Ed25519, which is what stops a rainbow table attack against the checkout hash. Each mandate names its schema in a vct claim whose version suffix verifiers must match exactly, mandate.checkout.1 and mandate.payment.1 for the closed forms and mandate.checkout.open.1 and mandate.payment.open.1 for the open ones.
​

The two mandate types carry different payloads and go to different verifiers. The Checkout Mandate authorizes the completion of a checkout. Its content is created by the Shopping Agent, rendered to the user by the Trusted Surface, and verified by the Merchant. The closed form is bound to the merchant-signed Checkout JWT by a base64url-encoded hash carried in its checkout_hash claim, so the merchant can prove the user approved the exact checkout it built, and the merchant returns a Checkout Receipt once it accepts or rejects. The open form carries constraints instead of a finalized checkout: allowed merchants, and line items defining which acceptable items and quantities may appear (Checkout Mandate spec).
​

The Payment Mandate authorizes the payment for a particular checkout. Its content is also created by the Shopping Agent and rendered by the Trusted Surface, but it is verified by a different set of parties: the Credential Provider, the Network, and the Merchant Payment Processor. It is bound to the checkout by the same cryptographic hash of the Checkout JWT, so a payment authorization cannot be moved onto a different checkout. The open form carries the spending constraints a user sets for autonomous operation: agent recurrence with a frequency and a maximum occurrence count, allowed payees, allowed payment instruments, allowed payment initiation service providers, an amount range, a total budget, a reference tying it to its open Checkout Mandate, and an execution date range (Payment Mandate spec). Privacy is handled by selective disclosure rather than by stripping fields: the spec requires a Shopping Agent to present only those disclosures from the open Mandates that evaluating the closed Mandate actually needs. Once the Merchant Payment Processor accepts or rejects, a signed Payment Receipt goes back to the Shopping Agent, the Credential Provider, and where applicable the networks.
​

The Credential Provider is one of five roles the protocol names, alongside the Shopping Agent, the Merchant, the Merchant Payment Processor, and the Trusted Surface (AP2 v0.2 specification). It holds the user's payment instrument, verifies that this agent is authorized to access that credential, and scopes the credential appropriately before returning it. PCI-regulated wallets like PayPal, Apple Pay, Google Wallet, and Coinbase Smart Wallet fit this role. The shopping agent never sees raw card numbers or seed phrases, the credential provider returns an opaque token and the agent passes that token forward. One role constraint is worth calling out: the Trusted Surface MUST be non-agentic, meaning no part of its processing may be delegated to an LLM, because it is the surface that obtains informed user consent before any user-signed mandate exists. This is the same separation-of-duties pattern that makes Apple Pay safer than typing card numbers into a web form, applied to the agent context.
​

AP2 produces a non-repudiable audit trail by binding the user's signature to the exact checkout contents at a specific timestamp. A merchant or network can later verify the user signed that checkout, at that price, and that it satisfied the constraints carried in any open Mandate the user signed earlier. If the agent deviated, the signature does not validate and the transaction does not settle.
​

The protocol answers the authorization question through three properties. Authentication: only the holder of the user's private key (resident on the user's device or in the credential provider's HSM) can produce a valid signature. Integrity: SHA-256 hashing means any modification to the checkout after signing breaks signature validation. Bind-to-context: the closed Checkout Mandate carries the hash of the merchant-signed Checkout JWT in its checkout_hash claim, and the Payment Mandate carries the same hash, so a signature commits to that checkout and only that checkout. The agent cannot reuse it for a different checkout, a different merchant, or a different price (AP2 v0.2 specification). The combination is what cryptographers call non-repudiation: the user cannot later deny having authorized a specific transaction, and the agent cannot fabricate authorizations the user did not give.
​

The accountability story extends past authorization. AP2 documentation breaks the chain into three named functions (described in the launch announcement): authorization (proving the user gave the agent authority), authenticity (the merchant knows the agent's request reflects true intent), and accountability (when something goes wrong, the audit trail names who signed what). If a fraudulent transaction occurs, the mandate chain points at one of three parties: the user (whose signature authorized it), the agent (whose signature on its outputs ties it to the request), or the merchant (whose signature on the Checkout JWT binds it to the price). This is sharper than card-network dispute resolution, which often resolves ambiguity in favor of the cardholder by default.
​

The threat model the Cloud Security Alliance applied identifies six STRIDE categories, spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege, and maps each to a mandated control. ECDSA signatures and PKI defeat spoofing. SHA-256 plus TLS 1.3 defeat tampering. The non-repudiable audit log defeats repudiation. Role-based isolation between agent, credential provider, and merchant defeats information disclosure. Rate limiting and allowlists defeat DoS. OAuth-scoped agent permissions defeat privilege elevation. The combination is more rigorous than how most card-not-present transactions are authenticated today.
​

AP2 composes with two adjacent Google-stewarded protocols. Anthropic's MCP handles tool and data discovery. Google's UCP handles end-to-end commerce flow, from product search through cart finalization. AP2 inserts the cryptographic authorization layer between them. A working agent stack runs all three, with each protocol owning a specific concern and not duplicating the others.
​

The compositional logic shows up most clearly in the PayPal + Google Cloud Conversational Commerce Agent launched on October 27, 2025. A merchant deploys an agent built on Google's Agent Development Kit. The agent uses MCP servers to read the merchant's product catalog and inventory. It uses A2A to communicate with the user's PayPal Agent. When the user picks a cart, AP2 mandates carry the authorization between the user, the merchant agent, and the PayPal credential provider. UCP defines the end-to-end checkout shape, discovery, configuration, cart assembly, finalization. The whole flow is a single conversation from the user's perspective, but four protocols are running underneath. Google's UCP launch post calls AP2 out specifically: "compatible with Agent Payments Protocol (AP2) to provide secure agentic payments support."
​

The crypto-payment path uses a fifth protocol on top of these. The A2A x402 extension, co-developed by Google with Coinbase, the Ethereum Foundation, and MetaMask, connects AP2's authorization output to x402's settlement layer. The flow: the user signs a Checkout Mandate, the merchant agent's payment endpoint returns HTTP 402 with the payment terms, the client agent signs an EIP-3009 transferWithAuthorization referencing the upstream mandate, the facilitator confirms onchain settlement, and the resource ships. Two cryptographic signatures stack: the AP2 mandate signature attests authorization; the x402 token-transfer signature attests payment movement. They commit to different things and validate independently.
​

The MCP layer sits below all of this. Anthropic open-sourced MCP in November 2024 and donated it to the Linux Foundation's Agentic AI Foundation in December 2025; agentic payments systems use MCP servers to expose tools (catalog reads, price lookups, inventory checks) that the agent calls before assembling a cart. The MCP server is what turns a merchant's existing API surface into something an agent can navigate without bespoke wiring. AP2 then takes over once the agent is ready to commit to a purchase.
​

Four named protocols overlap with AP2 in the agent payment space: Visa's TAP, OpenAI/Stripe's ACP, Coinbase's x402, and Mastercard's Agent Pay Acceptance Framework. Each occupies a different layer or solves a different sub-problem. A production agent stack typically uses two or three of them together rather than choosing one. The table below maps the differences across four dimensions.

The clean way to think about it: TAP says "the agent is real," AP2 says "the user authorized this purchase," ACP says "here is a scoped token to charge for this checkout," x402 says "the dollars moved onchain," and Mastercard's Agent Pay Acceptance Framework says "the issuer accepts this transaction." A retail purchase from a ChatGPT-style agent might use ACP for the checkout flow, AP2 for the underlying authorization, TAP for agent identity, and a card rail for settlement. A machine-to-machine API call between two agents might skip ACP and go straight from MCP discovery to x402 settlement, with AP2 producing the upstream mandate. Agent payment protocols compared covers the routing decisions.
​

Two protocols in the table merit a sharper differentiation. ACP's Shared Payment Token is conceptually similar to AP2's Payment Mandate, both are scoped, ephemeral credentials that the agent can pass to the merchant. The difference: ACP's token is opinionated about checkout flow (one merchant, one cart, one Stripe-style charge), while AP2's mandate is payment-method-agnostic and supports human-not-present delegation through user-signed open Mandates. ACP launched narrow but live (Etsy plus a handful of Shopify brands on day one); AP2 launched broad (60+ partners) but production-thin. The two are not strictly competitive, since ACP could in principle issue Shared Payment Tokens that reference an AP2 mandate as upstream authorization. None of the major implementations do this yet, but the architecture allows it.
​

x402 and AP2 sit at different layers entirely. x402 is the HTTP-native settlement protocol, when an agent pays USDC for a CoinGecko API call, x402 carries the payment. It does not address authorization in the AP2 sense; an agent calling x402 today might use any wallet credential, scoped or not. The A2A x402 extension closes that gap by letting AP2 mandates carry into x402 settlement, which gives crypto payments the same audit trail card payments get under AP2. Agent spend controls covers the operational pattern teams use to bound mandate-issuance authority before it reaches the wallet.
​

Three named AP2 deployments are public as of April 2026: PayPal's wallet integration with the Google Cloud Conversational Commerce Agent, the Mastercard Agent Pay pilot inside PayPal, and the A2A x402 extension for crypto payments. Each tests AP2 against a different deployment shape, wallet-resident credential, network-hosted acceptance, and stablecoin settlement.
​

PayPal Conversational Commerce Agent. Announced October 27, 2025. PayPal acts as the credential provider; merchants deploy a Google Cloud agent built on Vertex AI; the user shops conversationally; AP2 mandates carry between the merchant agent and the PayPal Agent. PayPal's product team described the integration in their developer community post as the canonical pattern for "verifiable trust for agentic commerce." The integration runs over Google Cloud's Agent Development Kit but does not require it, merchants can build agents in any framework that emits AP2-compliant mandates.
​

Mastercard Agent Pay × PayPal pilot. Same date. Mastercard's Agent Pay Acceptance Framework, a network-layer specification for issuers and merchants to interoperate around agent-initiated transactions, is being piloted inside PayPal's wallet. The framework is "compatible with Mastercard and common agentic protocols," per the joint announcement, with AP2 named explicitly. The pilot tests how AP2 Payment Mandates flow into Mastercard's risk engines and how the Agent Pay Acceptance Framework's Agentic Tokens compose with AP2 mandates. This is the first concrete test of AP2 inside a live card network's authorization stack.
​

A2A x402 extension. Launched alongside AP2 v0.1. Co-developed with Coinbase, the Ethereum Foundation, and MetaMask. Lets an AP2 mandate authorize an x402 stablecoin settlement, so an agent can pay USDC to a merchant agent with the same audit trail a card payment would have. The extension lives at GitHub with reference implementations. This is the path for crypto-native agentic commerce that wants AP2's authorization rigor without giving up onchain settlement.
​

Around these three anchors sits a long tail of integrations from the original launch list, Salesforce, ServiceNow, Adobe, Shopee, Etsy, Adyen, American Express, JCB, UnionPay International, and others, each at a different stage. The PayPal pilot is the most fully wired through to production. The Mastercard pilot is the most consequential for card payments. The x402 extension is the most operationally interesting for crypto-native agent stacks.
​

AP2 is a young specification (v0.2 in April 2026) and inherits constraints typical of standards still in early adoption. Three matter for production planning: agent identity is not solved by AP2, mandate revocation needs careful handling, and the protocol has not yet been tested at meaningful card-network volume.
​

The first limit is scope. AP2 binds a mandate to a user's identity through their signing key, not to an agent's identity. A compromised agent can still produce a mandate-signing prompt that fools the user, and the user's signature on the resulting cart is valid even though the agent acted maliciously. This is why TAP exists and why the protocol stack is layered. Production deployments expect agent identity attestation to come from TAP or an equivalent before AP2 mandate signing happens.
​

The second is revocation and dispute. Cryptographic mandates are non-repudiable by design, which is the security feature, but there is no in-protocol mechanism for the user to revoke an open Mandate before its exp claim runs out. If the user signs open Mandates authorizing $500 of grocery purchases over the next month and changes their mind on day three, the existing protocol surface depends on the credential provider or wallet to enforce revocation outside AP2. The nearest in-protocol control is narrower: a Shopping Agent must not present a further open Mandate until it has received a rejection receipt for the previous one, which caps reuse but does not cancel a mandate a user regrets (AP2 v0.2 specification). The same applies to disputes: AP2 produces an audit trail that says who signed what, but does not specify how to resolve a contested transaction. Card networks layer their own dispute resolution on top, which is part of why the Mastercard pilot matters.
​

The third is throughput. The PayPal and Mastercard pilots are early-stage and have not produced public transaction volumes. AP2's per-transaction overhead, generating, signing, and verifying a Checkout Mandate and a Payment Mandate plus their receipts, is meaningfully higher than standard card-not-present authentication. Whether issuers will accept that overhead at scale, especially for low-value transactions where the risk-mitigation benefit is small, remains an open question through 2026. Treasury teams running compliant flows for stablecoin movements often use execution-time compliance patterns that look structurally similar to AP2 mandates, which suggests the audit-trail approach is workable; production card-rail proof points are still pending.
​

AP2 specifies the authorization layer; it does not specify which chain the dollars sit on or how they get there. When an agent's credential provider holds USDC on Base and the merchant settles in USDC on Solana, AP2 produces the mandate but does not bridge the funds. Eco operates as the cross-chain stablecoin orchestration layer that fills that gap, abstracting routing, solver selection, and finality across 15 chains for the major dollar-denominated stablecoins. An agent integrated against Eco can satisfy an x402 endpoint anywhere, across cross-chain messaging rails like Hyperlane and Circle's CCTP, without holding a separate wallet or liquidity pool per chain. AP2 mandates compose over this orchestration layer cleanly: the mandate authorizes the user's intent, Eco routes the dollars, x402 confirms settlement, and the merchant gets paid on the chain it expected.
​

What is agentic commerce, the 2026 guide
​Agentic payments: how AI agents pay
​Agent payment protocols compared
​Universal Commerce Protocol (UCP) explained
​x402 protocol explained
​AI agent spend controls
​Why programmable stablecoin treasury automation requires compliance at execution time
​8 best cross-chain messaging protocols (2026)
​

Sources and methodology. Protocol details verified against the AP2 reference repository, the AP2 specification site, and Google's launch announcement. Cryptographic-primitive details (ECDSA P-256, SHA-256, STRIDE/MAESTRO) sourced from the Cloud Security Alliance's October 6, 2025 analysis. PayPal and Mastercard partnership dates from the October 27, 2025 joint press release. Figures refresh quarterly.
​