How AI agents pay onchain x402: the 402 retry loop that clears stablecoins

AI agents pay onchain with x402 by treating an HTTP 402 response as a price quote, signing a stablecoin authorization, and retrying the same request with proof of payment. A facilitator verifies the signature, blocks replays, submits settlement onchain, and the server releases the resource once confirmation matches the service’s finality SLA.

Key Takeaways

• x402 embeds payment into the normal HTTP request cycle: a 402 response carries structured terms, and the client retries with a signed payment proof.
• The core roles are the client (agent/app), the resource server (API), and a facilitator that verifies signatures, prevents replay, and handles onchain settlement.
• Most agent payments use stablecoin settlement, typically USDC, because finality time is the user experience for per-request commerce.
• x402 is signature-first: USDC/EURC commonly use EIP-3009 authorizations, while other ERC-20s use Permit2, so the agent does not broadcast raw transactions per call.

Why AI agents need x402 payments

Autonomous software breaks the assumptions baked into classic API monetization. API keys, OAuth flows, subscriptions, and invoicing all presume a human can create an account, store credentials, rotate secrets, and resolve billing failures. An agent that is supposed to run unattended cannot stop to open a dashboard, add a card, or negotiate a contract. That mismatch is the economic bottleneck behind a lot of “agent payments crypto” talk.

x402 attacks the problem at the protocol seam the web already reserved for it: http 402. HTTP 402 “Payment Required” has existed since the early 1990s, but it shipped without a standard way to express price, accepted assets, and where to pay. x402 fills that gap by making the paywall machine-readable and making payment a deterministic retry pattern rather than a separate checkout flow.

This is why x402 shows up in the agent economy explained conversation. It turns “how do AI agents pay” from a product integration problem into a request-response primitive. The 402 is the quote, the signed authorization is the order, and the facilitator is the clearing broker that makes settlement someone else’s operational problem.

The thesis matters for builders: the SLA being sold is not “blockchain payments.” It is predictable fulfillment latency. If the endpoint is interactive, the chain’s confirmation time becomes part of the product spec, not an implementation detail.

The x402 request and payment loop

The mechanism is a tight loop that looks like a trading venue handshake more than a checkout page. The resource server does not ask the client to go elsewhere to pay. It refuses the request with structured terms, then expects a retry that proves payment intent.

The basic x402 loop runs like this:

1. Client requests a paid resource. The AI agent or app sends a normal HTTP request to an API endpoint. 2. Resource server returns http 402 with terms. The response includes structured payment instructions: price, accepted tokens, recipient address, and the network to settle on. 3. Client constructs a payment proof. The agent reads the terms and prepares a signed payload that authorizes token movement for that exact amount and destination. 4. Client retries the same request with a payment header. The retry attaches the signed authorization as proof, turning payment into a standard HTTP retry rather than a separate flow. 5. Server verifies and settles, then returns 200 OK. Verification is often delegated to a facilitator, which confirms the signature and submits settlement onchain before the server releases the resource.

Two details are where most “x402 payments explained” posts get fuzzy.

First, the retry pattern is the product. It makes payment idempotent-friendly and automatable, because the client can treat “402 then retry” as a deterministic state machine.

Second, the 402 terms are not a static credential. They are per-request payment instructions. That difference is why x402 is not “just a new API key,” even if the developer ergonomics can feel similar once middleware is in place.

Facilitators and signature-based settlement

The facilitator is the operational unlock, not a convenience layer. Eco’s flow defines three roles, and the facilitator is the one that absorbs the messy parts: signature verification, balance checks, replay protection, onchain submission, and confirmation back to the resource server.

This is also where x402’s core design choice shows up on-screen: signature-first token movement. For USDC and EURC, x402 commonly uses EIP-3009-style transfer authorizations, where the agent signs an intent and another party submits it onchain. For other ERC-20s, the flow uses Permit2. Either way, the agent is not crafting and broadcasting a raw transaction per request. It is producing a signed authorization that can be settled by the facilitator.

That matters for “machine payments” because it changes what the client must hold and what the server must run. The client needs a wallet capable of signing the authorization payload. The server does not need to run nodes or manage chain-specific transaction plumbing if it can call a facilitator.

It also reframes risk like microstructure. The facilitator is acting like a clearing broker, so builders should think about:

1. Replay and idempotency. The client will retry after a 402, networks can be slow, and the facilitator must reject replays. Server handlers need a “paid state” that can be checked safely before serving. 2. Latency and finality. The facilitator can respond quickly, but the real SLA is chain confirmation. If the service promises “seconds,” it is implicitly choosing rails where finality fits. 3. Trust boundaries. Public facilitators reduce integration friction, but they also become a dependency for verification and submission.

Eco notes public facilitators from Coinbase (via CDP) are available at no cost on Base and Solana, and it also mentions Stellar support with an OpenZeppelin relayer. That is a fast path to shipping, but it is still a clearing dependency that needs explicit failure-mode thinking.

Chains, tokens, and performance tradeoffs

