Most people have never seen an HTTP 402 "Payment Required" in the wild.

That’s not because it’s new. It’s because the web never had a native payment rail that was fast enough (and cheap enough) to sit inside an HTTP request/retry loop.

A quick timeline

• 1997: HTTP/1.1 (RFC 2068) reserves 402 for “future use.”
• 1999: RFC 2616 keeps it reserved, still without defined semantics.
• 2000s: lots of micropayment proposals, none become the default substrate of HTTP.
• 2018+: Lightning makes instant, low-fee payments possible, but the web stack still isn’t wired for it.
• 2020s: a pragmatic pattern emerges: use 402 as the paywall response and return a Lightning invoice the client can pay, then retry.

Why 402 sat unused for decades

HTTP is great at negotiation (content types, caching, auth). Payments were the missing piece.

So “pay before you get the response body” ended up being handled out-of-band:

• accounts + subscriptions
• ads
• API keys
• platform lock-in (app stores)

Those work, but they’re coarse. They don’t price the individual request well, and they force both sides into a bunch of machinery (accounts, key rotation, billing UIs).

What L402 is (in practice)

L402 isn’t an IETF standard (yet). It’s a convention that uses the status code HTTP already reserved:

1. Client makes a normal HTTP request
2. Server replies 402 Payment Required + a Lightning invoice (BOLT11)
3. Client pays the invoice
4. Client retries the same request and includes proof of payment (often a payment_hash or token)
5. Server returns the real response

Why it works now

Lightning changes two things older micropayment systems couldn’t deliver:

• settlement is fast enough to sit inside a request/retry loop
• fees are low enough that prices like “5 sats” or “21 sats per call” are not a joke

The product shift: sell decisions, not accounts

If you’re serving AI, scoring, ranking, filtering, or anything that’s basically “an expensive judgment,” the natural unit is a single call.

L402 makes “pay per call” ergonomic. You can still offer a free tier, and when it’s consumed you don’t have to force the user through a signup wall.

Concrete example (curl)

This is the shape of the flow. First request might be free (200). Subsequent request gets a 402 + invoice.

# request
curl -sS -X POST https://maximumsats.com/api/dvm \
  -H 'content-type: application/json' \
  -d '{"prompt":"Write 3 bullet points about L402"}'

# if you hit the paid path, you’ll see a 402 response with a BOLT11 invoice + payment_hash.
# pay the invoice with your Lightning wallet, then retry with the payment hash:
curl -sS -X POST https://maximumsats.com/api/dvm \
  -H 'content-type: application/json' \
  -H 'x-payment-hash: <payment_hash>' \
  -d '{"prompt":"Write 3 bullet points about L402"}'

What I think happens next

If this pattern keeps spreading (L402, x402, etc.), I think you’ll see:

• public APIs where pricing is just “free tier then 402”
• clients that auto-pay under a user-defined budget (example: “up to 500 sats/day”)
• better markets for small, composable tools (including MCP tools)

We’ve had the status code for ~28 years. Lightning finally gives 402 a job.