Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release

Google announced Agent Payments Protocol (AP2) on September 16, 2025 and, unlike most entries in this wiki, published the full spec plus reference implementations to a public GitHub repo the same day rather than only a press release. This page separates what is in that repo and spec site from what is still launch-partner marketing, and traces the version history to the April 2026 donation to the FIDO Alliance.

Publication History and Version Log

AP2 was announced September 16, 2025 (TechCrunch: https://techcrunch.com/2025/09/16/google-launches-new-protocol-for-agent-driven-purchases/), with the spec published the same day to https://github.com/google-agentic-commerce/AP2 and documented at https://ap2-protocol.org/ (both confirmed by Google Cloud Blog: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). The initial release was v0.1-alpha, covering core architecture and common use cases — FONTE: https://eco.com/support/en/articles/15192002-ap2-protocol-explained-google-s-agentic-commerce-standard-2026.

The latest version tracked here is v0.2.0, shipped April 2026, adding "Human Not Present" payments for autonomous agent transactions and support for cards, stablecoins, and real-time bank transfers — FONTE: https://www.pymnts.com/artificial-intelligence-2/2026/google-and-mastercard-contribute-agentic-commerce-standards-to-fido-alliance/. On April 28, 2026 Google donated AP2 v0.2 to the FIDO Alliance, which formally established an Agentic Authentication Technical Working Group and a Payments Technical Working Group to continue standards development — FONTE: https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/. The spec is licensed Apache 2.0 (permissive, commercial use and modification allowed) — FONTE: https://github.com/whillhill/ap2 (repository metadata).

Spec status: published and in a public repo, not just an announcement. This is the key difference from AP4M (Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration), which as of this wiki's check has no public developer spec. See How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page for the general method.

The Three Mandates

AP2 authorizes a purchase through a chain of three cryptographically-signed credentials, each narrowing scope as the transaction proceeds:

Intent Mandate — captures the user's natural-language request and the authorization ceiling *before* a cart exists, built specifically for "human not present" scenarios where no one is watching at transaction time. Fields: the user's natural-language request, an optional NLP-summarized "prompt playback" string, hard constraints (max price, item specifications, expiry/TTL, allowed merchants), and a reference to agent identity — FONTE: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol (purpose); https://www.tenzro.com/docs/ap2 (field structure, secondary source).

Cart Mandate — captures the specific SKU set, price, tax, and shipping total produced by the merchant or merchant-side agent, and binds to the Intent Mandate by hash/reference at construction time. Fields: full item list with SKUs, unit prices, taxes, shipping totals, currency, merchant signature, payment options, expiry, and a flag for whether user confirmation is required — FONTE: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/ (purpose, merchant-signed cart binding); https://www.tenzro.com/docs/ap2 (fields, binding mechanism). Validation requires three axes to all approve: (1) AP2 cart constraints, (2) DelegationScope, (3) a runtime SpendingPolicySnapshot — FONTE: https://www.tenzro.com/docs/ap2.

Payment Mandate — the derived credential the payment network actually sees: it finalizes the transaction, authorizes the clearing-network charge, and ties it to a funding source. Fields: authorized amount, funding instrument reference (card token, wallet address, bank token), and a hash of the matched Intent and Cart — FONTE: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol (purpose); https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/ (chain description and fields). It can be embedded into ISO 8583 flows and existing tokenized-credential rails, or passed standalone — FONTE: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/.

Chain

Intent Mandate (user delegates authority) → Cart Mandate (user approves specific cart at specific price) → Payment Mandate (network-facing derived credential) — FONTE: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/. See Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives and How to Read an AP2 Mandate or Visa/Mastercard Agent Token Schema — telling a populated security field from a permissive one for how this compares field-by-field against AP4M permissioning and Visa/Mastercard token scoping.

Verifiable Credentials as the Encoding

All three mandates are encoded as W3C Verifiable Credentials — a standardized format for cryptographically signed claims — confirmed directly by Google Cloud Blog: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol. Each mandate VC carries an issuer (user, agent, or merchant), a subject (transaction context), a payload (Intent, Cart, or Payment data), and a signature (secondary-source description, unverified against primary spec text directly).

Cryptographic binding

ECDSA over the P-256 curve with SHA-256 integrity hashing, or stronger — reported consistently across secondary sources but not confirmed by a direct primary-spec quote in these notes, so treat the specific curve/hash choice as (unverified, reported by secondary sources). For signature computation over JSON payloads, implementations are reported to require JSON Canonicalization Scheme (JCS, RFC 8785) — also unverified against primary text in these notes.

Verification flow: each mandate is a VC issued by a wallet the user controls, signed with the user's key, and presented by the agent to the merchant or payment processor; the merchant verifies the signature and checks mandate scope before charging — FONTE: secondary-source description, consistent across sources checked but not confirmed against primary spec text directly. This DID-based verification detail should be treated as (unverified, reported by X) rather than confirmed spec text until read directly from the repo's docs/ directory.

Launch Partners vs Shipped, Independently-Verifiable Integrations

At announcement, Google named 60+ launch partners across four groups — FONTE: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol:

- Payments/financial services: Mastercard, American Express, PayPal, Adyen, Ant International, Revolut, Worldpay, JCB, UnionPay International. - Technology/commerce platforms: Salesforce, ServiceNow, Intuit, Adobe, Etsy, Shopee, Global Fashion Group. - Crypto/Web3: Coinbase, Mysten Labs (Sui), MetaMask, Ethereum Foundation, Crossmint. - Consulting/services: Accenture, Deloitte, PwC, Dell, 1Password, Okta, Checkout.com, DLocal, Airwallex.

Being on this list is not the same as having shipped an integration — see How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page step 4 and Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols for the general evidence bar. Applying that bar to AP2's own sources:

- PayPal: Payment Mandate pilots in active development to validate approval rates and ecosystem readiness — FONTE: https://www.pymnts.com/artificial-intelligence-2/2026/google-and-mastercard-contribute-agentic-commerce-standards-to-fido-alliance/. PayPal's own blog is explicit that "specific production integrations have not been completed" and describes its pilots in future-tense language ("could be applied," "is positioned to adopt") — FONTE: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/. Net: pilot/contribution-stage, not production or near-production. - Mastercard: contributed its own Verifiable Intent framework to FIDO alongside AP2, described as "most consequential for card payments" — FONTE: https://blog.google/products-and-platforms/platforms/google-pay/agent-payments-protocol-fido-alliance/. - Coinbase and MetaMask: both reported to have shipped a stablecoin/x402 extension (Agent-to-Agent) at launch, making USDC and other stablecoin rails first-class Payment Mandate funding instruments — FONTE: https://www.pymnts.com/artificial-intelligence-2/2026/google-and-mastercard-contribute-agentic-commerce-standards-to-fido-alliance/. This is the clearest AP2-to-x402 composition point referenced in these notes (see Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against). - Google Gemini Spark: the first product reported to ship with AP2 controls in production — FONTE: https://www.tryrankly.com/blogs/google-io-2026-agentic-commerce-ai-search. The source gives only an indefinite rollout window ("trusted testers this week; broader Pro and Ultra rollout in the coming weeks"), not a specific launch date, and does not mention Google I/O — treat any specific calendar date as unconfirmed. Reported implementation details: spending caps enforced at three granularities (daily/weekly/monthly) in the user's AP2 wallet config, a merchant allowlist, generic "spending limits and Human-Not-Present mandates" gating every purchase (the source gives no numerical threshold — a specific dollar figure would be unverified), and an immutable audit log recording every transaction the agent considers, completes, or is blocked from completing (reasoning, applied user config, merchant, amount, confirmation chain) — same FONTE. This is a first-party (Google) shipped example, not an outside implementation. - Most named retail/enterprise partners — Salesforce, ServiceNow, Adobe, Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair — have no evidence of a production implementation in these notes: UNVERIFIED. PayPal's own roadmap description (standardizing challenge orchestration, extending dispute resolution with mandate-based evidence, moving from curated allowlists to open-standard identity verification) is framed as "positioned capabilities," i.e. planned, not live — FONTE: https://developer.paypal.com/community/blog/PayPal-Agent-Payments-Protocol/.

Net read

of five-plus named categories of partners, only Coinbase/MetaMask (stablecoin extension) and Google's own Gemini Spark have a reported, sourced, shipped integration in these notes; PayPal and Mastercard are pilot/contribution-stage; the rest is unverified press-release presence.

Spec Repository vs Whitepaper/Diagram Claims

The GitHub repo (https://github.com/google-agentic-commerce/AP2) is organized into docs/ (specification, flows, FAQ), code/ (SDK and implementations), samples/ (reference implementations in Python, Go, and Android), and scripts/ — FONTE: WebFetch of the repository. Reference implementations exist in Python, Go, Android, and TypeScript — same source. Sequence diagrams in the spec show the full participant flow (User, Shopping Agent, Credential Provider, Merchant Agent, Merchant Payment Processor) from Shopping Prompt through Intent Mandate confirmation (secondary-source description, unverified against a direct read of the diagram files).

JSON Schema files for exhaustive mandate field definitions are reported to be available in the repository, with a Graphite UI shipped with a sandbox for interactive exploration — this detail is a secondary-source claim in these notes and should be treated as (unverified, reported by X) until the schema files are opened directly; see How to Read an AP2 Mandate or Visa/Mastercard Agent Token Schema — telling a populated security field from a permissive one for the general checklist this page's claims should be run through before citing a specific field as required vs optional.

The A2A x402 crypto extension is described as "production-ready" and already launched as of the FIDO donation announcement — FONTE: https://www.fstech.co.uk/fst/Google_Donates_Agent_Payments_Protocol_To_Develop_Open_Standards_For_Agentic_Payments.php. Taken together with the repo structure, AP2's spec status is: published as executable open-source code and documentation, not confined to a whitepaper or a diagram-only announcement — the strongest "spec vs press release" answer of the protocols surveyed for this wiki so far.

What Does NOT Work / Is Not Yet Confirmed

- The specific cryptographic parameters (ECDSA P-256, SHA-256, JCS/RFC 8785) are consistent across secondary sources in these notes but were not confirmed by a direct quote from the primary spec text — flagged unverified above rather than stated as fact. - "60+ launch partners" is a press-release count, not a count of shipped integrations; this page found dated, sourced evidence of a shipped integration for only two of them (Coinbase/MetaMask, Google's own Gemini Spark) — PayPal and Mastercard remain pilot/contribution-stage, not production. - No transaction-volume or dollar figures for any AP2-based flow were found in these notes — this page cannot state how much money has actually moved through AP2 mandates, only that specific products (Gemini Spark) have shipped.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — AP2 is the clearest working example in this wiki of a mandate layer explicitly composing with a settlement rail: the Coinbase/MetaMask x402 extension turns a Payment Mandate into a stablecoin transfer. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration — the direct contrast case: an announced authorization layer with no public developer spec, versus AP2's public GitHub repo and reference implementations. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — apply the same launch-partner-vs-shipped-integration test used here across all five protocols in this wiki to rank them. - Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives — where AP2's three-mandate chain sits against AP4M permissioning, Visa token scoping, ACP payment tokens, and Coinbase wallet policies field-by-field. - How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page — the method this page followed: primary spec over press release, outside implementation over launch-partner list, and every unverified secondary-source claim flagged rather than stated as fact.