x402

an open payment protocol that uses HTTP status 402 so a client can pay for a request and retry it with proof of payment. FastAF supports x402 v2.

x402 is an open payment protocol that puts the HTTP status code 402 Payment Required to work. A server answers an unpaid request with a 402 and a structured list of payment requirements; the client pays and repeats the same request with proof of payment attached. No account, session or API key is involved: the payment itself authorizes the request.

How does the request, challenge and retry loop work?

  1. The client sends an ordinary request, for example GET https://api.fastaf.co/x402/v1/serp?query=coffee.
  2. The server replies 402 with a PAYMENT-REQUIRED header (x402 v2) whose JSON lists what it accepts: scheme, network, asset, amount, payTo and maxTimeoutSeconds.
  3. The client signs a payment authorization for that exact amount and resends the request with the signature.
  4. The server, usually through a facilitator, verifies the signature, serves the response and settles the payment on-chain.

What does a FastAF challenge look like?

For the serp route the challenge says scheme: exact, network Base mainnet (eip155:8453), asset USDC (0x8335…2913), amount: 3000 and maxTimeoutSeconds: 300. USDC uses 6 decimals, so 3000 units are $0.003. An agent can read this before paying and refuse if the amount is above its budget.

Which versions does FastAF accept?

x402 v2. The requirements travel in the PAYMENT-REQUIRED header and name networks with CAIP-2 identifiers such as eip155:8453 for Base; the JSON body of the same 402 repeats them. The client signs and retries with the PAYMENT-SIGNATURE header.

How does FastAF apply it?

  • 24 routes under /x402/v1/, each with one fixed price, listed on the x402 price list.
  • Payment settles only when the call succeeds (HTTP 200).
  • Options that would cost more than the fixed price are not sold over x402: a paid request with them is refused with options_need_api_key, before any charge, and needs an API key.
  • The MCP server does not use x402.

Example: an agent budget check

An agent with a $0.01 cap per call reads the 402 for serp ($0.003) and pays; for linkedin ($0.06) it stops and asks its operator. The decision happens before any money moves.

Common mistakes

  • Treating the 402 of a bare curl as an error: it is the price quote.
  • Expecting an ordinary API-key SDK to pay: it does not sign wallet payments.
  • Reusing an old challenge: request a fresh one so amount and timeout are current.

Agent payments

Agent payments are payments started by a software agent rather than by a person at a checkout. An agent that needs a paid resource (a search result, a page, a dataset) pays for it during the task, within limits set by its operator. The hard part is not moving money; it is making sure the agent spends only what it should.

What are the building blocks?

  • A wallet the agent controls, funded with a small amount of a stablecoin such as USDC.
  • A payment protocol that agent and server both understand, such as x402.
  • A policy: maximum per call, maximum per task or day, allowed networks, assets and hosts.
  • Receipts, so every payment can be audited afterwards.

Example policy for a FastAF agent

allowed_host:   api.fastaf.co
network:        Base mainnet
asset:          USDC
max_per_call:   $0.01
max_per_day:    $2.00

With this policy the agent pays for serp ($0.003), zillow ($0.005) or images ($0.01) on its own, but a linkedin profile ($0.06) is over the per-call cap and goes to a human.

Why do fixed prices matter?

An agent can only enforce a cap if it knows the price before paying. FastAF’s x402 routes state a fixed amount in the 402 challenge, and only successful calls settle, so a retry loop cannot quietly drain the wallet on errors.

Agent payments or an API key?

An API key gives an agent access to a shared account balance: whoever holds the key can spend all of it. A wallet with a policy limits each payment on its own. FastAF supports both: API keys for REST and MCP (500 free credits every month after email verification), and x402 for agents that pay per call.

Which risks should you plan for?

  • Prompt injection that tries to make the agent pay an unknown host: restrict payTo and hosts.
  • Price drift: always read a fresh quote rather than a cached one.
  • Key leakage: never put wallet keys in prompts or logs.

How do you test safely?

Run the agent against FastAF’s Base Sepolia demo route first (/x402/v1/demo/search, $0.001 in test USDC, 5 verified attempts per IP per UTC day) before giving it real funds. See also how to cap agent spend per call.

Related: HTTP 402 · Pay-per-call API · How x402 works

Related terms

  • MCP: Model Context Protocol (MCP) standardizes how AI applications discover and invoke tools and access context.
  • HTTP 402: HTTP 402 Payment Required is an HTTP status code indicating that payment is required for a resource.
  • Pay-per-call API: A pay-per-call API charges for individual API requests rather than requiring a recurring subscription.

What it costs: FastAF pricing and credit packs · x402 price list per call

Frequently asked questions

What is x402?

an open payment protocol that uses HTTP status 402 so a client can pay for a request and retry it with proof of payment. FastAF supports x402 v2.

What are agent payments?

Agent payments are payments initiated by software acting within a user-defined authorization and spending policy. With x402 the agent pays a live challenge from its own wallet, within the amount, network and resources you allow.