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 tokensthat embed payment proofs with capability constraints. Together, they form the L402 protocol — and it turns HTTP 402 from a placeholder into infrastructure.
HTTP 402 Payment Required Agent Implementation
The agent implementation path is compact: receive 402 Payment Required, parse the L402 challenge, check budget policy, pay if allowed, then retry with proof. That turns a previously reserved status code into a machine-readable API purchase flow.
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.
# Standard 402 response with L402 challenge
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. A human client would need custom UI to handle this. An AI agent processes it natively.
HTTP 402 Payment Required FAQ
What does HTTP 402 Payment Required mean?
HTTP 402 means the requested resource requires payment before access. In modern API use, that usually means the server returns a payment challenge instead of a normal response, and the client retries with proof of payment.
Why was HTTP 402 reserved for future use?
HTTP 402 was reserved because the web lacked a low-friction payment rail for tiny digital transactions. Credit cards were too expensive for micropayments, and browsers were designed around human checkout flows rather than machine-readable payment negotiation.
How is L402 different from ordinary HTTP 402?
HTTP 402 is the status code. L402 is the practical protocol pattern: HTTP 402 carries a Lightning invoice and macaroon capability token so delegated clients can present payment proof and access the API under explicit constraints.
How does an AI agent implement HTTP 402 Payment Required?
The agent receives a 402 challenge, checks whether policy allows the payment, pays the Lightning invoice, attaches the L402 credential or payment proof, and retries the request. The gateway should still enforce budgets so the agent cannot buy unlimited API calls.
When should an API return HTTP 402 instead of 401 or 403?
Return HTTP 402 when access is allowed after payment. Use 401 when authentication is missing, 403 when access is forbidden, and 402 when the resource is available but requires payment or proof of payment first.
Why 402 Stayed Dormant for Decades
HTTP 402 isn't a new idea — it's an idea that was waiting for its technology stack. Three barriers kept it dormant:
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. The web needed a payment system where sub-cent transactions made sense. Lightning Network, which settles payments in milliseconds for fractions of a cent in fees, solves this.
Barrier 2: No Machine-Readable Payment Protocol
Traditional payment flows require human interaction: enter card details, click confirm, handle 3D Secure. Machines can't fill out credit card forms. A machine-native payment protocol needs to be fully expressible in HTTP headers — request, pay, present proof, access resource. L402 provides exactly this protocol.
Barrier 3: No Autonomous Clients
Humans browse the web deliberately. They don't make thousands of API calls per minute or autonomously decide to purchase resources. There was no pressing need for a machine-readable payment status code because machines weren't buying things. AI agents changed that overnight.
Seven Real-World Use Cases for HTTP 402
With the barriers removed, 402 unlocks business models and integration patterns that weren't possible before. Here are the use cases driving adoption today.
1. Pay-Per-Call API Monetization
The pattern: Instead of monthly subscriptions or pre-purchased credit packs, APIs charge per call at the moment of use. No accounts, no invoices, no billing reconciliation.
How 402 enables it: An agent calls your API. Your gateway returns 402 with a Lightning invoice for $0.002. A delegated client presents payment proof, receives a macaroon proof, and replays the request with the proof attached. Total time: under 500 milliseconds. The API earned revenue without ever knowing who the caller was.
# Agent flow: automatic payment negotiation
1. GET /api/translate?text=hello&target=es
→ 402 Payment Required (invoice: 10 sats)
2. Delegated client presents Lightning payment proof (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. No signup forms, no API key management, no billing portals. The agent discovers the API, pays, and uses it — all within the HTTP protocol.
2. Premium Content Gating Without Accounts
The pattern: Premium content (research reports, data feeds, analysis) is accessible to anyone willing to pay, without requiring user registration.
How 402 enables it: A research agent scraping market data hits a premium endpoint. Instead of getting a login page (useless to a machine), it gets a 402 with a price and invoice. The agent evaluates whether the data is worth the cost based on its budget constraints, pays if it is, and moves on if not.
For publishers, this creates a new revenue stream from machine consumers who would never create accounts. For agents, it means access to premium data without human-mediated onboarding. The transaction is anonymous, instant, and provable.
3. Anti-Abuse Without Rate Limits
The pattern: Instead of blocking excessive usage with rate limits, price it. The 402 response makes abuse economically irrational rather than technically impossible.
How 402 enables it:Your free tier allows 100 calls per hour. Call 101 returns a 402 instead of a 429. Legitimate users pay the small fee and continue working. Scrapers and abusers hit a cost wall that scales with their abuse. A bot making 10,000 requests doesn't get blocked — it gets a $20 bill. That's a more effective deterrent than any IP blocklist.
Rate Limits vs Economic Limits
Rate limit (429):“You've made too many requests. Wait 60 seconds.”
→ Bot rotates IP, continues scraping for free.
Economic limit (402):“You've used your free tier. Each additional call costs $0.001.”
→ Bot must spend real money to continue. Abuse has a price.
4. Multi-Agent Budget Delegation
The pattern:A parent agent allocates budget to sub-agents, each of which can independently pay for API access within their allocation. The parent never shares credentials — it shares economic authority.
How 402 enables it:The parent agent pre-pays for a macaroon with a $50 budget. It attenuates that macaroon into sub-tokens: $20 for the research agent, $15 for the writing agent, $10 for the review agent, $5 reserve. Each sub-agent uses its token to pay for 402-gated APIs. When a sub-agent's budget runs out, it gets 402 responses with no valid payment path — a hard stop enforced by cryptography.
# Budget delegation chain
Parent Agent ($50 macaroon)
├── Research Agent ($20 sub-macaroon)
│ ├── Pays for search API calls via 402
│ └── Hits budget ceiling → 402 with no remaining balance
├── Writing Agent ($15 sub-macaroon)
│ └── Pays for LLM API calls via 402
└── Review Agent ($10 sub-macaroon)
└── Pays for fact-check API calls via 402
# Total spend can never exceed $50
# Each agent can never exceed its allocation
# No centralized budget tracking needed5. Instant API Marketplace Discovery
The pattern: Agents discover and consume APIs dynamically based on price, without pre-negotiated contracts. The 402 response serves as both a price list and a checkout flow.
How 402 enables it: An agent needs translation services. It queries three APIs. Each returns 402 with a price: API A charges 5 sats, API B charges 3 sats, API C charges 8 sats but includes quality guarantees in the macaroon caveats. The agent selects based on price-quality tradeoff, pays, and proceeds. No API directory, no contracts, no sales calls. The HTTP protocol is the marketplace.
This creates a competitive dynamic that benefits both providers and consumers. Providers set prices that reflect their costs and quality. Consumers choose based on real-time economics. The market clears at machine speed.
6. Proof-of-Work Spam Prevention
The pattern: Public endpoints (contact forms, submission APIs, webhook receivers) require a tiny payment to process. The payment is too small for legitimate users to notice but too expensive for spammers to sustain at scale.
How 402 enables it:Your API receives form submissions. Each submission requires a 1-sat payment (roughly $0.001). A real user's delegated client presents proof within policy. A spammer sending 100,000 submissions faces a $100 bill. The economics filter spam more effectively than CAPTCHAs, and they work for machine clients that can't solve CAPTCHAs anyway.
This is Hashcash for the agent economy, but with real economic cost instead of computational work. The payment proves commitment without wasting energy.
7. SaaS Usage-Based Billing at the Request Level
The pattern:SaaS platforms charge for actual usage at request granularity instead of seat-based or tier-based pricing. No surprise invoices, no overage charges — you pay exactly for what you consume.
How 402 enables it:An enterprise deploys AI agents that consume a data enrichment SaaS. Each API call returns 402 with the exact cost for that specific operation (simple lookups cost less than complex enrichments). The enterprise's gateway pays automatically from a pre-funded wallet, deducting per-request costs in real time. The CFO sees spend accumulate live, not on a monthly invoice 30 days later.
For SaaS providers, this means revenue recognition at the moment of delivery. For enterprises, it means cost visibility and control at a granularity that monthly billing can't match.
The L402 Protocol: Making 402 Practical
HTTP 402 on its own is just a status code. The L402 protocol makes it actionable by combining three technologies:
Lightning Network provides the payment rail. Invoices are generated per-request, payments settle in milliseconds, and fees are negligible. This is what makes sub-cent API transactions economically viable.
Macaroon tokens provide the capability proof. After payment, the client receives a macaroon that encodes what they paid for, how long access lasts, and what constraints apply. The macaroon is the receipt, the access token, and the capability boundary all in one cryptographic package.
HTTP semantics provide the transport. The 402 response, the WWW-Authenticate header, and the Authorization header are all standard HTTP. No custom protocols, no WebSocket upgrades, no out-of-band communication. Every proxy, load balancer, and CDN in the chain can handle L402 traffic without modification.
# Complete L402 flow
┌──────────┐ ┌──────────────┐
│ Agent │ GET /resource │ API + │
│ │───────────────────▶│ Gateway │
│ │ │ │
│ │ 402 + invoice │ │
│ │◀───────────────────│ │
│ │ │ │
│ │ Pay invoice ──────────▶ Lightning│
│ │ ◀── preimage ─────────── Network │
│ │ │ │
│ │ GET /resource │ │
│ │ Auth: L402 token │ │
│ │───────────────────▶│ ✓ Verify │
│ │ │ ✓ Grant │
│ │ 200 OK + data │ │
│ │◀───────────────────│ │
└──────────┘ └──────────────┘Implementation Considerations
If you're considering 402 for your API, here are the practical questions to resolve:
Pricing Strategy
Not every endpoint should return 402. Separate your API surface into free (discovery, health checks, documentation), metered (standard operations where usage correlates with cost), and premium (expensive operations like ML inference or batch processing). Start with metered endpoints and expand based on usage data.
Client Compatibility
Existing HTTP clients handle 402 as an error by default. AI agent frameworks are adding native L402 support, but you'll need to support both 402-aware and traditional clients during the transition. The simplest approach: accept both API keys (traditional) and L402 tokens (agent-native) on the same endpoints. Return 402 only to clients that signal L402 support via an Accept-Payment header or lack traditional credentials.
Lightning Integration
You need a Lightning node or a hosted Lightning service to generate invoices and verify payments. Solutions range from running your own LND/CLN node (full control, operational overhead) to using hosted services like Voltage or LNBits (less control, zero ops). For most API providers, a hosted solution is the right starting point.
Gateway Architecture
Deploy 402 logic at the gateway layer, not in your application. The gateway handles invoice generation, payment verification, macaroon minting, and budget tracking. Your API backend never touches payment logic — it just serves requests that the gateway has already authorized.
402 in the Wild: Early Adopters
L402-based 402 implementations are appearing across the API ecosystem:
- AI inference APIs charging per-token with instant settlement instead of monthly billing cycles
- Data providers selling real-time market data to trading agents at per-query prices
- Developer tools offering premium features (code analysis, security scanning) on a pay-per-use basis
- Content platforms monetizing API access to articles, research, and datasets without subscription walls
- IoT networks where devices pay for cloud processing at the request level
The pattern is consistent: wherever monthly subscriptions create friction for machine consumers, 402 with L402 provides a smoother alternative. Agents don't want to manage subscriptions. They want to pay for what they use, when they use it.
The Future: 402 as a Paid Rail Under Authority
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 increasingly sophisticated payment strategies: comparing prices across providers, pre-funding budgets for anticipated workflows, and negotiating bulk rates through macaroon caveats.
The enterprise end state is not agents spending freely. Humans and platforms set budgets, constraints, and policies; agents execute inside those boundaries; the payment rail carries value only after authority has been checked.
HTTP 402 was reserved for future use in 1997. For agent systems, the useful version is narrower: 402 is paid-rail context around an authority decision, with policy checked before value moves and Evidence Packs available after the call.
Model paid-agent pricing before enabling 402
HTTP 402 gets powerful when pricing, margin, free allowances, and L402 settlement are explicit before agents call the API.
SatGate path: Observe → Control → Prove
Start by observing paid-agent and API usage. Move to Control when budgets, scopes, and payment authority need to stop bad calls before value moves. Preserve Evidence Packs so each paid-rail decision can be verified later.
Govern 402 payments before value moves
SatGate treats HTTP 402 and L402 as paid rails around authority decisions. Deploy it in front of APIs to enforce scope, budget, and payment policy before execution, then preserve Evidence Packs for later verification.