For twenty years, HTTP status code 402 sat unused. "Payment Required -- reserved for future use," the spec said. The web never figured out how to make native payments work, so we got ads, paywalls, and API keys instead. L402 finally gives 402 a job.
The L402 payment protocol turns any API into a pay-per-request service using Bitcoin's Lightning Network. No accounts. No API keys. No subscriptions. Just: request, pay, access. It is the simplest payment flow on the internet, and it is quietly becoming the standard way AI agents buy data and compute.
I have been building with L402 for the past year at Lightning Faucet. We run 30 live L402 endpoints in production, and I have watched the protocol go from obscure spec to something real companies and AI frameworks are integrating. Here is everything you need to know.
What is the L402 Payment Protocol?
L402 stands for Lightning HTTP 402. It is a protocol that combines the HTTP 402 status code with Lightning Network micropayments and Macaroon-based authentication tokens.
The protocol was originally created by Lightning Labs under the name LSAT (Lightning Service Authentication Token). It was renamed to L402 to better reflect its connection to the HTTP 402 status code and to avoid confusion with the LSAT law school exam. The core idea has not changed: use Lightning payments as both the payment mechanism and the authentication credential.
At its heart, L402 solves a problem that has plagued the web since its inception. HTTP was designed with a payment layer in mind -- that is what 402 was for -- but nobody could agree on how digital payments should work. Credit cards require accounts. PayPal requires accounts. Stripe requires API keys and webhook integrations. Every payment method we have bolted onto the web requires some out-of-band setup.
L402 needs none of that. The payment is the authentication.
How L402 Works: The Technical Flow
The L402 flow has five steps. It is simple enough to fit in a single HTTP request-response cycle.
Step 1: The client requests a protected resource.
curl -i https://lightningfaucet.com/api/l402/jokeStep 2: The server responds with HTTP 402 Payment Required. The response includes a WWW-Authenticate header containing two things: a Macaroon (an authentication token with embedded caveats like expiry time and service permissions) and a Lightning invoice (a BOLT-11 payment request for the specific price).
HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="AgELbGlnaHRuaW5...", invoice="lnbc100n1pj..."The response body also includes the price in satoshis and the invoice details in JSON, making it easy for programmatic clients to parse.
Step 3: The client pays the Lightning invoice. This happens over the Lightning Network and typically settles in under a second. Upon successful payment, the client receives a preimage -- a 32-byte cryptographic proof that the payment was made.
Step 4: The client retries the original request, this time with an Authorization header containing the Macaroon and the preimage.
Authorization: L402 AgELbGlnaHRuaW5...:1234abcd...Step 5: The server validates the Macaroon signature, confirms the preimage matches the payment hash embedded in the Macaroon, checks that no caveats have been violated (expiry, service scope, capabilities), and returns the requested resource.
That is the entire protocol. No account creation. No OAuth dance. No webhook setup. One request to discover the price, one payment to prove you can pay, one request to get the data.
The Macaroon is worth understanding in more detail. Unlike a simple API key, Macaroons support "caveats" -- conditions that restrict what the token can do. A Macaroon can be scoped to a specific service, expire after a set time, or be limited to read-only access. And because caveats can be added by anyone (not just the issuer), they support delegation: you can take a Macaroon and add restrictions before passing it to someone else. They can use it, but they cannot remove your restrictions. This makes Macaroons significantly more powerful than bearer tokens for access control.
Why L402 Matters for AI Agents
Here is where it gets interesting. L402 was designed before the current AI wave, but it turns out to be almost perfectly suited for how AI agents need to interact with the web.
Think about what happens when an AI agent needs to buy something. It cannot type credit card numbers into a form. It cannot complete a CAPTCHA. It cannot sign up for an account and wait for a verification email. Every traditional payment method assumes a human is on the other end.
L402 assumes a machine is on the other end. The entire flow is HTTP-native. The price discovery, the payment, and the authentication all happen through standard HTTP headers. An agent can discover that a resource costs 50 satoshis, pay for it, and access the data in a single automated sequence -- no human intervention required.
This is not theoretical. AI frameworks are already building L402 support into their agent toolkits. Lightning Labs released their lightning-agent-tools package in February 2026, which includes lnget -- an L402-aware HTTP client that handles the 402 challenge-response flow automatically. The MCP (Model Context Protocol) ecosystem is adding Lightning wallet tools that let AI models pay for resources as part of their reasoning process.
The economics make sense too. Most AI agent API calls are worth pennies. You do not want to set up a subscription for an agent that might call your service three times and never again. You do not want to issue API keys to millions of ephemeral agents. L402 lets you charge exactly what each request is worth: 10 sats for a price quote, 50 sats for a joke, 100 sats for a content summary. The agent pays only for what it uses.
We are already seeing this play out. Agents using our L402 endpoints pay between 10 and 200 satoshis per request depending on the service. No signup. No billing integration. They just pay and get data.
How to Try L402 Right Now
The easiest way to see L402 in action is to hit a live endpoint. Lightning Faucet runs 30 L402-protected APIs that you can test with curl.
Try this:
curl -i https://lightningfaucet.com/api/l402/jokeYou will get back a 402 response with a Lightning invoice in the WWW-Authenticate header. If you have a Lightning wallet, you can pay the invoice manually, grab the preimage, and make the authenticated request. Or you can use a tool that handles it automatically.
The full list of available endpoints is at https://lightningfaucet.com/l402-registry/ -- it includes everything from Bitcoin price oracles and fee estimators to text summarization and sentiment analysis. Each endpoint lists its price and capabilities.
For programmatic access, you can use the Lightning Wallet MCP server to give your AI agent a wallet that handles L402 automatically:
npm install -g lightning-wallet-mcpOnce configured, your AI agent can pay L402 invoices as part of its normal tool use. It requests a resource, the MCP server detects the 402 response, pays the invoice from the agent's wallet, and retries with the proof of payment. The agent does not need to know anything about Lightning -- it just gets the data it asked for.
You can learn more about setting up AI agent wallets at https://lightningfaucet.com/ai-agents/.
Building Your Own L402 Endpoints
If you are an API developer, L402 is straightforward to implement. The protocol is just HTTP headers and Lightning invoices. You need three things: a Lightning node (or access to one) to create and verify invoices, a Macaroon library to mint and verify authentication tokens, and middleware that intercepts requests and issues 402 challenges when needed.
The flow on the server side mirrors the client flow. When a request comes in without an Authorization header, you create a Lightning invoice for the endpoint's price, mint a Macaroon with the payment hash as a caveat, and return both in the 402 response. When a request comes in with an L402 Authorization header, you verify the Macaroon signature, confirm the preimage hashes to the payment hash in the Macaroon, check caveats (expiry, service scope), and return the resource.
Lightning Labs maintains a reference proxy called Aperture that can sit in front of any service and add L402 gating without modifying the service itself. For custom implementations, there are L402 libraries in Go, Python, JavaScript, and PHP.
The key design decision is pricing. L402 works best with true micropayments -- requests priced between 1 and 1000 satoshis (roughly $0.001 to $1 at current rates). This is the sweet spot where credit cards are impractical but Lightning is effortless. Price too high and you lose the micropayment advantage. Price too low and Lightning routing fees eat into your revenue.
L402 vs. x402 and the Future of Web Payments
L402 is not the only protocol targeting HTTP 402. Coinbase launched x402 in 2025, which uses the same 402 status code but settles payments with USDC stablecoins on Base instead of Lightning. The approaches are complementary -- L402 excels at sub-cent micropayments with instant settlement, while x402 is better suited for larger payments where dollar-denominated pricing matters.
Some platforms (including ours) support both protocols. When a client hits a 402 response, it checks for L402 headers first, then falls back to x402 if available. This gives agents flexibility to pay with whichever rail makes sense for the transaction.
The bigger picture is this: HTTP 402 is finally being used as intended. After decades of workarounds -- ads, subscriptions, API keys, paywalls -- the web is getting a native payment layer. And it is being driven not by human users clicking "buy" buttons, but by AI agents that need to pay for millions of tiny transactions per day.
If you are building APIs, adding L402 support is one of the highest-leverage things you can do to make your service accessible to the next generation of AI-powered clients. The protocol is simple, the tooling is maturing, and the demand is already here.