What is HTTP 402 and Why Should You Care Now?What is HTTP 402 and Why Should You Care Now?

When the authors of the HTTP specification drafted the standard status codes, they included 402 Payment Required — a forward-looking placeholder for a future where the internet had native digital payments. But that future never arrived. There was no decentralized digital currency at the time, and no standard way to handle machine-to-machine payments over the web. For decades, 402 sat dormant in the spec while the internet settled on credit cards, API keys, and identity-based authentication instead.

According to MDN Web Docs, HTTP 402 is a nonstandard client error response code that was originally created to enable digital cash or micropayment systems. No standard usage convention was ever adopted, and different implementations have used it in different ways — until now.

L402 is a protocol developed by Lightning Labs that finally gives HTTP 402 its intended purpose. It combines Bitcoin's Lightning Network with macaroons (flexible bearer tokens for distributed systems) to create a standard for programmatic, identity-free payments for API access, digital resources, and machine-to-machine commerce. The protocol is open source and publicly specified on GitHub.

Why This Matters: AI Agents Need to TransactWhy This Matters: AI Agents Need to Transact

The trigger for L402's renewed relevance is the explosion of AI agents. Modern agents can write code, send emails, make phone calls, and orchestrate complex workflows — but they can't easily pay for things. Traditional payment rails (credit cards, bank accounts, identity-based processors) are fundamentally incompatible with how agents operate: they don't have government IDs, they need to transact instantly and programmatically, and they often deal in amounts so small that traditional fees would consume the entire payment.

On February 11, 2026, Lightning Labs announced a new set of open-source tools that give AI agents native access to the Lightning Network and the L402 protocol. The toolset includes client-side payment handling, server-side paywalls, remote key management, scoped credentials, and MCP (Model Context Protocol) integration for querying node state from AI assistants.

How L402 Works: A Step-by-Step OverviewHow L402 Works: A Step-by-Step Overview

Here's the basic flow of an L402 transaction, simplified for clarity:

Step 1 — The Request: A client (or AI agent) makes an HTTP request to a resource or API endpoint, just like any normal web request.

Step 2 — The 402 Challenge: The server responds with HTTP 402 Payment Required. Included in the response headers are two things: a Lightning invoice (a payment request with an amount and expiry) and a macaroon (a credential container that will serve as the access token once payment is proven).

Step 3 — Payment: The client pays the Lightning invoice. This happens over the Lightning Network and settles in seconds. Upon successful payment, the client receives a cryptographic proof of payment called a preimage.

Step 4 — Proof and Access: The client retries the original request, this time including the macaroon combined with the preimage as an authorization header. The server verifies the proof and grants access to the resource.

Step 5 — Reuse: The resulting credential can be cached and reused for subsequent requests to the same resource, so the client doesn't need to pay again until the credential expires.

No signup, no API key, no identity required at any point.

The Toolset: Key ComponentsThe Toolset: Key Components

lnget — The Client-Side Payment Handlerlnget — The Client-Side Payment Handler

lnget is a command-line HTTP client similar to wget or curl, but with built-in L402 awareness. When an agent runs lnget https://api.example.com/data.json and the server returns a 402, lnget automatically parses the challenge, pays the invoice through the configured Lightning backend, caches the resulting token, and retries the request — all transparently. It supports spending limits via --max-cost flags to keep agents on a budget.

Aperture — The Server-Side Reverse ProxyAperture — The Server-Side Reverse Proxy

Aperture is a reverse proxy that sits in front of any existing API, website, or web service. It handles the full L402 negotiation — issuing invoices, verifying payments, managing macaroons — so the backend doesn't need to know anything about Lightning. It supports dynamic pricing based on request complexity or resource consumption. If you want to put a pay-per-use paywall in front of your API, Aperture lets you do it without rewriting your backend.

Remote Signing — Key IsolationRemote Signing — Key Isolation

Lightning Labs promotes a remote signer architecture for security. The node that the agent operates is a watch-only node: it can route payments and interact with the network, but private keys are held on a separate signer machine that never connects to the public network. Even if an attacker compromises the agent's machine, the keys aren't there.

Scoped Macaroons — Least-Privilege CredentialsScoped Macaroons — Least-Privilege Credentials

Macaroons are bearer tokens (similar to API keys) that support fine-grained permission scoping. You can bake a credential that only allows paying invoices, or only allows creating invoices, or only allows reading node state — and you can further restrict it without issuing a new one. The toolset ships with preset roles: pay-only, invoice-only, read-only, channel-admin, and signer-only. This is essential for protecting funds when giving an AI agent access to a wallet.

Practical Example: The Full LoopPractical Example: The Full Loop

Here's what a complete agent commerce loop looks like:

1. Seller agent stands up a paid API endpoint using Aperture. Any request to the endpoint triggers a 402 challenge with a Lightning invoice.
2. Buyer agent discovers the API and makes a request using lnget.
3. lnget receives the 402 response, pays the Lightning invoice automatically, and retries with proof of payment.
4. The buyer agent gets the data. The seller agent gets paid. Lightning settles the payment in the background.

Both sides operate without accounts, without API keys, and without knowing anything about each other's identity.

Honest LimitationsHonest Limitations

Our friend stonychambers offers some grounded perspective on the current state of things that's worth sharing:

• Lightning is still complex under the hood. Channel management — opening channels, balancing liquidity, handling routing reliability — is outside the scope of these tools. lnget can pay, but it doesn't address the operational overhead of running a Lightning node. Future solutions will likely need to include features like submarine swaps, splicing, and possibly interoperability with e-cash systems and sidechains.
• Adoption is the real bottleneck. The usefulness of L402 depends entirely on distribution. Right now, virtually no APIs use HTTP 402 as intended. Until more services deploy Aperture on the server side and more agents integrate lnget on the client side, the ecosystem remains theoretical. The protocol is sound, but network effects are everything.
• Dynamic node management is unsolved. A production-grade autonomous agent that manages its own Lightning liquidity is a hard problem that this toolset doesn't yet address.

ResourcesResources

This article was compiled from official Lightning Labs documentation, their February 2026 launch announcement, the L402 protocol specification, and community analysis.