Google's Agent Payments Protocol (AP2) Authorizes the Transaction. It Does Not Score the Counterparty Agent.

Google announced AP2 on 2025-09-16 as "an open protocol developed with leading payments and technology companies to securely initiate and transact agent-led payments across platforms." The three problems AP2 addresses, in Google's own words, are Authorization ("Proving that a user gave an agent the specific authority to make a particular purchase"), Authenticity ("Enabling a merchant to be sure that an agent's request accurately reflects the user's true intent"), and Accountability ("Determining accountability if a fraudulent or incorrect transaction occurs"). Notice what is not on that list: whether the counterparty agent is real, reachable, or worth paying. Two days ago we argued that Cloudflare Wallets shipped the buyer-side rail without the trust filter; AP2 is the second commoditising payments rail arriving under the same gap, from a different vendor, three weeks apart.

Published 16 August 2026. Third-party quotes below are verbatim from the linked sources with the publication date; every OUR-OWN count is a live /v1/public/stats figure refreshed on every visit. Category framing, not a fresh measurement — the measurements it stands on (the 6.5% signpost gap dataset, the 97.9% top-10 concentration) are our own prior published work, cross-linked so a reader can walk to the raw numbers.

What AP2 is, from primary sources

Per Google's announcement, AP2 is "an open, shared protocol that provides a common language for secure, compliant transactions between agents and merchants, helping to prevent a fragmented ecosystem." The AP2 specification site (v0.2 at time of writing) defines two mandate types on top of Verifiable Data Credentials:

Checkout Mandate — "captures the reference to the specific items and purchase details negotiated between the agent and the merchant."
Payment Mandate — "authorizes a payment against a specific payment instrument."

The mechanism is "Mandates—tamper-proof, cryptographically-signed digital contracts that serve as verifiable proof of a user's instructions. These mandates are signed by verifiable credentials (VCs) and act as the foundational evidence for every transaction" (Google Cloud, 2025-09-16). The reference implementation at google-agentic-commerce/AP2 is Apache-2.0 licensed. Samples in the spec repo include a "Human Not Present x402" path, and the sibling google-agentic-commerce/a2a-x402 repository documents the A2A extension that "brings cryptocurrency payments to the Agent-to-Agent (A2A) protocol," listing "x402 Protocol: The underlying payment protocol" and "AP2 Protocol: The Agent Payments Protocol" as separate but related layers.

Launch partners named in the Google announcement include "a diverse group of more than 60 organizations… including Adyen, American Express, Ant International, Coinbase, Etsy, Forter, Intuit, JCB, Mastercard, Mysten Labs, Paypal, Revolut, Salesforce, ServiceNow, UnionPay International, Worldpay, and more." Coinbase's side of that partnership is discussed in a Coinbase Developer Platform launch note (URL: coinbase.com/developer-platform/discover/launches/google_x402) which our automated fetcher could not verify at time of publication (Cloudflare bot challenge / HTTP 403 on our fetch). We deliberately do not cite the "first and only stablecoin facilitator" phrasing that has been circulating alongside AP2 coverage; the Google announcement lists Coinbase inside the 60+ partner block without singling it out as facilitator, and we drop unverifiable claims by policy rather than reprint them (this is the same discipline that pinned the x402 concentration numbers to x402-list.com/api/v1/stats rather than to secondhand summaries of it).

The category shape: what AP2 handles vs what it does not

