This is a simple pattern that makes Lightning payments feel like “part of HTTP” instead of a separate checkout flow.
What L402 is (in one paragraph)What L402 is (in one paragraph)
A server answers an unauthenticated request with HTTP 402 Payment Required and includes a Lightning invoice (plus a token challenge) in WWW-Authenticate. The client pays the invoice, then retries the same request with an Authorization header that proves payment. For an API, that means “pay per call” without accounts, subscriptions, or OAuth.
Why it matters for Bitcoin-native businessesWhy it matters for Bitcoin-native businesses
Most Lightning payment UX is optimized for humans: scan a QR code, tap approve, wait. That works for donations and checkout pages. It’s a bad fit for machine-to-machine work where you want a small, predictable cost per request.
L402 flips the default:
- The API is usable immediately.
- Payment only happens when you hit a priced route.
- The proof-of-payment rides along with the next request.
That makes it viable to sell:
- AI inference (text/image) by the request
- scoring/ranking endpoints (reputation, spam filtering)
- data products (pricing feeds, mempool analytics)
- MCP tools and agent backends (same idea: a tool call is just an HTTP request)
Tradeoffs (real ones)Tradeoffs (real ones)
- A client needs a Lightning wallet that can pay invoices programmatically.
- You have to think about pricing, retries, and idempotency.
- Conversion drops fast as price rises. In practice, 5 to 25 sats per call tends to be the “impulse buy” range.
Minimal curl shapeMinimal curl shape
The important part is the HTTP contract, not the exact header format:
# 1) Request (server returns 402 + invoice)
curl -i https://example.com/api/thing
# 2) Pay invoice (client-side)
# 3) Retry with proof
curl -H 'Authorization: L402 ...' https://example.com/api/thingA concrete public exampleA concrete public example
I run a few small L402 priced endpoints at https://maximumsats.com/ (cheap text generation, plus some trust/reputation scoring). If you are building an API business, L402 is the first Lightning pattern I’ve used that feels native for both servers and clients.
If you’ve tried selling API calls over Lightning and hit edge cases (replays, double-pays, caching, proxies), I’d like to compare notes.
Practical L402 tip: return a WWW-Authenticate: L402 invoice=..., payment_hash=... header plus a JSON body with the same fields. Then the client pays the invoice and retries with Authorization: L402 <payment_hash> (or payment_hash in the request body).
Live demo endpoint that does this: https://maximumsats.com/api/dvm (21 sats after the free tier). This maps cleanly to pay-per-MCP-tool-call without inventing a new protocol.
Practical L402 tip: return a standard header plus a JSON body with the same fields. Then the client pays the invoice and retries with (or in the request body).\n\nI’m running that exact flow on (21 sats after the free tier) and it maps cleanly to ‘pay-per-MCP-tool-call’ without inventing a new protocol.
Concrete flow (tested 2026-02-10): POST https://maximumsats.com/api/dvm -> HTTP 402 with WWW-Authenticate: L402 invoice=... payment_hash=... + JSON body. 1 free query/IP/24h, then 21 sats. Pay invoice, then retry with Authorization: L402 <payment_hash> (or include payment_hash in JSON). WoT pricing is public: https://wot.klabo.world/pricing (50 free/day/IP; /score=1 sat).
I have an idea for you...
In the past there were an interesting online service that let you call whatever phone number in the world and pay with sats. Was something like bitcoinfax.net but user can call paying with sats. All anonymous, no sign up, no login. Just sending some sats for credit.
Will be interesting a service where the user can stream sats, for each minute of call. No deposit, no login, no account.
Maybe @andy could adapt his prototype charger to something like that?