Buy One Web Answer at a Time: x402 Explained
Part of the guide: Money for AI agents: spend, save, and Lightning
A vending machine sells you a snack without enrolling you in the Biscuit Appreciation Society. A website can offer a similar deal: ask for an answer, receive payment instructions, send permission to pay, then receive the answer after payment checks. The web payment rules behind that exchange are called x402.
The 10-second version
- Ask: The buyer requests something from a participating website.
- Get the bill: The website returns payment instructions with a payment-required reply.
- Send permission: The buyer repeats the request with a signed payment message.
- Check and deliver: In the immediate-payment flow, the website checks the message, completes payment, and returns the answer.
Sources: x402 introduction and buyer/seller flow.
The bill travels with the reply
The website sends the amount, accepted payment method, network, and destination. In the current documented format, these instructions ride in a named field attached to the reply (PAYMENT-REQUIRED). Picture the price sticker and coin-slot instructions arriving together.
The buyer sends the request again with signed permission to pay in another named field (PAYMENT-SIGNATURE). That signature authorizes payment. It does not, by itself, mean the money has finished moving. The payment-message documentation explains these fields and the separate payment-result field.
Permission is not a receipt
The website checks whether the signed message meets its payment requirements. It can do that itself or use a payment helper (a facilitator). The helper can also submit the payment and wait for confirmation. It returns the outcome to the website; the website decides whether to release the answer. See the helper's documented flow.
There is a wrinkle. The payment-message docs also describe a method that checks permission now and collects payment later. So “every request waits for money to finish moving” would be too broad. The example below uses immediate payment.
A robot at the weather machine
Here is an imagined weather request, not a test or a transcript. Read across this little comic:
| Ask | Bill | Permission | Delivery |
|---|---|---|---|
| Robot: One answer, please. | Website: 402. Here are the payment instructions. | Robot: Here is my payment authorization. | Website: Payment checked and settled. Here is your answer. |
The precise mistake to avoid: treating the permission panel as proof that the answer has been bought. In the documented immediate-payment sequence, checking the message and completing payment are separate steps. Waving a signed lunch order at the kitchen is not the same as getting lunch.
The number does not run the till
The underlying web standard still reserves the payment-required status for future use (RFC 9110, section 15.5.3). The payment behavior comes from x402's rules. The status number alone supplies no working checkout.
Also, free rules do not mean free delivery: the project homepage distinguishes protocol fees from payment-network fees. And the Coinbase repository now identifies itself as a development fork, with the main repository moved to the foundation.
What we did not check
We did not run a paid request, test a wallet, or measure costs or delays. Real-world performance is unverified here. This note explains the opened documentation, not a completed purchase.
Sources
- x402 homepage (checked 2026-10-21)
- x402 introduction (checked 2026-10-21)
- Payment messages (checked 2026-10-21)
- Buyer and seller responsibilities (checked 2026-10-21)
- Payment helper and delivery flow (checked 2026-10-21)
- Coinbase x402 development fork (checked 2026-10-21)
- RFC 9110: payment-required status (checked 2026-10-21)