Every web developer knows 200 OK, 404 Not Found, and 401 Unauthorized. But there's a status code that has been sitting in the HTTP specification since 1997, doing essentially nothing: 402 Payment Required.
The original HTTP/1.1 spec (RFC 2068) defined 402 as "reserved for future use." The authors knew that the web would eventually need a native way to say "this resource costs money — pay first, then access." They just didn't know how digital payments would work yet. Credit cards weren't built for sub-cent transactions. PayPal didn't exist. Bitcoin was a decade away.
Twenty-nine years later, three things have converged to make 402 not just useful, but essential: AI agents that consume APIs autonomously, Lightning Network micropayments that settle in milliseconds, and macaroon tokens that embed payment proofs with capability constraints. Together, they form the L402 protocol — and it turns HTTP 402 from a placeholder into infrastructure.
What HTTP 402 Actually Means
HTTP status codes communicate between client and server in a language both understand. 401 means "authenticate yourself." 403 means "you don't have permission." 402 means something subtly different: "you can have this, but it costs money."
That distinction matters. A 401 tells the client to present credentials. A 402 tells the client to present payment. The resource isn't forbidden — it's for sale. This is a fundamentally different relationship between client and server, and it enables business models that 401/403 can't express.
HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 macaroon="base64-macaroon", invoice="lnbc10n1..."
Content-Type: application/json
{
"error": "payment_required",
"amount_sats": 10,
"description": "Translation API: 1 call",
"expires": "2026-04-02T22:00:00Z"
}
The response includes everything a client needs to complete payment: a macaroon (the capability token that will grant access after payment), a Lightning invoice (the payment mechanism), and metadata about what's being purchased.
Why 402 Stayed Dormant for Decades
HTTP 402 isn't a new idea — it's an idea that was waiting for its technology stack.
Barrier 1: No Micropayment Infrastructure
Credit card transactions cost $0.30 + 2.9% minimum. Paying $0.001 for an API call through Stripe is economically absurd — the processing fee is 300x the transaction value. Lightning Network settles payments in milliseconds for fractions of a cent in fees.
Barrier 2: No Machine-Readable Payment Protocol
Traditional payment flows require human interaction: enter card details, click confirm, handle 3D Secure. L402 is fully expressible in HTTP headers — request, pay, present proof, access resource.
Barrier 3: No Autonomous Clients
Humans don't make thousands of API calls per minute or autonomously decide to purchase resources. AI agents changed that overnight.
Seven Real-World Use Cases for HTTP 402
1. Pay-Per-Call API Monetization
The pattern: APIs charge per call at the moment of use. No accounts, no invoices, no billing reconciliation.
An agent calls your API. Your gateway returns 402 with a Lightning invoice for $0.002. The agent pays, receives a macaroon proof, and replays the request. Total time: under 500 milliseconds.
1. GET /api/translate?text=hello&target=es
→ 402 Payment Required (invoice: 10 sats)
2. Agent pays Lightning invoice (200ms)
→ Receives payment preimage
3. GET /api/translate?text=hello&target=es
Authorization: L402 <macaroon>:<preimage>
→ 200 OK {"translation": "hola"}
This eliminates the entire API onboarding funnel.
2. Premium Content Gating Without Accounts
A research agent hitting a premium endpoint gets a 402 with a price and invoice — not a login page. It evaluates cost vs. budget, pays if worthwhile, moves on if not. Publishers get revenue from machine consumers who would never create accounts.
3. Anti-Abuse Without Rate Limits
Instead of blocking excessive usage with rate limits, price it. Call 101 past the free tier returns 402 instead of 429.
Rate limit (429): "Wait 60 seconds." → Bot rotates IP, continues for free.
Economic limit (402): "Each additional call costs $0.001." → Bot must spend real money.
4. Multi-Agent Budget Delegation
A parent agent attenuates its macaroon into sub-tokens with specific budgets for each sub-agent. When a sub-agent's budget runs out, it gets 402 with no valid payment path — a hard stop enforced by cryptography.
Parent Agent ($50 macaroon)
├── Research Agent ($20 sub-macaroon)
├── Writing Agent ($15 sub-macaroon)
└── Review Agent ($10 sub-macaroon)
5. Instant API Marketplace Discovery
Agents query multiple APIs, each returns 402 with a price. The agent selects based on price-quality tradeoff, pays, and proceeds. The HTTP protocol is the marketplace.
6. Proof-of-Work Spam Prevention
Public endpoints require a 1-sat payment (~$0.001) to process. Legitimate agents pay without thinking. A spammer sending 100,000 submissions faces a $100 bill. Hashcash for the agent economy.
7. SaaS Usage-Based Billing at the Request Level
Each API call returns 402 with the exact cost for that specific operation. The enterprise's gateway pays from a pre-funded wallet. The CFO sees spend accumulate live, not on a monthly invoice.
The L402 Protocol: Making 402 Practical
HTTP 402 on its own is just a status code. L402 makes it actionable:
- Lightning Network provides the payment rail (millisecond settlement, negligible fees)
- Macaroon tokens provide the capability proof (what you paid for, how long, what constraints)
- HTTP semantics provide the transport (standard headers, no custom protocols)
┌──────────┐ ┌──────────────┐
│ Agent │ GET /resource │ API + │
│ │───────────────────▶│ Gateway │
│ │ 402 + invoice │ │
│ │◀───────────────────│ │
│ │ Pay invoice ──────────▶ Lightning│
│ │ ◀── preimage ─────────── Network │
│ │ GET /resource │ │
│ │ Auth: L402 token │ │
│ │───────────────────▶│ ✓ Verify │
│ │ 200 OK + data │ │
│ │◀───────────────────│ │
└──────────┘ └──────────────┘
Implementation Considerations
Pricing Strategy: Not every endpoint should return 402. Separate into free (discovery), metered (standard ops), and premium (expensive ops). Start with metered.
Client Compatibility: Support both API keys and L402 tokens on the same endpoints. Return 402 only to clients signaling L402 support.
Gateway Architecture: Deploy 402 logic at the gateway layer, not in your application. Your API backend never touches payment logic.
The Future: 402 as Default Commerce Layer
HTTP 402 is evolving from a curiosity into a fundamental building block of the agent economy. As more APIs expose 402 endpoints, agents will develop sophisticated payment strategies: comparing prices, pre-funding budgets, and negotiating bulk rates through macaroon caveats.
The end state is an internet where machines discover, evaluate, purchase, and consume digital services — within budgets and policies set by humans, executed at machine speed.
HTTP 402 was reserved for future use in 1997. The future is here.
SatGate is an economic gateway that adds L402 payment support, budget enforcement, and macaroon authentication to any API. View on GitHub or read the L402 Protocol Explained.
Top comments (1)
This was a genuinely interesting read because it treats 402 as more than a forgotten status code trivia fact. It reframes it as a trust and coordination primitive for machine to machine commerce, which is where the conversation actually gets interesting.
What landed for me most is the shift from access control to economic control. A 401 says prove who you are. A 402 says prove you paid. That is a very different contract, and in an agent driven environment it probably makes more sense than pretending every interaction should begin with accounts, dashboards, and billing relationships built for humans.
I also appreciate that this does not frame the idea as magic. The value is not just in reviving an old status code. It is in making payment legible to software in a way that can sit inside an actual request flow. That is the part that matters.
That said, this is also where the hard questions start. The protocol story is elegant, but real adoption will live or die on implementation friction, client support, pricing sanity, and whether teams actually want payment logic this close to the edge of their systems. A lot of good ideas die in that gap.
Still, strong piece. It pushes the conversation past vague agent economy hype and into a much more concrete question: what does native, machine readable payment on the web actually look like when you stop hand waving and try to operationalize it.