Both x402 and L402 reuse the long-dormant HTTP 402 status code to make payment a first-class part of an HTTP request. The difference is the settlement substrate: x402 rides EVM stablecoins (USDC on Base by default) and EIP-3009 transfer authorisations; L402 rides Bitcoin Lightning invoices and macaroons. Picking between them is mostly a settlement-rail decision.
Pick x402 when you want stable USD pricing, EVM tooling, and on-chain audit per call. Pick L402 when your stack already runs Lightning and you want sub-second BTC settlement with built-in macaroon auth.
x402 treats the payer's wallet signature as the identity — the EIP-712 typed-data signature over an EIP-3009 transferWithAuthorization is both the payment and the auth header. L402 issues a macaroon plus a Lightning invoice; the client pays the invoice, then attaches the macaroon as the auth token on subsequent requests.
x402 servers either settle directly with an EVM RPC or delegate to a facilitator (Coinbase CDP is the reference). L402 servers settle by detecting paid Lightning invoices, typically against an LND or Core Lightning node.
USDC pricing is naturally USD-stable. L402 prices are typically expressed in satoshis, which makes ad-hoc agent budgets harder to reason about across long-running workflows unless the price is denominated and re-quoted in fiat by the server.
x402 has client SDKs in Python and TypeScript, a Coinbase facilitator, and discovery via .well-known/x402.json. L402 has aperture (proxy), lightning-charge-style flows, and is most mature inside Lightning-native stacks.