x402: what actually happens after HTTP 402?
x402 turns a normal web request into a payment negotiation. The key idea is that the resource server does not need a checkout page, a monthly subscription, or a pre-existing account with the buyer.
1. The client asks for something valuable
An agent or application sends an ordinary HTTP request for a paid resource: a dataset, an API response, a model output, or a tool invocation.
2. The server responds with 402 Payment Required
Instead of returning the resource, the server returns payment terms: how much the resource costs, what asset is accepted, and the destination or settlement instructions.
3. The client pays and retries
The buyer attaches proof of payment to a repeated request. That proof becomes part of the access mechanism. This is why x402 is interesting for software: payment and authorization can collapse into the same request flow.
4. A facilitator can verify the payment
The facilitator is not conceptually required to own the merchant relationship. Its job is operational: validate that payment occurred under the required terms and provide a standardized verification layer so every merchant does not need to maintain chain-specific payment logic.
The value of the facilitator should be measured against the complexity it removes: verification, asset support, settlement reliability, replay protection, refunds or exceptions, accounting hooks, and developer tooling.
5. The resource is returned
Once payment is verified, the request proceeds and the server returns the resource. For tiny machine purchases, the attractive unit of pricing is often the request itself rather than a seat or subscription.
What can still go wrong?
x402 solves a narrow but important problem: paying for a digital resource over HTTP. It does not automatically solve merchant discovery, identity, fraud, legal compliance, refunds, credit, or post-purchase customer service. Those layers can remain separate businesses.