HTTP 402 Payment Required: The Dormant Status Code That Powers the Agent Economy

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.

# 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.

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. The agent pays, 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. 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. 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.

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 needed

5. 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 agent pays it without thinking. 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 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 increasingly sophisticated payment strategies: comparing prices across providers, pre-funding budgets for anticipated workflows, and negotiating bulk rates through macaroon caveats.

The end state is an internet where machines can discover, evaluate, purchase, and consume digital services without any human in the loop. Not because humans aren't important — but because humans set the budgets, constraints, and policies, and the machines execute within those boundaries at speeds no human could match.

HTTP 402 was reserved for future use in 1997. The future is here, and it looks like AI agents paying for API calls with Lightning micropayments, governed by macaroon tokens, settled in milliseconds. The dormant status code just woke up.