HTTP 402 is back: AI entities start paying for APIs themselves

Your intelligent agent needs to call an interface. The conventional path is designed for humans: registering an account, verifying an email, binding a credit card, obtaining an API key, selecting a subscription tier------to use it 17 times, first buy a package of 10,000 times.

In fact, there is a fourth path, and it has been around for 30 years: HTTP status code 402 Payment Required, which was reserved in the original HTTP specification, noted as "for future use." The future has arrived. The x402 protocol (v2, maintained by Coinbase) turns 402 into a usable payment handshake: the server returns a quote, the agent signs a stablecoin payment authorization, and the settlement party completes the transfer on-chain, then the interface returns the result------no account, no key, no subscription. Payment itself is authentication.

This is not a white paper overview. Each step below has been tested against real online interfaces (testing service: call402.com, a publicly running x402 service), and the quotes and returns are real data, with no illustrative diagrams.

Step 1: Ask for a price------a real quote

If you call any interface without paying, you will receive HTTP 402 and a machine-readable quote:
BASH copy

curl -X POST https://call402.com/api/phone-lookup \
  -H 'Content-Type: application/json' \
  -d '{"number": "+14155552671"}'

JSON copy

{
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "5000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0xAc6F1C3C3b17040730F16dC24Ee9993e9565BE4A",
    "maxTimeoutSeconds": 300,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

Read it as a price tag: amount is the minimum unit, 5000 is 0.005 USD (USDC is 6 decimal places); asset is the USDC contract on the Base chain; payTo is the payee; you have 300 seconds to pay according to this quote.

Step 2: Payment and call------this is the total code for the buyer

Using the official TypeScript library, the complete buyer code is just these few lines:
TYPESCRIPT copy

import { wrapFetchWithPayment } from "@x402/fetch";
import { x402Client } from "@x402/core/client";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(process.env.EVM_PRIVATE_KEY as `0x${string}`);
const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(signer));
const fetchWithPay = wrapFetchWithPayment(fetch, client);

const res = await fetchWithPay("https://call402.com/api/phone-lookup", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ number: "+14155552671" }),
});
console.log(await res.json());

// The settlement proof is returned in the PAYMENT-RESPONSE response header:
const proof = res.headers.get("PAYMENT-RESPONSE");
if (proof) {
  const settlement = JSON.parse(Buffer.from(proof, "base64").toString("utf8"));
  console.log("tx:", settlement.transaction, "payer:", settlement.payer);
}

BASH copy

npm i @x402/fetch @x402/core @x402/evm viem

The wrapper sees 402 and constructs an EIP-3009 payment authorization according to the quote, attaching a signature to retry, and the settlement party immediately completes the USDC transfer on Base. The return is just ordinary JSON:
JSON copy

{ "valid": true, "country": "US", "type": "FIXED_LINE_OR_MOBILE",
  "e164": "+14155552671", "national": "(415) 555-2671" }

Other interfaces of this store------and any x402 seller------work exactly the same. One buyer can visit all stores.

Step 3: Don't trust 200, verify the settlement yourself

Decode the PAYMENT-RESPONSE response header (it is Base64 encoded JSON) and check three things: this transaction actually exists on the Base browser and its status is successful; the USDC transfer record indeed went from your address to the payTo in the quote; the amount matches the quoted amount exactly. If any of the three do not match, note it down and stop------do not pay again directly.

The actual pitfalls you may encounter are just these:

Step 4: Set a budget discipline for the wallet

An agent that can sign is an agent that can spend money. Four rules to make it boring:

1. Single transaction limit (for example, 0.01 USD) and daily limit (for example, 1 USD) must be checked before signing.
2. Domain and asset whitelist ------the buyer should reject any quotes outside the whitelist.
3. Dedicated wallet, only hold capped float, never use the main wallet.
4. A ledger of expenses that only increases and does not change: transaction hash, interface, amount, regularly reconcile with on-chain transfers.

Finally, leave a question

If your agent has a wallet with a daily budget of 1 USD, what would you let it buy first? And what would you absolutely not let it touch? Once the payment barrier is crossed, the things the agent can do will increase significantly------and where each person draws the line may determine the direction of this matter more than the technology itself.