A2A x402: the extension that lets agents charge agents

A2A carries the message. AP2 gives it shape. x402 moves the money. The A2A x402 extension is the small piece of spec that wires the three together — and turns any agent into a service that can charge another agent.

We have written about each of these layers on its own. A2A lets agents discover and delegate to each other. AP2 defines the mandate — the signed authorization that says a user (or a delegating agent) approved a purchase. x402 settles a payment onchain over plain HTTP. The gap was always the seam: how does a running A2A task actually stop, ask for money, take a signed authorization, settle it, and hand back a receipt — without breaking the conversation model that A2A is built on?

The answer is a formal A2A extension. Google published it as a2a-x402, co-developed with Coinbase, the Ethereum Foundation, and MetaMask, alongside the AP2 launch in September 2025. It is small on purpose. It adds no new transport, no new RPC surface, no new signing scheme. It adds a payment state machine and a handful of metadata keys that ride on the A2A Task you already have. This post reads the v0.1 spec.

Where it sits: three protocols, one seam

Keep the responsibilities separate and the design stops being confusing:

• A2A is the transport and the conversation. It moves Message and Task objects between a client agent and a server agent.
• AP2 is the shape of the authorization — the mandate that ties an intent to a payer, agnostic to whether the rail is a card or a stablecoin.
• x402 is the settlement primitive: a PaymentRequirements object, a signed PaymentPayload, and a facilitator that runs /verify and /settle against a chain.

The extension is the connective tissue. It says: when an A2A task needs payment, express the x402 PaymentRequirements inside A2A metadata, pause the task, and resume it once a valid PaymentPayload arrives. AP2 mandates carry through so the settled crypto payment inherits the same audit trail a card payment would get. That last part matters — it is why this is an AP2 extension and not just an x402 wrapper.

Turning it on: the Agent Card and the header

Extensions in A2A are opt-in and advertised. A merchant agent declares support in its Agent Card under capabilities.extensions, keyed by a URI that doubles as the version identifier:

{
  "capabilities": {
    "extensions": [
      {
        "uri": "https://github.com/google-a2a/a2a-x402/v0.1",
        "description": "Supports payments using the x402 protocol for on-chain settlement.",
        "required": true
      }
    ]
  }
}

A client that wants to use it activates the extension per request with an HTTP header:

X-A2A-Extensions: https://github.com/google-a2a/a2a-x402/v0.1

The server echoes the same URI back in its response header to confirm the extension is live for that exchange. Nothing about the payment happens until both sides have acknowledged the URI. That handshake is the entire activation surface — deliberately boring, because the interesting part is the state machine.

The state machine

The extension defines a linear progression carried on a single field, x402.payment.status, in A2A message metadata. The happy path is four states; two more cover failure:

// happy path
payment-required   // merchant: I need payment to continue
payment-submitted  // client: here is a signed authorization
payment-verified   // merchant: signature and terms check out
payment-completed  // merchant: settled onchain, here is the receipt

// failure branches
payment-rejected   // merchant refused the submitted payment
payment-failed     // settlement broke after a valid submission

The elegance is that these states map onto the A2A Task lifecycle instead of inventing a parallel one. When a merchant needs money, it does not error out. It moves the task to A2A's own input-required state and attaches x402.payment.status: "payment-required" plus an x402.payment.required object. From the client's perspective this is the same pattern as any task that needs more input — it just happens that the input is a signature over money.

The data structures

Four objects do the work. They are lifted straight from the x402 v2 spec, which keeps the extension honest — a facilitator does not need to learn A2A to settle these.

The merchant advertises what it will accept with x402PaymentRequiredResponse, which is just a version and a list of acceptable terms:

// x402PaymentRequiredResponse
{
  "x402Version": 1,
  "accepts": [ /* PaymentRequirements[] */ ]
}

// PaymentRequirements — one acceptable way to pay
{
  "scheme":            "exact",
  "network":           "base",
  "asset":             "0x833589...USDC",
  "payTo":             "0xMerchant...",
  "maxAmountRequired": "1000000",   // 1.00 USDC, 6 decimals
  "resource":          "https://api.merchant/report",
  "description":       "Q3 risk report",
  "maxTimeoutSeconds": 120
}

The client signs and answers with a PaymentPayload. The payload field is opaque to A2A — its contents depend on the scheme and network. For the exact scheme on an EVM chain it carries an EIP-3009 transferWithAuthorization signature, the same gasless primitive we took apart previously:

// PaymentPayload
{
  "x402Version": 1,
  "network":     "base",
  "scheme":      "exact",
  "payload":     { /* signed EIP-3009 authorization */ }
}

After settlement the merchant returns an x402SettleResponse — success flag, the onchain transaction hash, the payer, and an error reason if it failed:

// x402SettleResponse
{
  "success":     true,
  "transaction": "0xabc...tx",
  "network":     "base",
  "payer":       "0xClient..."
}

