t402: The Internet Finally Gets a Payment Protocol

The 29-Year Wait

In 1997, the IETF published RFC 2068 defining HTTP/1.1. Among the status codes was 402 Payment Required, described with a single sentence:

“This code is reserved for future use.”

That was 29 years ago. Every other 4xx status code found its purpose — 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests. But 402 remained an empty promise, a placeholder for a payment layer that the web never built.

The web chose a different path: ads, subscriptions, and payment processors. Stripe charges $0.30 + 2.9% per transaction, making any payment below $0.50 economically unviable. PayPal, Apple Pay, Google Pay — they all inherit this floor. The result: an internet where micropayments are structurally impossible, and every content creator is funneled into either advertising or monthly subscription models.

t402 changes this.

What is t402

t402 is an open-source HTTP-native payment protocol that finally gives purpose to the 402 status code. It enables any web server to require and process stablecoin payments (USDT, USDT0, USDC) directly within the standard HTTP request/response cycle.

The name is straightforward: Tether + HTTP 402.

The core idea: your server returns 402 Payment Required with payment instructions in the header. The client signs a stablecoin authorization off-chain (zero gas cost). A facilitator settles on-chain. The server returns 200 OK with the resource. The entire flow completes in under 3 seconds.

No intermediaries. No KYC dashboards. No minimum transaction amounts. No chargebacks.

The Protocol Flow

t402 operates in 6 steps across 3 actors: Client, Resource Server, and Facilitator.

sequenceDiagram
    participant C as Client
    participant S as Resource Server
    participant F as Facilitator
    participant B as Blockchain

    C->>S: GET /api/premium-data
    S-->>C: 402 Payment Required<br/>(PAYMENT-REQUIRED header)
    Note over C: Sign authorization<br/>off-chain (zero gas)
    C->>S: GET /api/premium-data<br/>(PAYMENT-SIGNATURE header)
    S->>F: POST /verify
    F-->>S: Valid
    S->>F: POST /settle
    F->>B: Submit signed tx
    B-->>F: Confirmed
    F-->>S: Settlement receipt
    S-->>C: 200 OK + Resource<br/>(PAYMENT-RESPONSE header)

Step 1: Client Makes a Request

GET /api/premium-data HTTP/1.1
Host: api.example.com

A standard HTTP request. Nothing special.

Step 2: Server Returns 402

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: eyJ0NDAyVmVyc2lvbiI6Mn0=

The PAYMENT-REQUIRED header contains a Base64-encoded JSON object specifying what the server accepts:

{
  "t402Version": 2,
  "resource": {
    "url": "/api/premium-data",
    "description": "Real-time market data feed"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:42161",
      "amount": "10000",
      "asset": "0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9",
      "payTo": "0xMerchantWallet..."
    }
  ]
}

The server says: “Pay 0.01 USDT on Arbitrum to this address, and I’ll give you the data.”

Step 3: Client Signs Off-Chain

The client constructs an EIP-3009 transferWithAuthorization and signs it with EIP-712 typed data. This happens entirely off-chain — no gas, no transaction, no blockchain interaction. Just a cryptographic signature.

The signature covers: sender, recipient, amount, valid time window, and a random nonce. Crucially, the recipient address is locked into the signature. No one — not even the facilitator — can redirect the payment elsewhere.

Step 4: Client Resubmits with Payment

GET /api/premium-data HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: eyJhY2NlcHRlZCI6ey4uLn19

The same request, now with a PAYMENT-SIGNATURE header containing the signed authorization.

Step 5: Verification and Settlement

The resource server forwards the signature to a Facilitator service, which:

1. Validates the cryptographic signature
2. Checks the sender’s token balance
3. Confirms the amount matches or exceeds the requirement
4. Verifies the time window is valid
5. Simulates the transaction
6. Broadcasts the signed authorization to the blockchain
7. Waits for confirmation

Step 6: Resource Delivered

HTTP/1.1 200 OK
PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlfQ==
Content-Type: application/json

{"data": "...premium content..."}

The PAYMENT-RESPONSE header includes the transaction hash for on-chain verification.

Why Not Just Use Stripe?

graph LR
    subgraph Stripe
        A["$0.01 Payment"] --> B["$0.30 Fee<br/>3,000% overhead"]
    end
    subgraph t402
        C["₮0.01 Payment"] --> D["< ₮0.001 Fee<br/>< 10% overhead"]
    end

Stripe is excellent for traditional e-commerce. But it fundamentally cannot serve three emerging markets:

Micropayments: A ₮0.01 API call costs $0.30 in Stripe fees — a 3,000% overhead. t402 on Arbitrum or Base costs a fraction of a cent.

Machine-to-machine payments: AI agents don’t have credit cards. They have wallets. t402’s MCP integration lets Claude, GPT, and other AI agents autonomously discover, evaluate, and pay for APIs.

Instant global settlement: USDT on L2 settles in seconds with finality. No 2-day ACH holds, no currency conversion, no correspondent banking.

