L402: The Protocol That Lets Software Pay for Software

HTTP has had a status code for payments since the beginning. 402 Payment Required has been in the spec since 1997 — right next to 401 Unauthorized and 403 Forbidden. But nobody could use it. There was no digital payment system fast enough, cheap enough, or programmable enough to settle a payment in the middle of an HTTP request-response cycle.

For almost thirty years, 402 sat there doing nothing. APIs that wanted to charge money had to bolt on account systems, API key management, subscription billing, and payment processors. You couldn't just charge for a request. You had to build an entire business infrastructure around charging for requests.

The Lightning Network changed the economics. Payments settle in milliseconds, cost fractions of a cent, and can be triggered by any software that can make an HTTP call. In 2020, Lightning Labs published a protocol spec that finally put 402 to work. They called it LSAT (Lightning Service Authentication Token), later renamed to L402 — the Lightning HTTP 402 Protocol.

How it works

Three HTTP requests. That's the whole thing. The client and server don't need to know each other beforehand.

Step 1: Client requests a resource.

GET /api/premium/data HTTP/1.1
Host: api.example.com

Step 2: Server responds with 402 and a challenge.

Instead of data, the server sends back a Lightning invoice and a macaroon — a cryptographic token that will become the client's credential after payment.

HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="AGIAJEe...", invoice="lnbc100n1..."

Step 3: Client pays the invoice and retries.

The client pays the Lightning invoice through any Lightning wallet. Payment produces a preimage — a cryptographic proof that the invoice was paid. The client combines the macaroon with the preimage and sends both back as an authorization header.

GET /api/premium/data HTTP/1.1
Authorization: L402 AGIAJEe...:abcdef1234...

The server verifies the macaroon's signature and checks the preimage against the payment hash. If both check out, it returns the data. The whole exchange — challenge, payment, verification, access — takes under a second.

Client                              Server
  │                                    │
  │──── GET /api/data ────────────────▶│
  │                                    │
  │◀── 402 + invoice + macaroon ───────│
  │                                    │
  │    [pays Lightning invoice]        │
  │    [receives preimage]             │
  │                                    │
  │──── GET /api/data ────────────────▶│
  │    Authorization: L402             │
  │    macaroon:preimage               │
  │                                    │
  │◀── 200 OK ─────────────────────────│
  │    { "data": "..." }               │
  │                                    │

Why macaroons, not API keys

You could use any token format here — JWTs, opaque strings, whatever. L402 uses macaroons, and it's not an arbitrary choice.

Macaroons come from a 2014 Google Research paper titled "Cookies with Contextual Caveats." They're bearer tokens like cookies or API keys, but with one property that changes everything: anyone holding a macaroon can add restrictions to it after it's been issued. These restrictions are called caveats.

A server issues a macaroon. Before using it, a client — or a proxy, or a middleware layer — can append caveats:

• expiry = 2026-03-01T00:00:00Z — token expires at this time
• endpoint = /api/weather — only valid for this route
• request_count <= 10 — only good for ten requests

Each caveat is cryptographically chained using HMACs. You can add caveats but never remove them. The server verifies the chain in order — if any caveat fails, access is denied.

Three properties fall out of this design that matter for L402:

The server doesn't need a database of issued tokens. It verifies the macaroon using only the root key it originally used to create it, plus the preimage from the Lightning payment. No session table, no token store, no lookup per request. Verification is a local cryptographic operation.

A service can issue a macaroon and a downstream proxy can tighten it — adding an expiry or restricting which endpoints it covers — without going back to the original issuer. Delegation is baked into the math.

And the clever part: the macaroon embeds the payment hash as a caveat. The preimage — which you only get by paying the Lightning invoice — is the proof that satisfies that caveat. No payment, no valid credential. The cryptography enforces it, not a database check.

Compare this to API keys. An API key is a random string in a database. Verifying it means looking it up. Revoking it means deleting it. Scoping it means adding columns. Expiring it means a cron job. Every request hits the database. At scale, this becomes your bottleneck.

A macaroon is self-contained proof. Verification is a local cryptographic operation. That's the difference between O(1) and O(database).

The API monetization problem

If you've ever tried to charge for an API, you know the options aren't great.

Free with rate limits. You subsidize everyone until they hit a wall, then hope they convert. Most don't.

Subscription tiers. The developer who needs 50 requests pays the same as the one who needs 10,000. You lose the long tail.

Usage billing with Stripe. Stripe takes 2.9% + $0.30 per charge, which makes anything under a dollar absurd. So you batch into monthly invoices, which means net-30 terms, failed charges, and a billing system that costs more to maintain than the revenue it generates.

L402 creates a fourth option: pay per request, in real time. The client pays for exactly what it uses. No signup, no billing cycle, no minimum charge. A request costs 10 sats — roughly a penny — and the economics still work because Lightning fees are fractions of a cent.

This isn't theoretical. Lightning Labs has been running L402 in production since 2020, gating access to Loop (a channel liquidity service) and Pool (a channel marketplace) through Aperture, their L402 reverse proxy.

Agents can't fill out signup forms

Here's where L402 gets genuinely interesting.

An AI agent that needs to call a paid API today requires a human to create an account, generate a key, configure it, and fund it. For one API, fine. For five, annoying. For every paid service an agent might discover and want to use at runtime — impossible.

But an agent with a Lightning wallet can handle a 402 response on its own. It sees the invoice, pays it, retries with the credential, gets the data. The whole loop is machine-readable. There's nothing in the protocol that requires a human to be involved.

You'd want guardrails. Cap any single payment at 100 sats. Cap daily spend at 50,000. The agent operates within a budget, not with a blank check. But within those limits, every L402-protected API in the world is accessible to every agent with a balance. Both sides of the transaction can be software. That's new.

L402 vs. x402

You'll hear about x402 if you haven't already. Coinbase published it in 2025 — same concept (HTTP 402 + inline payment) but using USDC stablecoins on EVM chains instead of Bitcoin on Lightning.

L402 — Bitcoin over Lightning. Millisecond settlement. Stateless verification via macaroons. No external dependencies. In production since 2020.

x402 — USDC on Base/EVM. Stable dollar pricing. Requires a facilitator (often Coinbase) to verify on-chain payments. Launched 2025.

The practical tradeoff: x402 gives you dollar-stable pricing, which matters for commerce. L402 gives you faster settlement, stateless verification, no facilitator dependency, and no minimum cost floor. For high-frequency agent interactions — hundreds of requests per second — Lightning's speed and L402's stateless verification are hard to match. For a full breakdown, see the comparison in our pay-per-API-call guide.

Building with L402

The pay-per-API-call guide walks through the full server and client implementation — Express.js middleware, ASP.NET Core middleware, auto-pay clients, pricing strategies.

The AI agent payments guide covers giving an agent a wallet and letting it pay L402 APIs on its own — via MCP or SDK.

The protocol spec is open source, published by Lightning Labs. HTTP 402 sat unused for almost thirty years waiting for a payment system that could keep up with a request-response cycle. Now it has one.