How to Set Up AP2 x402 Stablecoin Payments (2026)

Agents can already talk to each other over A2A. The hard part is letting one agent pay another in USDC without handing an LLM a private key or an open-ended spending right.

That's the job of AP2 x402 stablecoin payments: Google's Agent Payments Protocol (AP2) supplies signed mandates that prove what the user authorized, and the A2A x402 extension carries the on-chain USDC payment between agents. This guide walks the setup in six steps, runs a worked budget example, and ends with Stablecoin Insider's take on when the stack is ready for production.

Key Takeaways

• AP2 proves user intent with signed mandates; x402 moves the USDC.
• The A2A x402 extension uses task metadata, not an HTTP 402 response.
• Merchants declare the extension in the AgentCard and require activation.
• Open Payment Mandates cap autonomous spend with amount, budget, and recurrence rules.
• Google's x402 samples are demos; the AP2-native x402 extension is still pending.

Facts here come from the public docs as of October 6, 2026: the AP2 documentation, the Payment Mandate spec, the AP2 flows page, the A2A x402 extension spec v0.1, and Google's Human Not Present x402 sample. The main competitor page for this keyword is Coinbase's AP2 + x402 launch note, which explains the why but not the setup.

What AP2 x402 stablecoin payments actually are

Google announced AP2 on September 16, 2025 as an open protocol that can run as an extension of A2A and MCP, built with more than 60 organizations including Coinbase, Mastercard, PayPal, and Revolut. The announcement says AP2 supports cards, real-time bank transfers, and stablecoins.

Two separate specs do the work. AP2 defines mandates: tamper-evident, cryptographically signed credentials that record what the user approved. The a2a-x402 extension defines how a merchant agent asks for an on-chain payment and how a client agent pays it inside an A2A task.

Coinbase calls x402 one of the first extensions to AP2 and the only stablecoin facilitator at launch. Be precise about status, though. The AP2 FAQ says the a2a-x402 repo will be aligned with AP2 over time, and the Human Present x402 sample says the AP2-compatible x402 extension is coming soon.

So today you compose two layers yourself. That's what the steps below do.

The roles you need to wire up

AP2 names four agent roles in its flows, and the x402 extension maps onto them cleanly. Here's the mapping Stablecoin Insider uses:

The Human Not Present x402 sample runs exactly this cast: a Shopping Agent, a Merchant Agent, an x402 Merchant Payment Processor, and an x402 Credentials Provider.

Step 1: Declare the x402 extension in the AgentCard

A merchant agent that charges in USDC must list the extension URI in the extensions array of its AgentCard. The spec recommends required: true, so clients that don't speak x402 get rejected instead of half-served.

{
  "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
      }
    ]
  }
}

Clients activate it per request with the header X-A2A-Extensions set to the same URI. The server must echo that URI back to confirm activation, per section 7 of the extension spec.

Step 2: Return a payment-required task with USDC terms

When a request needs payment, the merchant agent returns a Task in state input-required. The message metadata carries x402.payment.status set to payment-required and an x402.payment.required object listing accepted payment options. This is the key difference from HTTP x402: no 402 status code, just A2A task metadata.

"metadata": {
  "x402.payment.status": "payment-required",
  "x402.payment.required": {
    "x402Version": 1,
    "accepts": [{
      "scheme": "exact",
      "network": "base",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bda02913",
      "payTo": "0xServerWalletAddressHere",
      "maxAmountRequired": "48240000",
      "maxTimeoutSeconds": 600,
      "description": "Generate an image",
      "extra": { "name": "USD Coin", "version": 2 }
    }]
  }
}

The asset is native USDC on Base; check it against Circle's USDC contract address list rather than copying it. maxAmountRequired is in the token's smallest unit, and USDC uses 6 decimals (Turnkey's agentic payments docs annotate 1 USDC that way), so 48240000 means 48.24 USDC.

Need help choosing the price itself? See How to Price an x402 API in USDC.

Step 3: Capture user authority with AP2 mandates

This is the AP2 half. In a human-present flow, the user approves closed Checkout and Payment Mandates on a trusted surface, often with a biometric. In a human-not-present flow, the user signs open mandates up front and the agent later signs closed mandates within those limits, per the AP2 flows.

The Payment Mandate spec defines the constraints an open mandate can carry:

• payment.amount_range: min and max per payment, in minor units of an ISO 4217 currency.
• payment.budget: a total spend cap, used together with recurrence.
• payment.agent_recurrence: frequency (ON_DEMAND, DAILY, WEEKLY, MONTHLY and others) plus max_occurrences.
• payment.allowed_payees: the merchants the agent may pay.
• payment.allowed_payment_instruments: the instruments the agent may use.
• payment.execution_date and payment.reference: a date window and a binding to one open Checkout Mandate.

Two binding rules matter for agents. The open mandate includes the agent's public key as a confirmation claim, so only that agent can use it. And the flows page says the agent must not create overlapping mandates until it gets a receipt, which prevents double spend.

Step 4: Sign the PaymentPayload and submit it with the taskId

Once the mandate check passes, the client agent picks one entry from accepts and has a wallet or signing service sign it into a PaymentPayload. The spec is blunt: private keys must never be handled directly by any LLM operating an agent.

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "taskId": "task-123",
      "role": "user",
      "parts": [{ "kind": "text", "text": "Here is the payment authorization." }],
      "metadata": {
        "x402.payment.status": "payment-submitted",
        "x402.payment.payload": { "x402Version": 1, "network": "base", "scheme": "exact", "payload": {} }
      }
    }
  }
}

