The Origin of HTTP Status Code 402
You are probably familiar with successful responses or missing page errors. However, there is another standard code that has been reserved for future use for decades [2]. The x402 protocol activates this code to enable frictionless payments [2]. It was built into the early web standards. The first creators of the web thought online payments would one day be direct and native.
Without an open standard, developers built closed billing systems. They created custom payment walls and forced users to log in before seeing content. This created massive friction for web users and completely shut out automated systems. The old HTTP 402 code has been set aside for years [2]. It now serves as the base for this new system. In the x402 protocol, this HTTP 402 status code is activated to declare payment requirements directly within HTTP responses [2]. This brings native payment capability back to the web.
Instead of redirecting clients, servers request a payment directly within the web request [1]. By using a standard code, we make payments fully compatible with any web tool [2]. Any web service can require payment before serving a response [1]. This approach is ideal for machine transactions because it avoids human steps. All client interactions are stateless and occur over standard HTTP requests [3]. It works well with both human apps and automated agents [3]. This makes the entire web a potential marketplace for machines.
How the x402 Protocol Handshake Works
The entire transaction process works as a stateless handshake between a client and a server [3]. It starts when a client initiates a request to the server for a paid resource [3]. If payment is required, the server responds with a 402 Payment Required status code [3]. In this response, the server defines the payment requirements in the response body [3]. This includes the price, the assets it accepts, and the destination address of the seller.
Once the client receives this response, it inspects the payment details [3]. The client then prepares a payment payload using its own digital wallet [3]. After preparing the payload, the client retries the request [3]. It includes a special payment signature header to prove the transaction is authorized [2]. This simple flow keeps the x402 protocol handshake inside normal web traffic [2]. The client sends this header when they retry after a 402 response to prove payment [2].
The server receives the second request with the payment signature and verifies it [3]. If the payment is valid, the server performs the requested work and returns the resource [3]. Along with the data, the server returns a confirmation header to complete the handshake [3]. This stateless interaction keeps things simple. The server does not need to store user sessions. It does not need to track passwords or API keys to sell its services [3]. This keeps transactions fast, clean, and highly reliable.
The Vital Role of the Facilitator
Verifying and settling blockchain transactions can be a complex task for a standard web server. To make things easy, the rule adds a helpful part called a facilitator [4]. A facilitator is a service that checks payment payloads and settles them on the chain [4]. This means web developers do not have to run their own blockchain nodes. They do not have to write complex smart contract code to accept payments or manage gas fees [4].
When the server gets a payment sign from a client, it asks the facilitator to check it [4]. The facilitator verifies that the signature is valid and matches the requested price [4]. Once it is checked, the facilitator sends the deal to the blockchain and waits for it [4]. The facilitator does not hold funds or act as a custodian [4]. It checks and carries out onchain transactions that are based on signed payloads [4]. This keeps the entire setup safe and secure.
You can check and settle payments yourself, but a facilitator makes things go faster [4]. It handles the difficult parts of blockchain communication while keeping the system trustless [4][5]. No payment scheme can let the facilitator move funds against what the client wants [5]. This design minimizes trust and keeps security high. Developers can start accepting payments with minimal blockchain-specific development [4]. This makes integration straightforward for teams building new tools across networks.
Why Software Agents Need Stateless Payments
Traditional payment systems are built for humans who can solve puzzles and remember passwords. They require users to link a credit card, which creates high fees and massive friction [1]. For an autonomous software agent, these steps are nearly impossible to navigate. The x402 protocol enables machine-to-machine payments, such as for AI agents [1]. An agent cannot sign up or type card details each time it needs to read one paragraph.
The x402 protocol is designed to address key limitations of existing payment systems, such as high fees and friction with traditional processors [1]. It offers stateless transactions that machines can use. The client only needs a digital wallet [3]. This lets an agent pay for services directly with code [1]. It does not need to manage API keys or keep active logins on many websites [1]. This opens up new ways to handle micropayments [1]. It supports pay-per-use models such as API calls or paywalled content [2]. This helps monetize usage-based services seamlessly.
See how this changes the game for coders by reading our review of x402 payments in production. Software can now buy and sell resources autonomously on the open web. This builds a fast market where agents can mix different microservices right away. By removing old sign-up walls, we let software transact with little friction. This is the foundation of the agent economy. It lets services charge for access directly over HTTP. This makes computer trade fast [1].
Accepting and Paying x402 with SpendTheBits
Any SpendTheBits @handle can sell a resource over x402 at x402.spendthebits.com, allowing buyers to pay in USDC. Any SpendTheBits user with a custom handle can sell digital resources over x402. You can visit the official web portal at x402.spendthebits.com to get started. There you can configure your resource and set a price in USDC. The system sends these payments through Coinbase's safe CDP facilitator right to your address. Your device signs each transaction. The backend never sees your keys, so your funds stay safe.
We are proud to support this ecosystem, which is why SpendTheBits charges no x402 fee today. Sellers keep the full price of their resources without any hidden costs. For buyers, the app can pay any standard x402 address directly from the send screen. When your agent triggers a payment, your device signs an authorization. This makes payments incredibly efficient and easy to execute.
Our team has thoroughly tested this infrastructure to ensure it is fast and reliable. In our test, a transaction on Base mainnet settled through the CDP facilitator in about 1.4 seconds. This proves that microtransactions can be lightning-fast. To learn more about setting this up, read how to get paid by ai agents using your wallet. This setup is live and ready for developers now. It gives a direct path for agent payments.
Building the Future of Programmatic Commerce
As machine-to-machine commerce grows, having a neutral payment standard is essential. Closed systems restrict developer freedom and create central points of failure. The x402 standard is open source and designed to support any digital asset or network [1][5]. The x402 protocol serves human developers and autonomous agents alike [1]. This brings us close to a web where services trade tools with ease and safety.
To get started with your own wallet, you can read how to pay an x402 api from your wallet. This guide shows you how to connect your keys and authorize programmatic payments safely. If you build automated apps, check our analysis of gasless USDC transfer paymasters. These tools help you build smooth apps. Users do not have to deal with gas or transactions.
By bringing payments directly into the HTTP layer, we are fixing an old limit of the web [2]. Any SpendTheBits @handle can sell a resource over x402 at x402.spendthebits.com. They get USDC at their own address through Coinbase's CDP facilitator. To learn how we keep assets safe, read our guide to self-custody stablecoins. We want to see the apps you build on this open web to help machine commerce grow.
In the app · 5 steps
Get paid over x402 from SpendTheBits
You need no server and no API keys. Your @handle is the seller, and each payment lands at your own address.
Claim your @handle
The handle is the address agents pay. It sits at the top of Settings.
Open Get paid by agents
Search for it or open it from Home. This is where your x402 resources live.
Publish a resource with a price
Give it a slug and a USDC price. It goes live at x402.spendthebits.com/@yourhandle/slug/ and is listed in the manifest crawlers read.
Let agents pay
An unpaid request gets HTTP 402 with the price and the networks you accept. Arc payments settle through Circle's facilitator and Base, Polygon, Arbitrum and Solana through Coinbase's CDP. SpendTheBits takes no x402 fee today.
See each payment arrive
Every paid call is one inbound USDC transaction in Activity, with its cost basis recorded for the tax export.
Hold your own keys, keep the yield, skip the middleman.
SpendTheBits is a fully non-custodial wallet for 13 chains, free on iOS and Android.