Finality time is the user experience for per-request commerce, which is why x402 deployments cluster on fast rails. Eco lists x402 as live on Base, Solana, Stellar, Arbitrum, Polygon, and Ethereum mainnet, and notes Base and Solana are commonly used due to low fees and fast finality.

Eco also provides indicative finality times that map cleanly to product expectations: Solana at ~400ms, Base at ~2 seconds, Stellar at ~5 seconds, and Ethereum L1 at ~12 seconds. Those numbers are not trivia. They define whether an agentic payment feels like an API call or like a checkout.

Stablecoin settlement is the other half of the performance story. Eco describes stablecoins, primarily USDC, as the dominant settlement token across x402. That is less about ideology and more about keeping the payment leg from adding price risk to an automated workflow. If an agent is paying per request, volatility turns a metered bill into a moving target.

Chain support also needs careful language. Eco’s “live” list and Alchemy’s x402 V2 “supports” list are not identical. Alchemy says x402 V2 shipped in December 2025 with multi-chain support and names Base, Solana, Ethereum, Polygon, Starknet, and Injective. Eco’s list includes Arbitrum and Stellar. The clean way to read this is that the spec can be multi-chain, but what is usable today depends on which networks a given facilitator actually clears and what tokens it can settle.

For high-frequency workloads, Alchemy’s point about x402 V2 sessions is the key performance lever. Wallet-based sessions reduce per-request onchain settlement overhead, shifting the experience from “pay-per-call” toward “streaming access” where settlement can be amortized.

Real-world uses and ecosystem standards

x402’s sweet spot is machine to machine payment where the buyer is software and the seller is an HTTP resource. Eco lists active use cases that match what shows up in production: pay-per-request API access, machine-to-machine micropayments for data or compute, content paywalls, MCP tool monetization, and data marketplace access.

The important part is not the category list. It is the pricing granularity. Per-request settlement lets an agent compare providers dynamically, route based on price or latency, and pay without pre-provisioned keys. That is the economic behavior people mean when they say agentic payment.

Ecosystem positioning is where confusion is expensive. Eco distinguishes x402 from Google’s A2A and AP2 and treats them as complementary layers: A2A for agent communication and discovery, AP2 for authorization and governance, and x402 for execution and settlement. The mistake is treating x402 as a competitor to A2A or AP2. They solve different legs of the workflow.

Timeline-wise, Eco and Alchemy both place x402’s launch in May 2025. Allium reports the x402 whitepaper release date as May 6, 2025, authored by Coinbase Developer Platform. Foundation governance timing is less clean: Eco says Coinbase and Cloudflare launched the x402 Foundation in 2025, while Alchemy says Coinbase contributed the protocol to the Linux Foundation and the x402 Foundation launched in April 2026 with 20+ founding members. Builders should treat that as an open governance detail, not a blocker for understanding the payment loop.

Practical setup and key caveats

Integration is “lightweight” only if the retry loop is treated as a state machine and not as a one-off hack. Eco describes a typical server-side path as middleware that intercepts unpaid requests, returns 402 with terms, and verifies payment on retry, often by calling a facilitator.

A pragmatic build checklist looks like this:

1. Define the payment terms schema you will emit on 402. Price, accepted token(s), recipient address, and network must be unambiguous. 2. Decide who clears settlement. Using a public facilitator can remove node ops and chain plumbing, but it adds a dependency that should be monitored like any other payment processor. 3. Implement idempotency around “paid.” The client will retry after a 402, and the server must be able to re-check payment status safely before serving. 4. Pick rails that match the endpoint’s latency budget. Eco’s indicative finality times make it obvious why Base and Solana dominate interactive flows. 5. Plan for sessions if the workload is high-frequency. Alchemy’s x402 V2 wallet-based sessions exist because per-request onchain settlement does not scale cleanly for streaming access patterns.

Key caveats are mostly about expectations. Alchemy claims x402 has processed over 100 million payments since May 2025, but that figure is not corroborated by the other provided sources. Chain support also varies by facilitator, so “supported by spec” and “live with a public facilitator” are different statements.

The broader agent economy explained arc is heading toward API commerce that looks like order flow. x402 is the piece that turns payment into a deterministic retry, with the facilitator acting as the clearing layer and chain finality acting as the SLA.

The Take

I’ve watched teams treat x402 like a credential swap, then get surprised when the first production incident is not “signature verification.” It’s idempotency. The client retries after a 402, the facilitator is doing replay checks, and the server still needs a clean paid-state check so it does not double-serve or double-charge when latency spikes.

The mental model that holds up is microstructure: the 402 is the quote, the signed authorization is the order, and the facilitator is the clearing broker. Once that clicks, chain finality stops being a crypto detail and becomes the SLA the endpoint is selling. That is why stablecoin settlement on fast-finality rails like Solana (~400ms) or Base (~2s) keeps showing up in agentic payment designs, while slower confirmation paths force teams back into offchain credit anyway.

Sources

• Eco
• Alchemy
• Allium