x402 vs L402: Two Ways to Pay Over HTTP 402

x402 and L402 are both protocols that turn HTTP's long-dormant 402 Payment Required status code into a real payment flow, but they settle value on different rails: x402 settles stablecoin payments onchain (initially USDC on Base), while L402 pairs an HTTP challenge with a Bitcoin Lightning Network invoice and a macaroon-based access token. x402 is built for the world of onchain stablecoins and AI agents holding wallets; L402 is built for the world of Bitcoin and Lightning micropayments.

Key takeaways

• Same trigger, different rails. Both use HTTP 402 to say "pay to proceed." x402 asks for an onchain stablecoin transfer; L402 asks for a Lightning payment and issues a macaroon token in return.
• x402 leans on stablecoins and EVM chains. The reference implementation from Coinbase settles in USDC on Base, with a facilitator that verifies and settles the transfer.
• L402 leans on Bitcoin and Lightning. Originating from Lightning Labs (first as LSAT), it binds a paid Lightning invoice to an authenticated, attenuable access credential.
• The token model differs. L402 hands back a reusable macaroon that can carry caveats and be re-presented; x402's flow is settlement-centric and does not standardize a long-lived credential in the same way.
• Agent fit drives the choice. If your agent already holds a stablecoin wallet on an EVM chain, x402 is the shorter path. If your stack is Bitcoin-native, L402 fits without adding a new asset.

What each protocol does when a client hits 402

The two protocols share a shape. A client requests a resource, the server responds with 402 Payment Required plus payment instructions, the client pays, and the client re-requests with proof. The divergence is in what "pay" and "proof" mean.

Under x402, the 402 response carries the details needed to construct an onchain payment (recipient, amount, asset, network). The client signs and submits a stablecoin transfer, a facilitator verifies and settles it, and the client retries the request with a payment header the server can check. Coinbase's launch materials describe the initial implementation settling in USDC on Base. For a fuller walkthrough of the flow and its intended use in agent commerce, read our breakdown of the x402 payments standard for APIs, data, and agents.

Under L402 (documented by Lightning Labs, and originally introduced as LSAT), the 402 response returns a Lightning invoice together with a macaroon. The client pays the invoice over the Lightning Network, obtains the payment preimage as cryptographic proof, and re-presents the macaroon plus preimage in an Authorization header. The server validates the pair and grants access. The macaroon can carry caveats, meaning the same credential can be constrained (for example, limited to a specific endpoint or expiry) without a new round trip to the server.

The core difference: settlement rail and credential model

Two axes explain almost every downstream difference between x402 and L402.

The credential difference is the one most people miss. L402's macaroon is a bearer token that can be attenuated and re-presented, which suits a model where a client buys access to a resource and returns to it. x402 centers on settling a payment for a request, which suits pay-per-call metering where the settlement itself is the authorization event.

A worked example: charging $0.05 per API call

Suppose you meter an API at five cents per call and expect an AI agent to make 1,000 calls. The user experience differs by rail.

The dollar total is the same by design in this example, because we priced both at five cents. The operational difference is what the agent must hold and how pricing stays stable. A stablecoin quote in x402 does not drift with crypto markets. A sat-denominated quote in L402 is pinned to Bitcoin unless the server re-quotes in fiat terms and converts. Each reflects the asset the protocol assumes.

When to reach for which

Choose x402 when your service or your agents already live on EVM stablecoins, when you want dollar-stable pricing without a conversion layer, and when settlement-as-authorization fits your metering. Its reference implementation on Base is aimed at agent-to-service commerce where a wallet is already present.

Choose L402 when your stack is Bitcoin-native, when you want the smallest possible per-call value transferred over Lightning, or when you specifically want a reusable, attenuable access token as the thing you sell. The macaroon model gives you fine-grained, offline-verifiable access control that a payment header does not.

They are not mutually exclusive. A service can expose both, letting a client pick the rail it is provisioned for. Both revive the same HTTP primitive, so the client logic (get 402, pay, retry) rhymes across them.

The measurement problem underneath both

Once agents start paying per request, someone has to answer basic questions across rails: how many payments settled, for how much, to whom, and denominated in what. An x402 payment is an onchain stablecoin transfer that, on its own, looks like any other transfer. An L402 payment is a Lightning event that never touches the base chain in a way a naive block scan would capture. To compare activity across these worlds, each payment has to resolve to the same fields: asset, issuer, sender, recipient, amount, USD value, and transaction type, so that a stablecoin settlement on one chain and a stablecoin settlement on another are counted the same way. Allium normalizes stablecoin and transfer records across blockchains into consistent schemas, which lets a payments team measuring machine-driven flows treat an x402 settlement on Base as directly comparable to the same asset moving elsewhere.

Both protocols are young and evolving. Treat rail choices, supported assets, and facilitator behavior as things to verify against the projects' own documentation before you build.

Frequently asked questions

Is x402 based on L402?

No. They independently revive the HTTP 402 status code but come from different origins and settle on different rails. x402 originates from Coinbase and settles onchain stablecoin transfers (USDC on Base at launch). L402 comes from Lightning Labs (originally introduced as LSAT) and settles Bitcoin Lightning payments paired with a macaroon access token.

What is a macaroon in L402?

A macaroon is a bearer credential that can carry caveats, which are constraints such as an expiry or a specific endpoint. In L402, the server issues a macaroon alongside a Lightning invoice; once the client pays and obtains the preimage, it presents both to gain access. Because macaroons can be attenuated, they support fine-grained, offline-verifiable access control.

Does x402 require stablecoins?

x402 is designed around onchain payments, and its reference implementation settles in USDC on Base. The protocol pattern could in principle support other onchain assets, but the launch materials center on stablecoin settlement because dollar-denominated pricing stays stable for machine commerce. Check the x402 documentation for the current list of supported assets and networks.

Which is better for AI agent payments?

It depends on what the agent already holds. If the agent has a stablecoin wallet on an EVM chain, x402 is the shorter path and gives dollar-stable pricing. If the stack is Bitcoin-native, L402 avoids adding a new asset and offers a reusable access token. Many services can support both so clients pick the rail they are provisioned for.

Do x402 and L402 charge protocol fees?

The protocols themselves define the payment flow rather than a fixed fee. Real costs come from the underlying rail: onchain gas and any facilitator arrangements for x402, and Lightning routing fees for L402. Because these depend on network conditions and implementation choices, verify current costs against the projects' own documentation rather than assuming a fixed rate.

Can a single API support both x402 and L402?

Yes. Both return an HTTP 402 with payment instructions and expect the client to retry after paying, so a server can offer both and let the client choose based on the asset and rail it supports. The client-side logic (receive 402, pay, retry with proof) is similar across the two, even though the settlement mechanics differ.

Interested in learning more about Allium’s stablecoin data? Speak to someone on the team.

Allium provides onchain data infrastructure. Companies named in this article may be Allium customers, prospects or commercial counterparties. This article is informational only and is not investment, legal or tax advice. Data and information last reviewed: September 23, 2026.