L402 vs x402 vs API keys for agent payments
L402 and x402 both use HTTP 402 Payment Required so an agent can pay per request without an account; L402 settles in bitcoin over Lightning with a macaroon credential, and x402 usually settles in dollar stablecoins through a facilitator. API keys need a signup first, which agents can't usually do alone, but they remain the right tool for known customers on contracts. Many sellers will run more than one. This page compares them for API owners.
Part of How to sell your API to AI agents. The buyer-side comparison, including card-network agent programs, is in Agentic payments explained.
At a glance
| L402 | x402 | API keys | |
|---|---|---|---|
| Who's behind it | Lightning Labs (spec) | Created by Coinbase; now run by the x402 Foundation at the Linux Foundation (LF) | Every API provider, in its own way |
| Money | Bitcoin over Lightning, priced in sats | Mostly dollar stablecoins such as USDC; the SDKs support many networks (x402 SDK features) | Whatever your billing system takes |
| Challenge | 402 + WWW-Authenticate: L402 macaroon="...", invoice="..." | 402 + PAYMENT-REQUIRED header (base64 JSON) (x402 HTTP transport) | None; the client must already have a key |
| Proof of payment | Authorization: L402 <macaroon>:<preimage> | PAYMENT-SIGNATURE header with a signed payload; settlement result in PAYMENT-RESPONSE | The key itself; billing happens later |
| How you verify | sha256(preimage) matches the hash in the macaroon; stateless, no lookup | A facilitator verifies and settles, or you host that role yourself (x402 spec) | Look up the key in your database |
| Buyer needs | A Lightning wallet | A funded wallet on a supported network | An account, a key, and a payment method on file |
| Seller needs | A way to issue Lightning invoices | A receiving address and a facilitator | Signup, key management, billing, collections |
| Good for | Small per-call payments, settled in seconds, with tokens you can restrict by caveat | Dollar-priced per-call payments with broad industry backing | Known customers, contracts, volume discounts, enterprise procurement |
| Trade-offs | Buyers need Lightning; sats move with the BTC price | Depends on chain and facilitator choice | Agents can't self-onboard; you carry fraud and collections |
L402, briefly
The server answers an unpaid request with a macaroon and a Lightning invoice. The client pays, keeps the preimage, and retries with both. Because the macaroon commits to the payment hash, the server verifies the payment with one hash check and no database (L402 spec). Macaroon caveats can limit a token by time, service, or capability. Full explainer: Monetize an API with Lightning.
x402, briefly
x402 version 2 defines payment requirements, a signed payment payload, and a settlement response. Over HTTP, the server sends PAYMENT-REQUIRED, the client answers with PAYMENT-SIGNATURE, and the server returns PAYMENT-RESPONSE. A facilitator verifies and settles on the chain; schemes such as exact define how each payment works, and networks are named in CAIP-2 format (x402 spec v2). The spec also defines transports for MCP and A2A, not just HTTP.
API keys, fairly
API keys are not going away. They're the simplest way to serve customers you know, they work with every HTTP client, and they suit monthly plans, contracts, and volume discounts. What they don't do is let a new agent buy one call on the spot: someone has to sign up, verify, add a card, and store a key. If you want agents as walk-in customers, add a 402 path next to your keys.
Other HTTP 402 schemes
The IETF draft "Payment" HTTP authentication scheme (draft-httpauth-payment) is another approach; Lightning Labs' Aperture can offer it alongside L402 in the same 402 response (Aperture). Amboss publishes a Lightning SDK for that family of specs (lightning-mpp-sdk). The Amazap seller flow is built for L402.
Which should you pick?
- You want agents as customers and you're fine pricing in sats: L402. It's what Amazap buys, so an L402 endpoint can be listed on Amazap through /sell.
- Your buyers already hold dollar stablecoins: x402 is a reasonable choice, and the two can coexist on the same API.
- Your customers are companies on contracts: keep API keys, and add a 402 path for agents.
Where Amazap fits
Amazap (amazap.com) lists about 1,400 L402 and x402 services. Agents buy L402 listings and Lightning-payable x402 listings in sats from one balance through the Amazap MCP server; stablecoin-only x402 listings are shown but can't be bought there yet. For sellers, that means an L402 endpoint reaches every agent on Amazap without each one needing its own Lightning setup.
Ready to add L402? Start with payments:
Disclosure: Amazap is an Amboss referral partner. Amazap earns a referral credit if you sign up through this link.
Then use the starter kit and list your endpoint.
FAQ
What is the difference between L402 and x402?
Both use HTTP 402 so a client can pay per request without an account. L402 uses a Lightning invoice and a macaroon, settles in bitcoin, and verifies payment with a stateless hash check. x402 uses a signed payment payload, usually in dollar stablecoins, verified and settled by a facilitator.
Is x402 better than L402 for AI agents?
Neither is better everywhere. x402 suits dollar-priced payments and has broad industry backing. L402 suits small per-call payments in sats with stateless verification. You can support both.
Can I keep my API keys and still sell to agents?
Yes. Keep keys for known customers and add an L402 or x402 path for agents that want to pay per call without signing up.
Who maintains x402 and L402?
L402 is specified by Lightning Labs. x402 was created by Coinbase and is now run by the x402 Foundation at the Linux Foundation.
Which protocol does Amazap use?
Amazap buys over L402, plus x402 services that can be paid over Lightning. Its seller flow lists L402 endpoints.