Metadata keys: the whole protocol on the Task

The extension never touches the body of an A2A message. Everything lives in metadata, which is why it composes cleanly with any A2A agent. Five keys carry the flow:

• x402.payment.status — the current state (the six values above).
• x402.payment.required — the x402PaymentRequiredResponse, set by the merchant on the payment-required message.
• x402.payment.payload — the signed PaymentPayload, set by the client on the payment-submitted message, correlated back to the request by the original taskId.
• x402.payment.receipts — an array of every x402SettleResponse produced during the task. It is append-only: never replaced, always grown.
• x402.payment.error — a short machine-readable code on failure, such as insufficient_funds.

The append-only receipts rule is the audit story. The spec requires that all receipts created during the lifetime of a task appear in the final TaskStatus.message. A single task might involve several payments — a research agent that pays three data providers before answering — and every settlement is preserved, in order, on the object that closes the task. That is the AP2 audit trail expressed in x402 terms: not a log you have to reconstruct, but state that travels with the work.

Security: the model never holds the key

The spec is blunt about the one rule that matters for autonomous agents: private keys must never be handled by the LLM. Signing happens in a trusted signing service, and the model only ever sees the request to sign and the resulting PaymentPayload. This is the same separation we argued for in the agent threat model — the reasoning layer proposes, a constrained signer disposes. A prompt injection that reaches the model cannot exfiltrate a key it was never given.

The rest of the security surface is inherited rather than reinvented. Replay protection is mandatory and comes from nonce tracking; on EVM chains the EIP-3009 contract enforces nonce uniqueness at the token level, so a captured authorization cannot be settled twice. Authorizations carry explicit time windows via maxTimeoutSeconds. And because the merchant runs verification before settlement, a malformed or under-funded payload is rejected at payment-rejected without ever touching the chain.

Functional core, imperative shell

The reference implementation — Python, as x402_a2a — splits into two layers the spec calls a functional core and an imperative shell. The core protocol is pure: functions that build PaymentRequirements, verify a signature, and shape a settle response, with no I/O. The executors are middleware that wrap an existing A2A agent and drive the state machine automatically — intercept the outgoing task, inject payment-required, wait for payment-submitted, call the facilitator, append the receipt. You can adopt the executor for a hands-off integration, or call the core functions directly if you need custom payment logic. It is a clean shape, and one worth copying regardless of the payment rail.

What it means for LLM4Agents

LLM4Agents already speaks x402 at the gateway: an agent pays per inference call in stablecoins with no invoice, no card, no account. The A2A x402 extension extends that same economic model outward — from the agent paying us, to the agent paying other agents it delegates to. That is the missing half of a real agent economy. An agent that earns by answering questions should also be able to spend, mid-task, on the data and compute it needs, over the exact same rail.

Concretely, the extension is a natural fit above our stack. The signing-service rule maps onto how we already think about agent wallets and delegated authority — the model reasons, a scoped signer settles. The append-only receipts map onto the billing internals we described in reserve, proxy, settle: every settlement is a durable record, not a reconstructed log. And because the extension reuses x402 v2 types verbatim, an agent that pays an LLM4Agents endpoint and an agent that pays a peer over A2A are signing the same shape of authorization. One wallet, one settlement primitive, two directions of payment.

The threat is the mirror of the opportunity. If A2A x402 becomes the default way agents charge each other, a gateway that only accepts payment but cannot help an agent make payments outbound is half a platform. The economic graph is bidirectional; the infrastructure has to be too.

Staying on the frontier

Concrete steps, in order.

First, support the extension as a merchant. Any LLM4Agents-hosted endpoint that another agent might call should be able to advertise x402.payment.required and settle a payment-submitted authorization. The v2 types already match what we accept at the gateway, so this is wiring, not redesign.

Second, ship an outbound signer. Give agents a scoped signing service that can produce a PaymentPayload for a peer's PaymentRequirements without ever exposing the key to the model. This is the piece that lets an agent spend, not just earn, and it reuses the wallet and identity work already in flight.

Third, make receipts first-class. Persist the append-only x402.payment.receipts array as part of an agent's billing history, so a delegating agent can prove what it paid downstream. Combined with AP2 mandate context, that is a complete, portable audit trail across the whole delegation chain.

Fourth, track the schemes directory. v0.1 ships exact; the spec leaves room for upto and deferred schemes drafted by partners. Per-token and per-second pricing is exactly the metered model inference wants. When a metered scheme stabilizes, an OpenAI-compatible gateway that already bills per token is the most natural place to settle it.

The layers stopped being separate protocols the moment this extension shipped. A2A discovers, AP2 authorizes, x402 settles — and the seam between them is now written down. The platforms that internalize the whole seam, in both directions, are the ones agents will actually transact through.