When AI agents started paying for things on their own, two half-solutions appeared at once. One protocol knew what a user had authorized but had no way to move money on a blockchain. Another protocol could settle stablecoins over HTTP in seconds but had no standard proof of who approved the purchase and under what limits. The AP2 x402 extension is the piece that welds those two halves together. I've spent the last few months building against both, and this guide walks through exactly how the extension connects authorization to on-chain settlement, and how you'd wire it up yourself.
What the AP2 x402 Extension Is
The A2A x402 extension is a formal add-on to the Agent Payments Protocol (AP2), itself an extension of the Agent2Agent (A2A) protocol used for agent-to-agent messaging. Its whole job is to let an agent that already holds a signed mandate pay a merchant agent with an on-chain stablecoin instead of a card rail.
The extension reached v0.2.0 in April 2026 and was built as an open collaboration — the AP2 maintainers worked alongside contributors from Coinbase, the Ethereum Foundation, and MetaMask. That mix matters: Coinbase brought the x402 settlement scheme, the Ethereum Foundation brought account-abstraction and signing expertise, and MetaMask brought wallet-side authorization. The result is a payment method that plugs into AP2's existing mandate model rather than replacing it.
Think of it as one specific payment-method option inside AP2. Card networks are another option; this one says "settle in stablecoins over x402." Nothing about the intent, cart, or user-consent machinery changes — only the rail underneath does.
AP2 Mandates: The Authorization Layer
AP2's core idea is the mandate: a cryptographically signed, verifiable record of what a human actually authorized. There are two you need to know.
- Intent Mandate — captures the user's goal and constraints before anything is chosen. Example: "book a flight to Lisbon under $400, USDC only." It's the guardrail.
- Cart Mandate — captures the exact, finalized order: specific items, the precise amount, the payee. The user (or their agent, within the intent's limits) signs this to approve the concrete purchase.
Both are signed objects tied to the user's key, so a merchant can later prove the buyer agreed to this cart at this price. Crucially, mandates are rail-agnostic — they say nothing about how money moves. That gap is exactly what the x402 extension fills. Without the extension, a Cart Mandate is a signed promise with no settlement mechanism on-chain.
x402: The On-Chain Settlement Layer
x402 revives the long-dormant HTTP 402 Payment Required status code and turns it into a real payment handshake. The flow is simple:
- The client requests a resource.
- The server replies
402 with a list of payment requirements (accepts).
- The client resends the request carrying a signed payment payload in an
X-PAYMENT header.
- A facilitator verifies the payload and settles it on-chain, then the server returns the resource.
A typical 402 body looks like this:
{
"x402Version": 1,
"accepts": [{
"scheme": "exact",
"network": "base",
"asset": "0x833589...2913", // USDC on Base
"maxAmountRequired": "1500000", // 1.5 USDC (6 decimals)
"payTo": "0xMerchantAgentAddress",
"resource": "/api/flight-booking"
}]
}
The exact scheme is the workhorse: it uses EIP-3009 transferWithAuthorization, which lets a wallet sign a stablecoin transfer that the facilitator (not the user) broadcasts and pays gas for. The user needs only USDC — no native gas token. This is why x402 feels instant and why it's a natural fit for autonomous agents making many small payments.
How the Extension Wires Mandates to Payments
Here's the conceptual join. AP2 answers "is this purchase authorized, and for how much?" x402 answers "how do I actually move the funds on-chain?" The extension makes the signed Cart Mandate the source of truth that the x402 payload must match.
User authorizes Merchant demands Facilitator
┌──────────────┐ Cart Mandate ┌──────────────┐ 402 + accepts ┌────────────┐
│ Intent Mandate│ ───────────▶ │ Merchant │ ─────────────▶ │ Verifies │
│ (limits) │ │ Agent │ │ + settles │
└──────┬───────┘ └──────┬───────┘ X-PAYMENT │ on-chain │
│ signs cart │ ◀─────────────────── └────────────┘
▼ ▼
Cart Mandate ──────────────▶ amount/payee must equal
(item, $, payee) the signed cart
The extension defines the A2A message parts that carry x402 data. A merchant agent advertises support via an extension URI in its A2A AgentCard, and payment requirements ride inside the A2A task as structured parts rather than a bare HTTP header. The buyer's agent then attaches the signed payment payload back onto the same A2A task — so the entire negotiation stays inside one auditable agent-to-agent conversation, with the mandate and the settlement bound together.
The Payment Flow, Step by Step
Putting AP2 and x402 together, a full ap2 crypto payments round trip looks like this:
- Intent — The user's agent holds an Intent Mandate: "buy this dataset, up to 5 USDC on Base."
- Discovery — The merchant agent's AgentCard declares the x402 extension and a USDC-on-Base payment method.
- Cart — The merchant returns a concrete cart (2.5 USDC, payee address). The user's agent checks it against the Intent Mandate's limits and produces a signed Cart Mandate.
- Payment requirements — The merchant sends x402
accepts inside the A2A task.
- Signed payload — The agent's wallet signs an EIP-3009 authorization for exactly the cart amount and payee, and returns it as the x402 payment part.
- Verify & settle — The facilitator verifies the signature and that the payload matches the Cart Mandate, then settles USDC on-chain.
- Fulfillment — On confirmation, the merchant releases the resource and both sides retain the mandate plus the settlement tx hash as a tamper-evident receipt.
The security win is that steps 3 and 5 are cross-checked: the on-chain transfer cannot exceed what the user signed in the cart, and the cart cannot exceed the intent's ceiling.
Choosing a Stablecoin and Network
In practice v0.2.0 traffic is dominated by USDC on Base — low fees, fast finality, and EIP-3009 support out of the box. The extension itself is network- and asset-neutral: the accepts array can list multiple options (different chains or stablecoins), and the buyer's agent picks whichever satisfies its Intent Mandate. If your users constrain payments to a specific asset in the intent, the agent simply skips any accepts entry that doesn't match. My honest take: start with a single USDC-on-Base path, get the mandate-to-payload matching solid, then add chains only when you have a real reason to.
Using It as a Developer
To build a merchant agent that accepts these payments, you'll:
- Add the x402 extension URI to your A2A
AgentCard so buyers know you support it.
- Return a Cart Mandate request, then x402
accepts describing your USDC payee, network, and amount.
- Run or point at a facilitator for verification and settlement (Coinbase publishes a hosted one; you can self-host).
- On settlement, verify the tx and check that the settled amount and payee equal the signed Cart Mandate before releasing goods.
On the buyer side, your agent needs a wallet capable of EIP-3009 signing (MetaMask's agent tooling and other smart-EOA wallets handle this) and logic that refuses to sign any payload exceeding the active Intent Mandate. Keep the mandate check in your own code — never delegate the spending ceiling entirely to the counterparty.
Frequently Asked Questions
Is the AP2 x402 extension a separate protocol from AP2?
No. It's an extension to AP2 (which itself extends A2A). It adds one crypto-native payment method — stablecoins settled via x402 — without changing how mandates, intents, or carts work.
Do I need a gas token to pay?
Not with the exact scheme. EIP-3009 transferWithAuthorization lets the facilitator broadcast and pay gas; the agent's wallet only needs the stablecoin itself.
Which stablecoin and chain should I use?
As of the v0.2.0 (April 2026) release, USDC on Base is the common default. The extension supports multiple assets and networks via the accepts array, so you can offer alternatives, but a single USDC-on-Base path is the simplest reliable start.
How does it stop an agent from overspending?
Two nested checks: the Cart Mandate must fall within the user's signed Intent Mandate limits, and the on-chain payload must exactly match the Cart Mandate. A payload for more than the signed cart is rejected before settlement.
Conclusion
The AP2 x402 extension is deliberately narrow, and that's its strength. AP2 already had a rigorous way to prove what a user authorized; x402 already had a fast way to settle stablecoins over HTTP. Version 0.2.0, shipped in April 2026 with Coinbase, the Ethereum Foundation, and MetaMask, is the connective tissue that binds a signed Cart Mandate to an on-chain USDC transfer so neither can drift from the other. For developers, the practical path is straightforward: advertise the extension, keep your mandate checks in your own code, settle through a facilitator, and verify the tx against the signed cart before you hand anything over. It's early, the surface will keep changing, and you should treat spend limits as sacred — but the core pattern of intent, cart, and matching on-chain settlement is a genuinely sound foundation for agent payments.
