HTTP 402 "Payment Required" has existed since 1997. L402 combines it with Bitcoin Lightning for micropayments. Both solve for AI agents paying APIs—not humans controlling spending. This distinction matters for anyone building AI payment systems.
What HTTP 402 Was Supposed to Be
HTTP 402 is an official status code reserved for future payment systems. When a server returns 402, it means: "This resource requires payment to access."
The original vision: browsers and servers would have a standardized way to signal "payment needed" and automatically handle payment flows.
What happened instead: The spec defined the status code but not how to pay. Should you send credit card data in headers? Redirect to a payment page? Use a digital wallet? Nobody knew. And in 1997, the infrastructure didn't exist anyway—no PayPal (founded 1998), no Stripe (founded 2010), and transaction fees made micropayments impossible.
Developers used 403 Forbidden or built custom paywall systems instead. HTTP 402 became a historical curiosity.
L402: Lightning Network Meets HTTP 402
In 2023, Lightning Labs proposed L402: combine HTTP 402 with Bitcoin's Lightning Network to finally enable micropayments.
The flow: Request a protected resource → receive a 402 with a Lightning invoice → pay the invoice (seconds, near-zero fees) → receive cryptographic proof of payment → retry the request with that proof → access granted.
What L402 gets right:
- True micropayments — Lightning enables fractions of a cent with minimal fees
- No accounts required — Pay invoice, get access. No registration.
- Cryptographically secure — Can't fake payment; proof is mathematical
- Machine-to-machine ready — Agent has wallet, sees 402, pays automatically, continues
For AI agents paying APIs autonomously, this is elegant.
The Problem: Agents vs. Humans
L402 assumes the payer is an agent with a wallet and spending logic built in. For humans using AI applications, the experience looks different.
Wallet connection friction: Users must have a Lightning wallet installed, connect it to the application, authorize spending, and manage their balance. Most users won't connect their Bitcoin wallet to an AI writing assistant and let it auto-pay per request.
No spending controls: L402 is binary—pay or don't pay. Users need budget limits ("don't spend more than $50 this month"), approval thresholds (auto-approve small charges, require confirmation for large ones), and alerts at spending milestones. L402 has none of this.
Refunds are impossible: Lightning Network payments are final. For agent-to-agent payments, this is fine. For humans paying for AI output that turns out to be low quality? No mechanism exists for recourse. You can't build consumer trust on irreversible micropayments.
Crypto dependency: L402 requires Bitcoin and Lightning Network. This means technical barriers (users must understand and hold Bitcoin), regulatory complexity (varies by jurisdiction), and for most AI companies, "just use Bitcoin Lightning" is a non-starter.
What AI Payment Systems Actually Need
The gap between L402 and real user needs suggests what should exist instead:
| L402 Approach | What Users Need |
|---|---|
| Pay, then see result | Estimate before execution |
| Binary pay/don't | Tiered approvals with budget limits |
| Payment is final | Refund mechanisms for poor quality |
| Bitcoin Lightning only | Credit cards, wallets, bank accounts |
| Pure pay-per-request | Subscription + usage hybrid |
Estimation before execution: Users need quotes, not surprise charges. Describe the task, see an estimated cost range, approve, then execute.
Approval workflows: Small charges auto-approve with notification. Medium charges require explicit approval. Large charges require password or 2FA. Budget overages require explicit authorization.
Quality gates: Pay for delivered value. Accept output, charge confirmed. Reject output, partial or full refund. Dispute triggers manual review.
Standard payment methods: Support familiar rails—Stripe for credit cards, Apple Pay, Google Pay, ACH, subscription billing. Crypto optional for those who want it.
This is product architecture, not an HTTP status code.
See how Bear Lumen approaches AI payment infrastructure →
Comparison: 402 vs. L402 vs. What's Needed
| Feature | HTTP 402 | L402 (Lightning) | What Users Need |
|---|---|---|---|
| Payment method | Undefined | Bitcoin only | Cards, wallets, banks |
| Micropayments | No (fees) | Yes | Not the goal |
| Quotes | No | No | Yes |
| Approval flow | No | Binary | Tiered |
| Refunds | Undefined | Impossible | Essential |
| Budget controls | No | No | Critical |
| Crypto required | No | Yes | Optional |
Where Each Approach Fits
HTTP 402 will remain niche—technically interesting but solving problems most developers don't have.
L402 will thrive in specific domains: agent-to-agent payments, crypto-native applications, censorship-resistant systems, and micropayment experiments. Projects like Fewsats are building in this direction.
For mainstream AI applications, standard payment infrastructure wins: Stripe-style APIs, subscription + usage hybrids, familiar payment UX, and the ability to issue refunds.
The real innovation isn't the status code. It's the product architecture around honest estimation, user control, quality gates, and fair refunds.
Learn More
- Why AI Pricing Should Work Like Uber — Plan-based pricing for AI
- Why Every AI Payment System Gets User Experience Wrong — The UX problems in current approaches
- Join early access — Be among the first to use plan-based AI pricing