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 three mandate types, 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.org 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 JSON-LD 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 chains three cryptographically signed mandates: an Intent Mandate (user delegates authority), a Cart Mandate (user approves a specific cart at a specific price), and a Payment Mandate (a derived credential the network sees). Together they form a non-repudiable audit trail of who authorized what, within what limits. The merchant verifies the signatures before submitting payment.
​

The flow has six steps in the human-present case. (1) The user asks an agent for something — "find me white running shoes under $150." (2) The agent generates an Intent Mandate that captures the request and any constraints, but in human-present mode this is informational rather than authoritative. (3) The agent shops, returns options, and the user picks one. (4) The merchant generates a Cart Mandate listing the exact items, prices, taxes, and shipping. (5) The user cryptographically signs the Cart Mandate using a hardware-backed device key, producing the binding authorization. (6) The merchant validates the signature, derives a Payment Mandate, attaches it to the standard payment authorization message (ISO 8583 for cards), and sends it to the issuer. The issuer sees a normal authorization with extra mandate metadata that signals an agent-initiated transaction.
​

The human-not-present flow runs differently. The user signs an Intent Mandate upfront with explicit constraints — price cap, time window, merchant allowlist, item specification, "prompt playback" (a natural-language summary of the user's intent the merchant can display back). The agent then operates without further human approval until conditions are met. When the cart materializes, the agent generates the Cart Mandate algorithmically, the Intent Mandate's signature provides the binding authorization, and the rest of the flow proceeds as in the human-present case. Descope's AP2 walkthrough covers the same flow with credential-provider role detail.
​

Two things sit outside this flow. The first is payment movement — AP2 does not move dollars. Once the issuer receives the Payment Mandate, the card network settles via the standard card-rail path; 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, not to an agent; 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 JSON-LD documents structured as W3C Verifiable Credentials and signed using ECDSA over P-256 (or stronger) curves with SHA-256 integrity hashing. Each carries the user's request payload, a timestamp, a nonce, the signer's public key reference, and the signature. Merchants resolve the signer's public key through a DID method and validate against the document.
​

The three mandate types carry different payloads. The Intent Mandate contains the user's natural-language request, an optional NLP-summarized "prompt playback" string, hard constraints (max price, item specifications, expiry / TTL, allowed merchants), and the agent's identity reference. It establishes that the user delegated authority for this kind of purchase. 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 Cart Mandate is the most operationally important of the three. The merchant assembles it: full item list with SKUs, unit prices, taxes, shipping, totals, currency, and the merchant's own signature over the cart contents. The user then signs the merchant-signed cart, producing a co-signed credential. This co-signature is the "what you see is what you pay for" guarantee — the merchant cannot change the cart after the user signs, and the user cannot deny having seen the cart contents. Hardware-backed device keys (TPM, Secure Enclave, Android StrongBox) are the recommended signing path for in-session human-present approval.
​

The Payment Mandate is derived from the Cart or Intent Mandate and contains a minimal subset suitable for the network: hashed payment-method reference, transaction amount, a flag indicating human-present vs human-not-present, and a pointer to the upstream Cart Mandate. The Payment Mandate is what the issuer's risk engine ingests. It does not expose the user's PII or the cart's full contents to the card network — the credential provider keeps payment data isolated. PayPal's AP2 community post describes how Payment Mandates surface the agent-presence flag inside existing PayPal flows.
​

The credential provider is a fourth role in the protocol that often goes unmentioned. It is the entity that holds the user's payment instrument and produces a tokenized payment reference for inclusion in the Payment Mandate. 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. 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 cart contents at a specific timestamp using a hardware-backed device key. A merchant or network can later verify the user signed that cart, at that price, within that intent envelope. 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 cart after signing breaks signature validation. Bind-to-context: the cart's hashed contents are the document being signed, so the signature commits to the cart and only that cart — the agent cannot reuse the signature for a different cart, a different merchant, or a different price. 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 cart 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 Cart 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 the Intent Mandate. 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.com/google-a2a/a2a-x402 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 Intent Mandate before its TTL expires. If the user signs an Intent Mandate 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 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 three mandates — 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.
​