What x402 Actually Is, and How the HTTP 402 Flow Works
x402 revives the reserved HTTP 402 Payment Required status as a machine-readable payment challenge. A client requests a resource, the server responds 402 with the price and how to pay, the client settles the payment, and retries the request with proof. It makes paying part of the request itself rather than a separate signup flow.
The status code that was reserved and never used
HTTP 402 Payment Required has been in the specification since the early web, marked reserved for future use. It sat unused because the missing piece was never the status code. It was that no payment method could settle small amounts between two programs quickly enough, cheaply enough, and without a human completing a checkout.
Card rails were built around human buyers, account creation, and chargeback windows. Minimum viable transaction costs made a fraction of a cent economically impossible. So the web standardized on the alternatives we all know: sign up, get an API key, receive an invoice monthly, and have a human approve the spend.
That model works for organizations buying software. It fails completely for a program that discovers a resource at runtime, needs it once, and has no relationship with the provider. There is no path from "I need this data" to "I have this data" that does not involve a person filling in a form.
x402 is the attempt to close that gap by making the payment part of the HTTP exchange itself.
The request flow, step by step
1. The client requests the resource. An ordinary request to an ordinary URL, with no credentials.
2. The server responds 402 with payment requirements. This is the important part. The response carries structured, machine-readable terms: what the resource costs, in what asset, on what network, and where to send settlement. A human never reads this, which is exactly the point.
3. The client settles. It evaluates the price against whatever policy it has been given, and if acceptable, executes the payment.
4. The client retries with proof. The same request, now carrying evidence of payment. The server verifies and returns the resource.
What makes this different from an API key is that no relationship exists before the request and none needs to persist after it. The buyer does not sign up. The seller does not provision anything. The transaction is the relationship, which is the property that makes machine-to-machine commerce practical at volumes where account management would dominate the cost.
Why the challenge has to be structured
A pricing page is machine-readable in the sense that a model can read it and often guess wrong. A 402 response with typed fields for amount, asset, network, and destination is machine-readable in the sense that a client can act on it without interpretation. That difference between parsing and guessing is what makes automated payment safe enough to run unattended.
The parts that are genuinely hard
The status code is trivial. Everything around it is where implementations get stuck.
Settlement speed and cost. The payment has to clear fast enough that the retry is not absurd, and cost little enough that a small purchase makes sense. This is why these systems settle on chains with fast finality and low fees rather than on general purpose rails.
Proof verification. The server has to confirm payment before serving, without a round trip that costs more than the sale. Verification design decides whether the pattern is usable at high request rates.
Idempotency. The client pays, then retries. If the retry fails or times out, does it pay again? Every implementation needs a way to bind a payment to a specific request so that a retry presents the existing proof rather than buying twice.
Spend authority. Something has to decide whether this particular price for this particular resource is acceptable, and enforce a ceiling. That decision cannot live in the model's judgment alone.
The last one is where most projects stall, because it is not a protocol problem. It is a custody problem.
The client side is the unsolved half
A payment protocol tells a client how to pay. It does not tell you how the client came to control funds in the first place, and that is the question that decides whether any of this can run unattended.
The options that do not work are instructive. Handing an agent a private key with your balance behind it makes every prompt injection a withdrawal. Routing each payment through a human approval defeats the purpose of automation. Using a custodial account puts a third party between your agent and its funds, and reintroduces the account relationship the protocol was designed to avoid.
CryptoCadet exists for this half. It is a non-custodial USDC payment rail for agents, built Base-only, where the agent operates a bounded spending float through session keys with custody held in the OS keychain. The agent pays autonomously, without a human in the loop for each transaction, and the ceiling on what it can spend is enforced by the session key rather than by instructions in a prompt. It supports x402-style pay-per-call alongside ERC-20 subscriptions, with USDC as the settlement asset.
That combination is what makes the four step flow above operational rather than a demonstration: a protocol for quoting and proving payment, and a bounded, non-custodial way for the client to actually hold and spend money.
Frequently asked questions
- What is x402?
- A way to use the reserved HTTP 402 Payment Required status as a machine-readable payment challenge. The server answers a request with structured payment terms, the client settles, and the client retries the same request carrying proof. It makes payment part of the HTTP exchange instead of a separate signup and invoicing process.
- How is x402 different from using an API key?
- An API key requires a relationship established before the first request: signup, provisioning, and usually a billing arrangement. With a 402 flow no relationship exists before the request or needs to persist after it. That matters when a program discovers a resource at runtime and needs it once, where account management would cost more than the purchase.
- What is the hardest part of implementing agent payments over HTTP?
- Not the status code. Settlement has to clear fast and cheaply, the server has to verify proof without a round trip that exceeds the sale value, retries must be idempotent so a repeated request does not pay twice, and something has to enforce a spending ceiling. The last one is a custody problem rather than a protocol problem.
- Can an agent pay without holding a private key directly?
- It should. Giving an agent unrestricted key access makes any prompt injection a withdrawal. A bounded approach gives the agent a spending float through session keys with custody in the OS keychain, so the ceiling is enforced cryptographically rather than by instructions the model could be argued out of.