The taskId is mandatory. The merchant uses it to look up the original requirements and confirm the signed payload matches them. If the terms don't fit the mandate, the client replies with payment-rejected instead.

For wallet options that keep keys off the model, see Turnkey agentic USDC payments and Dfns x402 agent payments.

Step 5: Verify, settle, and return the receipt

The merchant sends the payload to a facilitator to verify the signature, then settles on-chain. Status moves from payment-submitted to payment-verified to payment-completed, and every settlement attempt is appended to x402.payment.receipts, never replaced, per the state rules. The spec also says the merchant should finish the work before settling.

These codes come from section 8.1 of the a2a-x402 spec. Choosing who settles is its own decision; see How to Choose an x402 Facilitator for USDC and Circle's x402 facilitator setup.

Step 6: Run Google's x402 samples before you write your own

Google's Human Not Present x402 scenario starts every service with one script and needs a Google API key from AI Studio. It triggers an autonomous purchase from a mock price drop.

export GOOGLE_API_KEY=your_key
bash code/samples/python/scenarios/a2a/human-not-present/x402/run.sh

# separate terminal: simulate the trigger
curl -X POST "http://localhost:8081/trigger-price-drop?item_id=<item_id>&price=<price>&stock=10"

The script serves the agent on port 8080, the merchant trigger on 8081, the x402 PSP trigger on 8084, and the web client on 5173. An optional broadcast flag simulates on-chain broadcast, per the sample README. For a human-present run, the Human Present x402 sample uses the cards scenario script with the x402 payment method and skips the OTP challenge.

Treat these as protocol demos. The FAQ says the samples mock payment service providers. Before real USDC moves, follow How to Test an AI Agent USDC Payment Before Going Live.

Stablecoin Insider's worked example: one mandate, five payments

This is an illustrative setup Stablecoin Insider built from the spec fields, not a vendor quote. A user lets a research agent buy image generations from a merchant agent that charges the spec example price of 48.24 USDC each. The user signs an open Payment Mandate with three constraints:

[
  { "type": "payment.amount_range", "currency": "USD", "max": 6000 },
  { "type": "payment.budget", "currency": "USD", "max": 200.00 },
  { "type": "payment.agent_recurrence", "frequency": "ON_DEMAND", "max_occurrences": 10 }
]

Field names and units follow the Payment Mandate spec: amount_range uses minor units, so 6000 caps each payment at $60.00, and budget sets a $200.00 total.

The fifth call breaks the $200.00 budget even though it passes the per-payment cap. The AP2 flows page covers this case: the merchant or credential provider returns an unresolved_constraint error and brings the user back to approve closed mandates, turning a human-not-present flow into a human-present one.

That's the behavior you want. The agent keeps working until the user's own rule stops it.

AP2 x402 vs plain HTTP x402

Other agent payment rails solve adjacent problems: Stripe MPP in USDC, Catena ACK-Pay, and the Coinbase AgentKit x402 client. For the market map, read stablecoin payments for AI agents.

Where AP2 x402 setups break

• Unit drift. Comparing USD-cent mandate limits to USDC base units without a conversion.
• Missing taskId. The merchant can't match the payload to its original requirements.
• Keys in the prompt path. The spec forbids LLMs from handling private keys.
• Overlapping mandates. Creating a second open mandate before a receipt invites double spend.
• Treating samples as production. The samples mock providers, and the AP2-native x402 extension isn't out.

Pair this with wallet spend limits, agent verification, Know Your Agent checks, and USDC spend reconciliation.

Building an AP2 x402 stablecoin payment flow? Start with one merchant agent, one open mandate with a small budget, and one settled receipt on testnet before you raise limits.

How to Accept x402 USDC Payments from AI Agents

Stablecoin Insider's HTTP x402 setup guide for charging AI agents in USDC.

Stablecoin Insider

FAQ

This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell.