x402 vs L402
x402 and L402 both use the HTTP 402 status code to let a server demand payment for a request. x402 settles with stablecoin transfers on an EVM chain and returns proof of payment. L402 settles over the Lightning Network and issues a macaroon credential bound to a paid invoice, which the client presents on later requests.
The shared idea
HTTP defined a status code for payment required and left it unused for most of the web's life, because there was no payment method a server could demand from an arbitrary client without a prior relationship. Both schemes revive it on the observation that machine clients change this: a program holding funds can settle a payment mid-request without a human entering card details.
The shape is therefore the same in both. A client requests a resource. The server responds with 402 and the terms. The client pays and retries with evidence. The server validates and serves.
What differs is everything below that: what settles the payment, what the evidence is, and what infrastructure each side has to run. Those differences decide which one is practical for a given service, and they are not really about the protocol at all.
Why the credential model is the deeper difference
x402 is oriented around proving a specific payment for a specific request, which fits metered per-call access cleanly. L402's macaroon is a bearer credential that can encode caveats such as expiry or usage limits, so a single payment can purchase an entitlement the client presents repeatedly. That makes L402 naturally suited to purchasing access rather than purchasing one call. The distinction matters more than the settlement network for anyone designing pricing, because it determines whether your unit of sale is a request or a period of access.
What each demands operationally
Running a Lightning node is real work. Accepting L402 means operating a node, managing channels, and maintaining inbound liquidity so you can receive. Liquidity management is an ongoing operational task rather than a setup step, and it fails in ways that are unfamiliar to teams that have only run web services.
Stablecoin settlement needs chain access and funded clients. Accepting x402-style payments means being able to verify transfers on the chain and having an address to receive at. The client needs a funded account and gas. On a low-fee network that is cheap; on an expensive one, per-call payments stop making sense entirely, which is why the choice of chain matters as much as the choice of scheme.
Volatility is a pricing question. A stablecoin price is denominated in a unit your accounting already understands. A Bitcoin-denominated price moves, so either the price is quoted dynamically or the merchant carries exposure.
Finality differs in character. Lightning payments settle within the network almost immediately. Onchain transfers wait for confirmation, which on a fast network is brief but not instantaneous, and a server deciding how many confirmations to require is making a latency against risk trade.
Very small amounts favour Lightning. Sub-cent pricing is native there. Onchain the floor is set by fees and token decimals.
Client reach is the decisive practical factor. The scheme your callers can actually pay with wins, regardless of elegance. For agents built around stablecoin balances, a stablecoin rail is one integration; Lightning is a new subsystem.
Choosing between them
Start from what your clients hold. If your callers are agents with stablecoin funding, x402-style settlement is the shorter path and the one that does not ask them to acquire a new asset class. If your callers already operate Lightning infrastructure, the reverse is true.
Match the credential model to your pricing. Selling individual calls suits per-payment proof. Selling access for a period or a quota suits a credential that carries the entitlement, and building period-based access on a per-payment scheme means implementing that state yourself.
Count the operational surface honestly. A Lightning node is a stateful system with liquidity that requires attention. Chain access is a dependency on a node or provider with its own reliability characteristics. Neither is free; they are unfamiliar in different directions.
Do not let novelty decide. Both are unusual enough that adopting either means your clients need documentation and examples. The scheme with fewer moving parts for your specific callers is worth more than the one with better properties in the abstract.
Supporting both is possible and rarely worth it early. The 402 flow is a thin layer over whichever settlement you use, so a server can offer multiple options. Doubling the surface to operate is reasonable once demand for both is demonstrated.
| Dimension | x402 | L402 |
|---|---|---|
| Settlement | Stablecoin transfer on an EVM chain | Lightning Network payment |
| Typical asset | USDC | Bitcoin, denominated in satoshis |
| What the client presents | Proof of a payment for the request | A macaroon credential plus payment preimage |
| Credential reuse | Per payment by default | Credential can carry ongoing entitlement |
| Server must operate | Chain access and payment verification | A Lightning node with inbound liquidity |
| Client prerequisites | Funded account and gas | Lightning wallet with outbound liquidity |
| Settlement finality | Chain confirmation | Near instant within the network |
| Amount granularity | Limited by token decimals and fees | Very small amounts are native |
Frequently asked questions
- What is the difference between x402 and L402?
- Both use the HTTP 402 status code to demand payment during a request. x402 settles with stablecoin transfers on an EVM chain and the client proves a specific payment. L402 settles over the Lightning Network and issues a macaroon credential bound to a paid invoice that the client presents afterwards.
- Which is better for very small payments?
- L402, because Lightning handles sub-cent amounts natively. Onchain settlement has a practical floor set by transaction fees and token decimals, and a payment worth less than the fee to send it does not make sense, although a low-fee network moves that floor down considerably.
- What does a server need to run for each?
- For L402, a Lightning node with managed channels and inbound liquidity, which is an ongoing operational responsibility. For x402-style settlement, access to the chain to verify transfers and an address to receive at, which is a lighter operational footprint but a dependency on node access.
- Can a service support both schemes?
- Yes. The 402 flow is a thin layer over whichever settlement mechanism sits beneath it, so a server can offer more than one and let clients choose. It doubles the surface to operate and test, so it is usually worth doing only once demand for both is actually demonstrated.
- Does L402 require Bitcoin exposure?
- Payments are denominated in satoshis, so a merchant either quotes prices dynamically against a reference rate or carries exposure to the price between receiving and converting. Stablecoin settlement avoids that by denominating in a unit that accounting already treats as stable.