Why Not Lightning Network?

Lightning Network is brilliant for Bitcoin-denominated micropayments. But:

• Volatility: Merchants receiving BTC bear price risk. USDT is pegged to USD.
• Channel management: Lightning requires liquidity management, channel opening/closing, and routing. t402 is stateless — each payment is independent.
• Multi-chain: t402 supports 52 networks across 12 blockchain families. Lightning is Bitcoin-only.
• Developer experience: t402 integrates as HTTP middleware. Lightning requires running a node.

They serve different use cases. Lightning is for Bitcoin payments. t402 is for stablecoin payments on the web.

The Scale

t402 supports 52+ networks across 12 blockchain families:

graph TB
    T402[t402 Protocol] --> EVM[EVM<br/>19 USDT0 Networks]
    T402 --> SOL[Solana]
    T402 --> TON[TON]
    T402 --> TRON[TRON]
    T402 --> NEAR[NEAR]
    T402 --> APT[Aptos]
    T402 --> TEZ[Tezos]
    T402 --> DOT[Polkadot]
    T402 --> STX[Stacks]
    T402 --> ATOM[Cosmos]
    T402 --> XLM[Stellar]
    T402 --> BTC[Bitcoin<br/>PSBT + Lightning]

• EVM: 19 USDT0 networks via LayerZero (Ethereum, Arbitrum, Base, Optimism, Polygon, and 14 more) + legacy USDT on BNB, Avalanche, Fantom, Celo, Kaia
• Solana: SPL Token (USDC)
• TON: Jetton TEP-74 (USDT)
• TRON: TRC-20 (USDT)
• NEAR: NEP-141 (USDT)
• Aptos: Fungible Asset (USDT)
• Tezos: FA2 (USDt)
• Polkadot: Asset Hub (USDT)
• Stacks: SIP-010 (sBTC)
• Cosmos (Noble): Native USDC
• Stellar: Soroban SEP-41 (USDC)
• Bitcoin: PSBT + Lightning (BOLT11)

One protocol, one API, one developer experience — regardless of which chain the payer uses.

The Developer Experience

Server-side integration is 5 lines of middleware:

import { paymentMiddleware } from "@t402/express";

app.use(
  paymentMiddleware({
    "GET /api/premium": {
      price: "₮0.01",
      network: "eip155:42161",
      payTo: "0xYourWallet...",
    },
  })
);

That’s it. Any GET /api/premium request now returns 402 unless accompanied by a valid payment signature.

Client-side:

import { T402Client } from "@t402/fetch";

const client = new T402Client({ signer: wallet });
const response = await client.fetch("https://api.example.com/api/premium");
const data = await response.json();

The client handles the 402 → sign → resubmit → 200 flow automatically.

SDKs are available in TypeScript, Python, Go, and Java — all with full feature parity.

Trust Minimization

The critical security property: the Facilitator cannot steal funds.

When the client signs the payment authorization, the recipient address (payTo) is embedded in the EIP-712 typed signature. The smart contract’s transferWithAuthorization function verifies on-chain that the signature matches all parameters — including the recipient. If the Facilitator attempts to change the destination, ecrecover returns a different signer, and the transaction reverts.

The Facilitator’s role is purely operational: it broadcasts the pre-signed authorization and covers gas fees. It has no ability to redirect, withhold, or modify the payment. This is enforced by cryptography, not by trust.

The AI Economy

Perhaps the most forward-looking aspect of t402: it’s designed for a world where AI agents are economic actors.

Through MCP (Model Context Protocol) integration, AI agents like Claude can:

1. Discover paid resources via the Bazaar extension
2. Evaluate pricing and decide whether to pay
3. Execute payments autonomously from their wallet
4. Verify settlement via on-chain transaction receipts

The A2A (Agent-to-Agent) transport extends this further — agents can sell services to other agents, creating an autonomous machine economy where payments flow as naturally as HTTP requests.

What’s Next

This is the first in a series of articles exploring t402:

1. t402: The Internet Finally Gets a Payment Protocol ← You are here
2. t402 Protocol Deep Dive: How HTTP 402 Actually Works — The complete protocol specification, three-actor architecture, and formal security model
3. Building with t402: From Zero to Paid API in 10 Minutes — Hands-on developer tutorial with the SDK and sandbox
4. t402 and the AI Economy: Machine-to-Machine Payments — MCP integration, A2A transport, ERC-8004 agent identity
5. t402 Multi-Chain Architecture: 52 Networks, One Protocol — Chain mechanisms, ERC-4337 gasless, USDT0 cross-chain bridging

Links

• t402.io — Protocol overview
• Documentation — Full technical docs
• GitHub — Open source (Apache 2.0)
• Explorer — Real-time settlement browser
• Sandbox — Public testnet for developers
• Demo — Interactive demonstration
• Whitepaper — 153-page technical specification

t402 is open source under the Apache 2.0 license. The protocol specification and whitepaper are available under the MIT license.