Dashboard
EN
Start free

How an AI agent pays for a web search per call with x402

No account, no API key: the real 402 challenge FastAF returns, the Node client that pays it in USDC on Base, and how to cap what the agent can spend per call.

An agent that needs one Google search should not need a signup form, an API key in a secrets manager and a prepaid balance. With x402 it sends the request, gets a price back, pays it from its own wallet and gets the data. Here is the whole round trip against FastAF, with the real challenge and the real client code.

What is x402?

x402 revives the HTTP status 402 Payment Required, which sat unused in the spec for decades. The server answers an unpaid request with 402 and a machine-readable price; the client pays and retries the same request. In version 2 of the protocol this travels in three headers, each base64-encoded JSON: PAYMENT-REQUIRED (server to client, the price), PAYMENT-SIGNATURE (client to server, the signed payment) and PAYMENT-RESPONSE (server to client, the settlement result), as described on docs.x402.org, checked 19 October 2026.

The payment itself is a stablecoin transfer, in practice USDC on Base. The client signs an authorization; a facilitator checks it against the server’s requirements and submits it on chain. The facilitator docs are explicit that it “does not hold funds or act as a custodian”. The protocol was incubated at Coinbase and contributed to the x402 Foundation under the Linux Foundation, announced on 2 April 2026, and is Apache-2.0 licensed.

What does the 402 challenge look like?

Every FastAF endpoint is available under https://api.fastaf.co/x402/v1/{endpoint} with the same parameters as the keyed API. The first request costs nothing:

curl -i "https://api.fastaf.co/x402/v1/serp?query=x402+payment+protocol"

On 19 October 2026 this came back as HTTP/2 402 in 0.24 seconds. Decoding the payment-required header gives (trimmed):

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

Field by field:

  • scheme: "exact": pay exactly this amount, no more.
  • network: "eip155:8453": Base mainnet, in CAIP-2 notation.
  • amount: "5000": atomic units. USDC has 6 decimals, so 5000 is $0.005, the price of one search.
  • asset: the USDC contract on Base. The SDK’s own table of default assets lists the same address as USDC.
  • payTo: the address that receives the payment.
  • maxTimeoutSeconds: 300: the signed authorization is valid for five minutes.
  • extra.name and extra.version: the token’s EIP-712 domain, which the client needs to sign a valid transfer authorization.

One detail worth knowing: parameters are validated before any price is quoted. The same URL without q returned 400 invalid_parameters, not a 402, so an agent never gets asked to pay for a malformed request.

How does the agent pay it in Node?

The official packages do the parsing, signing and retry. The versions below are the current ones on npm (@x402/fetch 2.28.0, with @x402/core and @x402/evm at the same version):

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

const client = new x402Client();
registerExactEvmScheme(client, {
  signer: privateKeyToAccount(process.env.AGENT_WALLET_KEY),
  networks: ["eip155:8453"],
});

// Refuse any single payment above one cent.
client.setSpendControls({ maxAmountPerPayment: "$0.01" });

// Refuse to pay once this run has spent $0.05 (USDC atomic units).
let spent = 0n;
client.onBeforePaymentCreation(async ({ selectedRequirements }) => {
  const amount = BigInt(selectedRequirements.amount);
  if (spent + amount > 50_000n) return { abort: true, reason: "run budget exhausted" };
  spent += amount;
});

const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const res = await fetchWithPayment("https://api.fastaf.co/x402/v1/serp?query=x402+payment+protocol");
console.log(res.status, res.headers.get("X-FastAF-Credits-Used"));

Without setSpendControls, @x402/core already caps each payment at DEFAULT_MAX_AMOUNT_PER_PAYMENT, which is "$1" in the installed source. For a search API that is far too generous; set it to what your most expensive call costs.

We ran this script on 19 October 2026 with a freshly generated wallet holding no USDC, so no paid call was completed and the 200 response with the PAYMENT-RESPONSE receipt is what the SDK does with a funded wallet. What did happen: with the cap at $0.002 the SDK refused locally in 91 ms, before signing anything (“rejected by spendControls.maxAmountPerPayment”). With the cap at $0.01 it parsed the 402, signed, retried, and the server answered 402 again with invalid_exact_evm_insufficient_balance. No search ran and nothing was settled.

Why does “settled only on success” matter for agents?

Agents fail a lot of calls: a bad query, a page that times out, a target that is not allowed. On FastAF the signed payment is settled only after the upstream request succeeds. If the call fails, the authorization is never submitted and expires after maxTimeoutSeconds, so the wallet keeps its money. The keyed API follows the same rule: failed requests are never charged.

Prices are the credit cost of the keyed API at $0.001 per credit. These amounts were read from live challenges on 19 October 2026:

Request Credits x402 amount Price
/scrape, static page 1 1000 $0.001
/serp, Google search 5 5000 $0.005
/shopping 10 10000 $0.01
/linkedin profile 60 60000 $0.06

When are prepaid credits the better choice?

x402 is the right fit for an agent that makes occasional calls, runs somewhere you cannot provision a key, or should pay from its own budget. Prepaid credits win in three cases:

  • Volume. A $10 Starter pack is 20,000 credits, so 1,000 searches cost $2.50 instead of $5.00 over x402, and $1.50 on the Pro pack. Credits stay valid for 12 months, no subscription.
  • MCP. The hosted MCP server at https://api.fastaf.co/mcp authenticates with a Bearer key; it does not take x402 payments.
  • A hard cap on the account. An exhausted balance returns 402 insufficient_credits and stops, whatever the agent decides. The spending cap post shows how to layer that with a per-run budget.

How do you keep the agent’s wallet safe?

The private key sits in the agent’s environment and signs without asking anyone, so treat it as a hot wallet:

  • Use a dedicated wallet per agent, never one that holds anything else.
  • Fund it with small amounts and top it up deliberately; the balance is your worst case.
  • Set maxAmountPerPayment to the price of your most expensive call, plus a per-run budget in the hook.
  • Pin networks to eip155:8453 so the client never pays on a chain you did not plan for.

The short version

x402 turns a 402 response into a price tag: decode PAYMENT-REQUIRED, sign the USDC authorization, retry with PAYMENT-SIGNATURE. On FastAF a search is $0.005, settled only if it succeeds, and the SDK’s spend controls cap each payment before anything is signed. The full flow is in the x402 section and every price is on pricing. For volume or MCP, create a free account and start with 500 credits, no card.