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?
- The client sends an ordinary request, for example
GET https://api.fastaf.co/x402/v1/serp?query=coffee. - The server replies
402with aPAYMENT-REQUIREDheader (x402 v2) whose JSON lists what it accepts:scheme,network,asset,amount,payToandmaxTimeoutSeconds. - The client signs a payment authorization for that exact amount and resends the request with the signature.
- 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
payToand 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.