Frequently asked questions

HTTP 402 has waited decades for a money layer. Here’s how we see it coming to life responsibly.

What is HTTP 402? Why unused?

402 Payment Required appears in RFC 7231 as “reserved for future use.” Early drafts anticipated digital cash, but no interoperable web-native payment rail existed, so browsers never implemented native handling.

Is 402 deprecated or experimental?

It’s neither deprecated nor fully specified. Servers may emit 402 responses today, yet the semantics for required headers or retry behaviour remain open for convention and future standardisation work.

Why focus on Bitcoin and Lightning?

Bitcoin provides an open, censorship-resistant settlement asset. Lightning adds instant, low-fee micropayments with invoices clients can settle programmatically - making per-request economics realistic.

How does a 402 flow operate?

A client requests a resource. The server responds 402 with headers describing price, method, and a payment request (for example, a Lightning invoice). Once the client pays, it retries the original request, optionally including proof headers, and receives 200 OK.

Does this require new browsers?

No. Existing browsers or API clients can implement 402 handling in userland today. Wallet extensions, WebLN-capable apps, or service workers can detect the status code, prompt for payment, and replay the request once settled.

What about privacy and fees?

Lightning routes can be blinded, invoices can expire quickly, and clients choose what metadata to reveal. Fees are typically sats-level fractions of a cent, keeping experimentation affordable for developers and publishers.