Google Just Put 60 Payment Companies Behind a Crypto-Native Agent Rail

The repository for Google's A2A x402 payments extension got a commit yesterday. That on its own is unremarkable. What is remarkable is the lineup of names that have attached themselves to the standard around it. Mastercard. American Express. PayPal. Adyen. Worldpay. JCB. UnionPay. Revolut. Intuit. Etsy. Salesforce. ServiceNow. Ant International. Forter. Then in the same announcement: Coinbase. Circle. MetaMask. The Ethereum Foundation. Mysten Labs. Sixty organizations total, according to Google's own announcement, behind a single protocol for agent commerce. A coalition that size has not formed around a payments standard since ISO 8583 in the 1980s. And this one is built to settle on-chain.

What actually shipped

The umbrella is the Agent Payments Protocol, AP2. Google announced AP2 in September 2025 with the headline that agents would be able to negotiate and execute payments without a human in the loop. Underneath AP2 sits a thinner, more concrete spec called the A2A x402 extension, hosted at google-agentic-commerce/a2a-x402. v0.1 dropped September 16, 2025. v0.2 is now active with an expanded composable flow that lets x402 act as a payment leg inside higher-level commerce protocols. 505 stars at time of writing, last commit yesterday.

The role A2A x402 plays in the stack is narrow but load-bearing. It says: when one agent owes another agent money for a service, here is the exact data structure the merchant sends, here is the exact data structure the client signs back, and here is how the receipt gets stapled to the response. The shapes are not new. They are taken directly from the canonical x402 protocol that TensorFeed has been serving for months. PaymentRequirements with scheme, network, asset, payTo, and maxAmountRequired. A signed PaymentPayload. A receipt with a transaction hash. The data structures are identical to what the Coinbase facilitator already accepts.

The transport is what is new

The same plumbing flows through different pipes. Canonical x402 V2, which TensorFeed and most of the early ecosystem implement, signals payment-required with the HTTP 402 status code, a PAYMENT-REQUIRED header carrying a base64 PaymentRequired body, a WWW-Authenticate challenge per RFC 7235, and an X-PAYMENT header on the retry. It is a web protocol. A2A x402 wraps the same data inside JSON-RPC messages on Google's Agent2Agent transport. The merchant returns a Task object with state input-required and metadata fields x402.payment.status set to payment-required and x402.payment.required carrying the PaymentRequirements. The client signs and replies with another A2A message carrying x402.payment.payload. The merchant verifies, settles, and closes the Task with x402.payment.status of payment-completed and a receipts array stapled to the response.

This matters because A2A is the language Google's agent platform speaks. An A2A client cannot call an HTTP x402 merchant directly today. The wrapper is missing on one side or the other. The fix is small, the protocol surface is well-defined, and the settlement layer is identical to what most x402 V2 merchants already run. But until the wrapper exists, A2A agents and HTTP agents are looking at each other through glass.

Discovery has its own answer

A2A merchants do not register in a paid-API directory the way HTTP merchants do. They publish a manifest at /.well-known/agent-card.json that lists their skills, their endpoint, and their declared extensions. The x402 extension URI sits in the capabilities.extensions array. A community-run Global A2A Registry aggregates these cards, verifies domain ownership through a DNS TXT record, and exposes a discovery API that other agents can query. The registry calls itself the DNS for AI agents. It is the analog of x402scan or Coinbase's Bazaar, but for A2A-native merchants instead of HTTP merchants.

The structural implication for agent-discovery work is that the directory layer is bifurcating along transport lines, not along payment lines. The same merchant might list once in x402scan for its HTTP surface and once in the A2A Registry for its JSON-RPC surface, even though the money behind both calls is the same USDC moving across the same Coinbase facilitator on the same Base network.

What 60 logos in one room actually says

The signaling content of the coalition matters more than the spec itself. Card networks (Mastercard, AmEx, JCB, UnionPay) are sitting at the same table as crypto infrastructure (Coinbase, Circle, MetaMask, Ethereum Foundation, Mysten Labs). PSPs and acquirers (Adyen, Worldpay, PayPal) are there too. Marketplaces (Etsy). Application platforms (Salesforce, ServiceNow). Risk and fraud (Forter). Banking-as- a-service (Revolut, Ant International). Tax and accounting (Intuit). This is not a crypto club showing up for an industry adjacency moment. This is the payments industry as it exists today, agreeing to share a protocol for a category that does not yet have meaningful transaction volume.

The acceptance side of agent commerce is being built before the demand side has arrived. That is the inverse of how almost every consumer payment standard rolled out. Apple Pay was built after iPhones owned the market. The card networks added tokenization after card-not-present fraud became unsupportable. Even ACH and SEPA followed clear pre-existing demand. With agent payments, the rails are being laid first, and the assumption is that agentic transaction volume will materialize later.

The flip side of that bet: anyone who waits to ship until the demand is obvious will be late. The protocol calcification window is right now, not a year from now. The coalition has signaled it intends to standardize before transaction volume forces the issue. Builders who are not on canonical x402 V2 today are looking at a months- long port, not a weeks-long one, because the data structures, the OFAC screening, the facilitator integration, the receipt signing, and the discovery surfaces all interlock.

Our Take

The bet TensorFeed made on canonical x402 V2 six months ago (USDC, Base, Coinbase facilitator) just got endorsed by a coalition larger than any other payments standard of the decade. The settlement layer maps one to one. PaymentRequirements is the same. PaymentPayload is the same. The networks supported are the same. EIP-3009 transferWithAuthorization is the same. AFTA receipt signing maps to the x402.payment.receipts array with no semantic loss.

What remains is the JSON-RPC wrapper. That is protocol shimming, not foundational rebuild. We will ship the A2A adapter in a focused session, publish an AgentCard at /.well-known/agent-card.json, and register with the Global A2A Registry once the wrapper is verified. The same work is months long for anyone who is not already serving canonical x402 V2 with a hosted facilitator, OFAC screening, and signed receipts. The coalition just published the destination. The merchants who are not already most of the way there are about to find out how far away they actually are.

The story today is not that Google is trying to win payments. The story is that Google convinced sixty payment companies, including ones that hate each other in every other context, to stand behind the same agent rail. The signal that sends to enterprises evaluating which agent-payments protocol to adopt is not subtle.