A2A x402 extension: pay-per-call monetisation for AI agents

The emergence of machine-to-machine commerce

The A2A protocol specification established how agents advertise capabilities and exchange tasks across corporate boundaries. But as multi-agent ecosystems mature, a critical question emerges: how do service providers monetize high-value agents?

Consider a specialized legal audit agent or a protein-folding analysis model. The operator cannot offer unlimited free access to arbitrary calling agents across the Internet, nor can they ask an autonomous client agent to complete an interactive checkout form.

What autonomous systems need is programmatic, machine-readable payment:

• The calling agent learns the price before it commits to the work.
• The receiving agent states what it will accept: a network, an asset, an amount and an address.
• Payment is verified and settled before, or as, the work is delivered.

What is the x402 extension?

Two things share the name, and they are easy to mix up.

x402 is an open payment protocol, specified in the x402 repository, that revives HTTP 402 Payment Required. A server replies to an unpaid request with its payment requirements; the client signs a payment authorization and retries; a facilitator verifies the authorization and settles it on-chain. Over plain HTTP the requirements travel in a PAYMENT-REQUIRED response header and the signed payment in a PAYMENT-SIGNATURE request header.

The A2A x402 extension, developed in the google-agentic-commerce/a2a-x402 repository, is x402 carried over A2A. It uses the standard extension mechanism of the core a2aproject/A2A specification, so nothing in the Agent Card schema changed. Instead of HTTP headers it uses the task state and message metadata that A2A already has:

1. Declaration in the card: the agent lists the extension URI in capabilities.extensions.
2. Payment required: the agent returns a task in the input-required state whose message metadata carries the payment requirements.
3. Payment submitted and settled: the client replies with a signed payment payload, and the agent verifies it, settles it on-chain, and reports a receipt in metadata.

Declaring the extension in the Agent Card

The extension is declared the same way as any A2A extension: an entry in the extensions array of capabilities, identified by a URI.

{
  "name": "Market Intelligence Oracle",
  "description": "Performs fundamental analysis on listed equity tickers and returns a structured report.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://oracle.example.com/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "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
      }
    ]
  },
  "defaultInputModes": ["application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "deep-equity-scan",
      "name": "Deep Equity Scan",
      "description": "Performs fundamental analysis on listed equity tickers.",
      "tags": ["finance", "equity", "analytics"]
    }
  ]
}

The extension specification recommends required: true, which tells clients they must understand x402 to use the monetized skills.

The negotiation and settlement lifecycle

The standard interaction cycle between a client agent and an x402-enabled merchant agent follows these steps:

1. Discovery and activation: The client reads the card, sees the x402 extension, and activates it by listing its URI in the extensions header of each request (the extension's v0.1 text calls the header X-A2A-Extensions; A2A v1.0 registers it as A2A-Extensions).
2. Payment required: For a paid request, the agent creates a task in the input-required state. Its message carries x402.payment.status: "payment-required" and x402.payment.required, an object with an x402Version and an accepts list of payment options. The client may pick any one.
3. Payment submitted: The client signs one option and sends a message on the same task (taskId) with x402.payment.status: "payment-submitted" and the signed x402.payment.payload. Rejecting every option instead is reported as payment-rejected.
4. Verification, settlement and receipt: The agent verifies the payload (payment-verified), settles it on-chain through a facilitator, and returns the result with x402.payment.status: "payment-completed" and an x402.payment.receipts array. A failure ends in payment-failed with an x402.payment.error code.

{
  "x402.payment.status": "payment-required",
  "x402.payment.required": {
    "x402Version": 2,
    "resource": {
      "url": "https://oracle.example.com/a2a/v1",
      "description": "Deep equity scan"
    },
    "accepts": [
      {
        "scheme": "exact",
        "network": "eip155:8453",
        "amount": "48240000",
        "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913",
        "payTo": "0xServerWalletAddressHere",
        "maxTimeoutSeconds": 600,
        "extra": { "name": "USD Coin", "version": "2" }
      }
    ]
  }
}

The amount is in the token's smallest unit (USDC has six decimals, so the figure above is 48.24 USDC). Field names differ between x402 versions: the extension's own v0.1 text still shows the v1 form, with maxAmountRequired, while the x402 transport for A2A uses the v2 form shown here.

How to build and generate a monetized agent

Building a commercial AI agent on A2A requires getting the foundational metadata right. If the card is invalid, client agents cannot discover or negotiate with your service.

To assemble your card and agent:

1. Open our Agent Card generator to draft your baseline endpoints, skills, and authentication schemes, and switch on x402. It adds the extension declaration shown above.
2. Validate the result with our Agent Card validator, which checks that capabilities.extensions entries are well formed.
3. Deploy the card at /.well-known/agent-card.json on your domain.
4. Implement the payment states in your agent. The a2a-x402 repository includes a Python implementation (x402_a2a) that wraps an A2A executor, and you will need a facilitator to verify and settle payments. Try the whole flow on a test network before you accept real funds.