A2A x402: Google's Agent Payments Extension
The A2A x402 extension brings on-chain cryptocurrency payments to Google's Agent-to-Agent protocol. Backed by 60 organizations including Mastercard, PayPal, American Express, Coinbase, MetaMask, and the Ethereum Foundation. Same payment data structures as canonical x402 V2. New JSON-RPC transport. New AgentCard-based discovery layer. This page is the working reference.
Google convinced 60+ organizations across card networks, acquirers, crypto infrastructure, marketplaces, and enterprise platforms to stand behind one agent-payments protocol. A coalition that size has not formed around a payments standard since ISO 8583 in the 1980s.
Full editorial analysisWho is in the coalition
Named coalition members from public launch coverage, grouped by category. The mix is the message: card networks and crypto infrastructure are sitting at the same table.
- Mastercard
- American Express
- JCB
- UnionPay International
- Adyen
- PayPal
- Worldpay
- Coinbase
- Circle
- MetaMask
- Ethereum Foundation
- Mysten Labs
- Etsy
- Salesforce
- ServiceNow
- Intuit
- Forter
- Revolut
- Ant International
The payment flow
Three steps over A2A messages. Same data shapes as canonical x402, packaged in JSON-RPC instead of HTTP headers.
The Merchant Agent receives a service request and decides payment is owed. It returns a Task with state input-required and stamps metadata.x402.payment.status with 'payment-required' plus metadata.x402.payment.required carrying the PaymentRequirements (scheme, network, asset, payTo, maxAmountRequired).
The Client Agent picks a PaymentRequirements option, has its wallet or signing service produce a signed PaymentPayload, and sends an A2A message back to the merchant containing the original taskId, metadata.x402.payment.status of 'payment-submitted', and metadata.x402.payment.payload.
The Merchant verifies the signature, settles on-chain through an x402 facilitator, then returns an updated Task. metadata.x402.payment.status moves to payment-completed, and metadata.x402.payment.receipts gets the transaction hash and network appended. The receipts array is persistent across the lifetime of the Task; every attempt is logged.
Discovery via AgentCard
A2A merchants publish an AgentCard at /.well-known/agent-card.json listing skills, endpoints, and declared extensions. The Global A2A Registry at a2a-registry.org aggregates these cards with DNS-TXT-based domain verification. The registry exposes its own discovery endpoint so agents can find merchants programmatically rather than hardcoding URLs.
How it relates to canonical x402 V2
Canonical x402 V2 (the version TensorFeed serves over HTTP) and A2A x402 use identical data structures. PaymentRequirements is the same. PaymentPayload is the same. The networks, schemes, asset identifiers, EIP-3009 settlement, and receipt shapes are all shared. Only the transport differs: HTTP 402 plus headers for one, JSON-RPC messages with metadata.x402.* fields for the other.
The practical implication: any merchant already serving canonical x402 V2 with a hosted facilitator and signed receipts is most of the way to A2A compliance. The work that remains is a JSON-RPC adapter that translates A2A messages into the existing payment flow. The settlement code does not change. The discovery surface does (AgentCard + a2a-registry.org are net-new).
TensorFeed plans to ship that adapter in a focused session. Until then, agents that natively speak A2A need to call our HTTP endpoints through a translation layer or wait for the wrapper. Watch /originals for the shipping announcement.
A2A x402 is one of three major agent-payments rails converging on USDC on Base with Coinbase as facilitator. AWS AgentCore Payments uses the same primitives. Hyperliquid standardized USDC as the trading-collateral side. The agent economy plumbing is collapsing into one asset, one chain, one custodian. The protocol surface differs; the money does not.
FAQ
What is the A2A x402 extension?
It is an official extension of Google's Agent-to-Agent (A2A) protocol that lets agents charge each other for services with on-chain cryptocurrency payments. Initially released September 2025 (v0.1), now at v0.2 with an embedded composable flow that allows x402 to act as a payment leg inside higher-level commerce protocols like AP2. The repository is google-agentic-commerce/a2a-x402, currently at 505 GitHub stars.
How is A2A x402 different from canonical x402 V2?
Same data structures, different transport. Canonical x402 V2 (the version most early ecosystem merchants implement, including TensorFeed) signals payment-required with an HTTP 402 response, a PAYMENT-REQUIRED header, and a WWW-Authenticate challenge, then accepts payment on retry via an X-PAYMENT header. A2A x402 wraps the same PaymentRequirements and PaymentPayload structures inside JSON-RPC messages on the Agent2Agent protocol, using metadata.x402.* fields on Task and Message objects. The settlement layer (EIP-3009, USDC, Base, facilitators) is identical.
What is the extension URI an agent must declare?
For v0.2 (current): https://github.com/google-agentic-commerce/a2a-x402/blob/main/spec/v0.2. For v0.1: https://github.com/google-a2a/a2a-x402/v0.1. The URI gets declared in the capabilities.extensions array of the merchant agent's AgentCard, with required:true recommended. Clients activate the extension by including the URI in the X-A2A-Extensions HTTP header on their request.
How do A2A agents get discovered?
Through an AgentCard at /.well-known/agent-card.json on the merchant's domain. The card lists capabilities, skills, endpoints, and declared extensions. Beyond self-discovery, the community-run Global A2A Registry at a2a-registry.org aggregates cards, verifies domains with a DNS TXT record (a2a-registry-verify=<token>), and exposes a discovery API that other agents query programmatically. The registry calls itself the DNS for AI agents.
Does TensorFeed serve the A2A x402 extension today?
TF serves canonical x402 V2 over HTTP today, which uses the same PaymentRequirements and PaymentPayload data structures. The A2A JSON-RPC wrapper is a separate adapter on the TensorFeed roadmap. Once shipped, the same Coinbase facilitator, AFTA receipts, and OFAC screening get reused; only the transport changes. Until then, A2A native clients cannot call TF endpoints directly. Treat this page as the canonical reference for the protocol, not a TF-implementation claim.
Who is in the AP2 coalition?
According to Google, 60+ organizations. Public coalition members named in launch coverage include Mastercard, American Express, JCB, UnionPay International, Adyen, PayPal, Worldpay, Coinbase, Circle, MetaMask, Ethereum Foundation, Mysten Labs, Etsy, Salesforce, ServiceNow, Intuit, Forter, Revolut, and Ant International. The coalition is the actual story; the spec is the artifact.
Where do AP2 and the A2A x402 extension differ?
AP2 (Agent Payments Protocol) is the umbrella commerce protocol. It defines the high-level interactions between agents around mandates (CartMandate, PaymentMandate, etc.). The A2A x402 extension is the on-chain payment leg that AP2 can use as its 'Form of Payment.' AP2 v0.2 explicitly supports embedding x402 PaymentPayload objects inside its CartMandate and PaymentMandate structures, which is why the spec calls out a Standalone Flow versus an Embedded Flow.
What is the relationship to Coinbase x402 Bazaar?
Bazaar (cdp.coinbase.com) catalogs HTTP x402 V2 merchants for agent discovery, requires you to settle through Coinbase's CDP facilitator, and produces a marketplace UI plus a /discovery API. A2A x402's Global Registry catalogs A2A-protocol merchants (JSON-RPC transport) with self-published AgentCards. Same merchant could in principle list in both surfaces if it implements both transports. Both rely on the same underlying x402 payment guarantees.