The x402 Protocol: Paying for a Service Inside the Request

x402 lets software pay for something at the moment it asks for it. Instead of an account, an API key and a monthly subscription, the server answers an unpaid request with HTTP status code 402, "Payment Required," attaches the price and where to send it, and serves the resource once the client has paid and retried. This is an emerging pattern rather than established infrastructure, and the page is careful about the difference.

This page covers Arc in its first weeks of mainnet. Where something is still settling we say so rather than guess, and we revise the page as the ecosystem fills in. Last reviewed: September 2026.

What is x402?

x402 is an open protocol that uses the HTTP 402 status code to let a client pay for a web resource inline, in a single request-retry cycle, using a stablecoin transfer rather than a stored card or an existing account. Coinbase introduced it in May 2025 and published it under the Apache License 2.0. Version 2 of the specification followed in December 2025, adding a chain-agnostic way of naming networks and assets and support for conventional payment rails alongside stablecoins.

It is no longer a single company's project. The Linux Foundation announced in April 2026 that it would host an x402 Foundation under neutral governance, and confirmed that foundation's operational launch on July 14, 2026 with around forty members — among them Circle, Visa, Mastercard, Google, Amazon Web Services, Cloudflare, Stripe, Shopify and the Solana Foundation. That is a real standards-body home, and it is months old rather than years.

What is interesting is not the payment but the absence of the account. Every commercial API assumes a prior relationship: someone signed up, entered a card, provisioned a key. x402 makes the request itself carry the money, which lets software buy from a service it has never met.

Why has HTTP 402 sat unused for thirty years?

Status code 402 has been in the HTTP specification since the 1990s, marked "reserved for future use," and almost no server returned it, because the payment method it implied did not exist: the web had no way to move a small sum between two parties with no account relationship, cheaply and quickly enough to do inside a request.

Every attempt ran into the same arithmetic. Card networks charge a fixed component per transaction, typically twenty to thirty cents plus a percentage, making a one-cent API call impossible; bank transfers settle in days. So the industry standardised on the workaround we all use — subscriptions, prepaid credits and API keys — amortising an expensive payment over many cheap requests.

How does the flow actually work?

Four steps. The client requests a resource with no payment attached. The server replies 402 with a machine-readable description of what it wants: amount, asset, network, destination and any deadline. The client constructs and signs the payment, then repeats the original request with it in a header. The server, usually via a facilitator that verifies and settles the transfer, confirms the money is good and returns 200 with the resource.

The property that makes this workable is that the second request is the same request: no redirect, no checkout page, no session, no callback. To the calling code it is one function that occasionally costs money.

The mechanics are specified rather than improvised. Under version 2 the server's refusal carries a PAYMENT-REQUIRED header and a JSON body with an x402Version field set to 2 and an accepts array, each entry stating a scheme, a network named in the chain-agnostic CAIP-2 format, an amount, an asset, a destination and a timeout. The client retries with its signed payload in a PAYMENT-SIGNATURE header, and the server returns settlement details in a PAYMENT-RESPONSE header. A facilitator is an HTTP service the resource server calls, not a party holding anyone's money: it exposes POST /verify to check an authorisation without executing it, POST /settle to broadcast the verified payment, and GET /supported to advertise what it handles. The main scheme, exact, uses EIP-3009 transfer-with-authorization on EVM chains: the payer signs an instruction someone else executes rather than submitting a blockchain transaction, a relative of the sponsored-transaction patterns in gasless UX.

Why do stablecoins and cheap settlement make this possible now?

Because the economics only work when moving the money costs far less than the thing bought. A stablecoin is a token designed to hold a fixed value, most commonly one US dollar, and moving one is a transfer on a blockchain — a shared ledger maintained by many independent computers — not a message through the card networks. Where a transfer costs a fraction of a cent and settles in under a second, a one-cent payment becomes sensible.

That threshold is the whole story. At thirty cents of fixed cost, per-request pricing is absurd and subscriptions win; at a fraction of a cent, per-request pricing becomes the natural unit and a service can charge for exactly what it delivers. Arc settles at a fraction of a cent with sub-second finality, which is the order of magnitude the pattern needs; the precise figure moves and is not the point.

Two consequences are less comfortable. Transfers are irreversible, so there is no chargeback if the service returns garbage. And the payer is identified by an address, not a name — a feature for permissionless access, a problem for anyone with a compliance obligation.

What does this mean for AI agents?

An autonomous agent is what makes x402 more than a curiosity. Agents fail at the account layer: they cannot sign up for a service, accept its terms, enter a card and retrieve an API key without a human. x402 removes that step. Given a wallet — software holding the key that controls an address — and a budget, an agent can pay for a data lookup or a single inference call at the moment it needs one, from a provider chosen at runtime.

Adoption is real but young. Amazon Web Services shipped x402 enforcement in CloudFront and AWS WAF in mid-2026 and Cloudflare announced an equivalent gateway at its edge weeks later, both letting a server demand payment before a request reaches its origin. The protocol's developers said x402 had processed more than 100 million payments in its first six months to December 2025, a figure reported by The Block. But the x402 documentation's own supported-network list remains short — Base and Solana, plus their testnets — so the protocol is broadly governed and narrowly deployed.

Read the promise with its qualifications intact. Spend limits and authorisation of what an agent may buy are the operator's problem, not the protocol's. An agent that can spend money is one an attacker would like to influence, which makes prompt injection a financial risk, and there is no dispute mechanism: if the paid response is wrong, the money is gone.

How does this connect to Arc?

Arc is a Layer-1 blockchain built by Circle, the issuer of USDC, live since September 16, 2026 and designed around stablecoin settlement: gas — the fee every blockchain charges to process a transaction — is paid in USDC, transactions finalise in under a second, and fees are a fraction of a cent. Those are the properties inline machine payments require, which is why Arc comes up in agentic-commerce discussions.

Being honest about where that stands matters more than claiming it. Circle publishes a developer walkthrough for monetising an API with x402 that runs on Arc testnet against a Circle-hosted testnet facilitator, and Circle's stated 2026 product direction is to deepen the integration between its Gateway product, Arc and x402 — groundwork, not a finished mainnet service. The x402 project's supported-network list does not include Arc. The accurate statement in Arc's first weeks of mainnet: the testnet path is documented, production x402 settlement on Arc is not yet established, and Circle's developer documentation is where to check whether that has changed.

What can be said plainly is that a dollar-denominated payment protocol runs more simply where the fee is also a dollar — one asset, not two, which is the point of gas fees on Arc and sending USDC.

Frequently asked questions

Is x402 a blockchain, a token or a company?

None of those. It is a specification for how an HTTP server asks for payment and how a client supplies it, published under the Apache License 2.0 and maintained under the Linux Foundation's x402 Foundation since 2026. It has no token, and any asset marketed as an "x402 token" deserves extreme scepticism.

Do I need x402 to accept crypto payments on my API?

No. You can accept stablecoin payments today with an invoice, an address and a manual check. x402 matters when payment must happen inside the request, priced per call, for clients you never onboarded.

Is this the same as micropayments people tried in the 2000s?

The idea is the same; what changed is the reason it failed. Earlier attempts needed a network that could move a cent for less than a cent, and none existed. Whether this attempt succeeds now depends on adoption, not on the mechanism.

What stops an agent from spending everything?

Nothing in the protocol. Spend limits, per-call caps, allowlisted providers and a wallet funded with only what you can afford to lose are the operator's responsibility. Treat an agent's wallet like a corporate card with a low limit.