Agent Payments and HTTP 402

HTTP 402 “Payment Required” was reserved in 1997 for a digital payment layer that never shipped — traditional payment rails couldn’t support micropayments economically. Thirty years later, AI agents need exactly what 402 was designed for: autonomous, real-time, machine-to-machine payments without human intervention, signups, or API key provisioning.

Three competing protocols now implement it. All use the same HTTP flow. They differ in settlement rails.

The Universal Flow

Every HTTP 402 implementation follows the same three-step handshake:

sequenceDiagram
    participant A as Agent
    participant S as Service

    A->>S: GET /api/premium-data
    S-->>A: 402 Payment Required<br/>+ payment instructions (headers)

    Note over A: Agent reads price,<br/>constructs payment,<br/>signs with wallet

    A->>S: GET /api/premium-data<br/>+ payment proof (headers)
    S-->>A: 200 OK + data

1. Agent requests a resource without payment
2. Server responds 402 with machine-readable payment requirements (price, currency, network, payment address)
3. Agent constructs and signs payment, retries with proof in headers
4. Server verifies payment, serves the resource

No accounts. No signups. No OAuth dance. The payment is the authentication.

The Three Protocols

x402: Stablecoin Payments

Coinbase’s open-source protocol. Agents pay in USDC on Base (or any EVM chain). The most widely adopted as of 2026.

Headers

# Server response (402)
HTTP/1.1 402 Payment Required
X-Payment-Required: {"price": "0.001", "currency": "USDC", "network": "eip155:8453", "address": "0x...", "facilitator": "https://facilitator.x402.org"}

# Agent retry (with payment)
GET /api/data
X-Payment-Signature: <signed_payment_payload>

How It Works

1. Server returns 402 with X-Payment-Required header — includes price, token, chain (CAIP-2 format), and recipient address
2. Agent constructs a PaymentPayload using ERC-20 Permit2 or EIP-3009 (gasless token approval)
3. Agent signs with its wallet and sends the signature header
4. Server forwards to a Facilitator (payment verification service) — the seller never touches blockchain infrastructure directly
5. Facilitator settles on-chain, server serves the resource

Scale

• 15M+ total transactions by early 2026
• x402 Foundation members: Coinbase, Cloudflare, Google, Visa
• Cloudflare AI Content Marketplace uses x402 for pay-per-crawl pricing

L402: Lightning Micropayments

Lightning Labs’ protocol. Agents pay via Bitcoin Lightning with macaroon-based credentials. Lowest possible payment granularity — fractions of a cent.

Headers

# Server challenge (402)
HTTP/1.1 402 Payment Required
WWW-Authenticate: L402 version="0", token="<base64_macaroon>", invoice="<bolt11_invoice>"

# Agent retry (with proof)
GET /api/data
Authorization: L402 <base64_macaroon>:<hex_preimage>

How It Works

1. Server returns 402 with a Lightning invoice and a macaroon (cryptographic bearer credential)
2. Agent pays the Lightning invoice — settlement reveals a preimage (32-byte proof of payment)
3. Agent retries with Authorization: L402 <macaroon>:<preimage>
4. Server verifies: sha256(preimage) == payment_hash — stateless, no database lookup needed

Macaroons: Delegated Agent Wallets

The key innovation for multi-agent systems. A macaroon holder can cryptographically restrict (attenuate) credentials without contacting the issuer:

graph TD
    O["Orchestrator Agent<br/><i>Holds root macaroon</i>"] --> R["Research Agent<br/><i>+ caveat: max $0.10</i><br/><i>+ caveat: read-only APIs</i>"]
    O --> C["Code Agent<br/><i>+ caveat: max $1.00</i><br/><i>+ caveat: expires 1hr</i>"]
    O --> D["Deploy Agent<br/><i>+ caveat: max $5.00</i><br/><i>+ caveat: requires HITL</i>"]

The orchestrator delegates spend authority to sub-agents by adding caveats to the macaroon. Each sub-agent gets a restricted credential — no server round-trip required, no shared private keys.

MPP: Fiat + Crypto via Stripe

Stripe’s Machine Payments Protocol. The bridge for merchants already on Stripe who want to accept agent payments without blockchain integration.

How It Works

1. Agent pre-funds a session (like pre-authorizing a credit card)
2. Every API call triggers automatic micro-settlement against the pre-funded balance
3. Supports Shared Payment Tokens (SPTs) — multi-asset credentials accepting USDC, credit cards, or BNPL
4. Settlement via standard Stripe PaymentIntents — merchants get funds in their default currency on their normal payout schedule

Key Difference

x402 and L402 are per-request payment protocols. MPP is a session-based protocol — authorize once, transact many times. Lower latency for high-frequency agent interactions, but requires session state.

MCP Integration

HTTP 402 and MCP compose naturally. When an MCP tool call hits a paid endpoint, the 402 flow happens inside the tool invocation:

sequenceDiagram
    participant A as Agent
    participant M as MCP Client
    participant T as MCP Tool Server
    participant P as Paid API

    A->>M: tools/call "fetch_premium_data"
    M->>T: Execute tool
    T->>P: GET /api/data
    P-->>T: 402 + payment requirements
    T->>T: Sign payment with agent wallet
    T->>P: GET /api/data + payment proof
    P-->>T: 200 OK + data
    T-->>M: Tool result
    M-->>A: Data returned

The x402-mcp package (Vercel/Civic) adds this interception to any MCP server. The agent doesn’t manage payments directly — the MCP tool layer handles 402 negotiation transparently.

Choosing a Protocol

These protocols are not mutually exclusive. A service can accept multiple payment methods by returning multiple options in the 402 response. The agent selects whichever it has credentials for.

Security Considerations

• Per-request payments are self-limiting. An agent can only spend what it’s authorized to spend per request. No runaway billing from a stuck loop — the agent must actively sign each payment.
• Macaroon delegation caps spend. Parent agents restrict sub-agent budgets cryptographically. The sub-agent cannot spend more than the caveat allows, even if compromised.
• No stored credentials. 402 payments are bearer proofs — the payment itself is the auth. No API keys to leak, no tokens to rotate.
• HITL for high-value transactions. All three protocols support a 202 Accepted response that pauses execution for human approval before settlement. See ARWS Layer 4.

The Bigger Picture

HTTP 402 completes the ARWS stack:

Without 402, agents can only use free or pre-authenticated APIs. With 402, any service on the internet can charge agents directly — no accounts, no billing dashboards, no invoices. The payment is in the protocol.