x402 exists because the buyer being a piece of software breaks the assumptions card payments are built on. There is no cardholder to authenticate, no chargeback window that means anything, and no appetite for a signup flow. HTTP 402 was reserved for exactly this and went unused for thirty years.
The practical consequence is that a price can be attached to an endpoint rather than to a customer relationship. An agent that has never seen your service before can discover the price, pay it, and get the response in one round trip.
Publish a payable endpoint
- 1
Claim your @handle in the app if you have not already.
- 2
Open the x402 section and create a resource with a slug and a price in USDC.
The resource lives at https://x402.spendthebits.com/@yourhandle/slug/ — a public URL under your handle, deliberately outside the app's authenticated API so an agent can reach it with no credentials. The machine-readable manifest at https://x402.spendthebits.com/.well-known/x402 lists it for crawlers.
- 3
Point the resource at what you are selling — an API response, a dataset, a piece of content.
- 4
Test it with an unpaid request and confirm you get a 402 with the price in the response.
That 402 body is the whole discovery mechanism. If it is missing or wrong, agents cannot pay you. A real exchange, recorded against a live endpoint on 2 September 2026: the unpaid GET answered 402 with accepts for USDC on Base, Polygon, Arbitrum and Solana; the agent retried with a signed authorization in the PAYMENT-SIGNATURE header; the resource came back 200 with a PAYMENT-RESPONSE header naming the settlement transaction on Base, 1.4 seconds after the first request.
- 5
Watch settlements arrive in Activity.
Each settled call is one inbound USDC transaction in your history, with its cost basis recorded for the tax export.
Good to know
- Agents pay in USDC using EIP-3009 transfer authorisations, which are gasless for the payer and settle directly to your address.
- Your endpoint quotes Base first, then Polygon and Arbitrum, and Solana when you hold a Solana address. Only chains the settlement facilitator can actually settle are ever quoted, so an agent never sees a price it cannot pay.
- A retried request carrying an authorization that already settled is answered from the original settlement, with no second charge. An authorization for the wrong amount, or one already spent on a different resource, is refused with a fresh 402.
- A small service fee, under 1%, applies to payments settled to your @handle. The live figure is in the app under Settings → Fees.
- Because settlement is to keys you hold, there is no payout schedule, no reserve, and no account that can be closed with your balance inside it.
Frequently asked
An open convention for paying for an HTTP resource inline: the server answers an unpaid request with 402 Payment Required plus a machine-readable price, the client pays on-chain, and retries with proof of payment.
No. The resource is hosted for you under your @handle. What you provide is the thing being sold and the price.
Yes, though it is not the interesting case. The design target is software that needs to pay a small amount, immediately, without a relationship.
Get SpendTheBits
A fully non-custodial wallet for 13 chains, free on iOS and Android. Your keys never leave your phone.