x402 gives an HTTP endpoint a price tag.
Normally, software that wants one paid API result must already have an account, a subscription, an API key, and billing set up. With x402, the server can answer the request itself with: “Payment required. Here is the price and how to pay.” The client signs a payment authorization, retries the same request, and receives the result with a settlement receipt.
Think of it as a vending machine built into an API.
GET /forecastAsk for the resource402 · $0.01Receive the pricePAYMENT-SIGNATUREAuthorize payment200 · JSONGet the resourceThe problem: software can ask, but paying is awkward
HTTP already gives software a common way to request almost anything on the web. Payments usually sit outside that request.
If an agent needs one map, one search result, or ten seconds of compute, the purchase can require much more machinery than the thing being purchased. The buyer may have to open an account, enter a card, choose a monthly plan, create an API key, store that secret, and later reconcile a bill.
Before: establish a billing relationship
- Create an account
- Add a payment method
- Choose a plan or prepay credits
- Copy and store an API key
- Finally make the request
With x402: buy the result
- Make the request
- Read the price
- Authorize the payment
- Receive the result and receipt
x402 is supposed to make a small, one-off purchase feel as native to software as following a link. It is especially useful for AI agents because the price, payment instructions, and receipt are all machine-readable. No human needs to stop the workflow to fill out a checkout form.
How x402 works
The name comes from HTTP status code 402 Payment Required. The code has existed for decades, but HTTP never defined a widely adopted payment flow around it. x402 supplies that flow.
The current x402 V2 exchange uses three payment headers:
The client asks
An agent, application, or person requests a protected API, file, or webpage normally.
GET /weather HTTP/1.1
Host: api.example.comThe server names its terms
The response identifies acceptable amounts, assets, networks, and recipients.
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <price and payment terms>The client signs and retries
The wallet creates a payment payload that matches one acceptable option. The original request is sent again.
GET /weather HTTP/1.1
PAYMENT-SIGNATURE: <signed payment payload>The server verifies and settles
The seller checks the authorization itself or asks a facilitator to verify it and submit the transfer to the selected payment network.
POST /verify
POST /settleThe server delivers
After settlement succeeds, the seller returns the requested resource and a machine-readable receipt.
HTTP/1.1 200 OK
PAYMENT-RESPONSE: <settlement receipt>{ "weather": "sunny", "temperature": 70 }
The headers are Base64-encoded in an actual V2 exchange; they are written as readable placeholders here to show the job of each message. The official x402 payment-flow documentation contains the full sequence, and the V2 migration guide documents the current header names.
Who does what?
Client
Requests the resource, checks the terms, and signs a payment authorization.
Resource server
Sets the price, enforces payment, and returns the paid result.
Facilitator
Optionally verifies the signed payload and handles settlement for the seller.
Payment network
Finalizes the transfer. Most deployed x402 flows use onchain assets such as stablecoins.
The facilitator is plumbing, not the merchant and not the buyer. It reduces the amount of blockchain-specific work the resource server must do. A seller can also verify and settle payments itself.
The protocol is open rather than Coinbase-only. Coinbase created x402 and contributed it to the x402 Foundation under the Linux Foundation. Anyone can implement the standard or operate a facilitator. V2 is designed to support different networks, assets, and payment schemes behind the same HTTP flow.
What x402 is supposed to solve
Pay per use
Sell one API call, one file, or one unit of compute instead of forcing a subscription.
Let software transact
Keep price discovery, authorization, and delivery inside a flow that an agent can complete.
Remove account friction
For a simple paid resource, avoid making every buyer create an account and manage another API key.
Give small services a checkout
Let a developer put a price on an existing HTTP route without building a full billing system first.
That does not mean the purchase is literally frictionless. The buyer still needs a funded wallet or compatible payment method, software that understands x402, and a policy governing what it is allowed to spend. The seller still needs to price the resource, choose supported payment schemes, and handle its legal and operational responsibilities. The x402 standard itself does not impose a protocol fee, though networks and service providers can have their own costs.
What x402 does not solve
x402 answers “How can this client pay this server for this response?” It does not answer every question around the purchase.
| It does not decide… | Why that still matters |
|---|---|
| Which service to choose | A payment protocol can execute a choice, but it cannot tell an agent which seller is reliable or which result is good. |
| Whether the price is worth it | The buyer still needs a budget, comparison logic, and a maximum-spend policy. |
| Whether returned content is safe | Paid API output is still untrusted input and can be wrong, malicious, or prompt-injecting. |
| How refunds and disputes work | Those depend on the seller, payment scheme, and applicable rules; a receipt is not a universal refund system. |
| Compliance, tax, or consumer protection | HTTP headers do not remove the obligations attached to selling and buying. |
This boundary is important. A successful x402 payment proves that money moved and a response was returned. It does not prove that the response was useful. Discovery extensions and marketplaces can help clients find services, but reputation and outcome evidence remain separate layers.
The shortest possible explanation
x402 turns “pay me, then retry” into a standard HTTP conversation.
The first request gets a price. The second carries a signed payment. A successful response carries the purchased resource and a receipt.
That is the whole mental model. Wallets, facilitators, networks, discovery, and policy make the model usable at scale, but they sit around that small exchange.
You can browse live offerings in Talkshi's x402 marketplace or compare paid API services in the broader Buy marketplace. Before an agent pays an unfamiliar seller, it should evaluate the provider and bound the spend. After it receives the result, it should record whether the service actually delivered. The distinction between payment evidence and outcome evidence is explored in The Barrier to Agent-to-Agent Payments Isn't Money. It's Trust..
For the first-hand version, read what it felt like to make 164 settled x402 API calls, including prices, latency, paid failures, a refund, and a settlement that arrived a day late.