Layer	Handled by AP2	Handled by the counterparty-quality layer we ship
User-authorised the purchase	Yes — Checkout Mandate + Payment Mandate signed by user's VCs.	No — out of scope. AP2 solves it correctly for the transaction.
Transaction intent authentic	Yes — the Authenticity pillar; cryptographically-signed Mandates are the evidence.	No — also out of scope.
Accountability trail	Yes — the Accountability pillar; VCs are the tamper-evident record.	No — also out of scope.
Counterparty agent is real (persistent on-chain identity, resolvable off-chain endpoint)	Not addressed — nothing in AP2's three pillars covers whether the merchant-side agent is who it says it is beyond a signed transaction.	ERC-8004 identity (persistent on-chain agentId + CAIP-10 addressability) + the signpost-gap dataset (only — indexed, of which — answer at their endpoints).
Counterparty has been paid before for the work (real got-paid history, not just a registration)	Not addressed — AP2 records the current transaction; it does not carry a rollup of the counterparty's prior settlement history.	Commerce-backed reputation — — agents whose ReputationRegistry rows tie back to real, paid on-chain job outcomes (ERC-8183 / Virtuals ACP), under the canonical predicate at `smartcontractauditpro/commerce_backed.py`. Continuously indexed since —.
Who pays whom (counterparty's inter-agent payment graph)	Not addressed — per-transaction, not economy-wide.	Free 200-node graph teaser + paid `/v1/intel/graph` and `/v1/intel/peers/{agent_id}` endpoints (API docs).

None of the "not addressed" rows are a criticism of AP2. They are the same category framing we applied to Cloudflare Wallets two days ago: an internet-native payments rail is genuinely useful and the transaction-authorisation layer is a legitimate, load-bearing problem. It is a different problem from should this agent be paid.

Why this matters: two rails, one missing layer

Three data points from our own prior work explain the shape of the gap this second rail widens rather than closes:

The signpost gap. Only 1,604 of 24,835 indexed Base + Ethereum ERC-8004 registrations (6.5%) publish a discoverable /.well-known/agent-card.json — the standard A2A capability manifest a discovery client needs to walk from the on-chain identity to a payable endpoint. Full breakdown, per-chain cuts, methodology, and machine-readable exports at the signpost-gap dataset and the data hub (both CC BY 4.0, JSON + CSV). The number stays the same regardless of which payment rail the buyer is using; AP2 does not close it, Cloudflare Wallets does not close it.
Demand concentration. Across 423 measured x402 services the top ten account for 97.9% of settled USDC volume — independently measured by x402-list.com on the demand side and reconciled with our own supply-side catalog scan in the concentration reconciliation. The rails carry a lot of small payments; the money concentrates on a tiny handful of counterparties. A wider directory of newly-walleted, newly-mandated agents is not the constraint on that shape; a working trust filter is.
The registry, measured. Imperial College's arXiv:2606.26028 (CC BY 4.0) reports that the ERC-8004 ReputationRegistry "cannot function as a trust signal" in its current deployed state (Ethereum 3%, BSC 4%, Base 15% pass the paper's trust bar) — the shape our own live index continues to measure. AP2 and x402 are payments rails; even the on-chain reputation layer that sits under them, treated as-published, is not enough. Commerce-backed reputation is a stricter cut because it demands a paid on-chain job outcome, not a self-reported feedback row.

Where the AP2 mandate stack could be walked into our stack

We do not implement AP2 today. The category-shape observation that matters for our roadmap is that AP2's Payment Mandate, when carried over an x402 rail (the "Human Not Present x402" sample in the spec repo, or the a2a-x402 extension), settles into exactly the same quality.l30DaysUniquePayers counter our market map already indexes off the CDP Bazaar. In other words, a healthy AP2 economy would move demand-side counters we already publish, and the trust filter we already publish is the counterparty-quality signal it would need. Concretely:

Our served agent.json for agentId 19353 on Base is the ERC-8004 identity a Payment-Mandate merchant would resolve; the signpost dataset measures how many other agents even show up at that step.
Our 11 paid x402 endpoints on api.onchainagentintel.io serve V2 402 challenges with USDC settlement on Base and Ethereum mainnet — the same wire format an AP2 Payment Mandate would carry to a stablecoin facilitator.
Our free MCP server and the paid /v1/intel/* family surface the counterparty-quality signals ( got-paid history, payment graph, capability map) an AP2-aware merchant — or a Cloudflare-Wallets-aware buyer — would need before authorising a Mandate against an unfamiliar counterparty.

Backing all of it is a continuous live index — — ERC-8004 agents on Base + Ethereum, of which — answer at their advertised endpoints (Base —%, Ethereum mainnet —%), with — feedback events indexed. Same universe AP2 mandates would touch; the trust-filter cut is what stays scarce.

The commoditisation window

Read AP2 in the sequence of announcements this year:

2026-07-14 — Linux Foundation announces the operational launch of the x402 Foundation with premier members including Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Ripple, Shopify, Stripe, and Visa.
2026-08-04 — Cloudflare Wallets ships buyer-side wallets with "Stablecoin micropayments via x402" and a cloudflare.pay identity.
2025-09-16 — Google announces AP2 as a merchant-and-agent mandate protocol with 60+ launch partners, an Apache-2.0 reference implementation, and explicit x402 sample paths.
2026-08-13 — Yahoo Finance: x402 settlement volume down ~93% YTD while payment count keeps climbing. The paradox only resolves one way — the scarce good is knowing which counterparty is real.

Two rails in three weeks under the same missing layer. This is the commoditisation window a counterparty-quality product ships into: not competing with the rails, sitting on top of them.

Attribution and reuse

Primary sources: the Google Cloud AP2 announcement (2025-09-16), the AP2 specification site, the Apache-2.0 reference implementation, and the a2a-x402 extension repo. Third-party quotes above are verbatim from those sources at time of fetch. We deliberately dropped one widely-reprinted claim (that x402 is AP2's first and only stablecoin facilitator) because the Coinbase Developer Platform page it usually cites returned a Cloudflare bot challenge to our automated fetcher and we do not publish sentence-form facts we cannot verify.

Our own measured cuts in this page — the 6.5% signpost figure, the 97.9% concentration figure, and the live-index counts — are drawn from the signpost-gap dataset and the x402 concentration reconciliation respectively. Every OUR-OWN count on this page is served from /v1/public/stats and refreshes on every visit. Redistribution of the framing and OUR-OWN measured cuts is welcome under CC BY 4.0 with a link back to this page. Third-party quotes are the property of their respective publishers.