Agent Wallets: Paying Per Run with x402
Buyer-side guide to giving an AI agent a wallet: how the x402 payment loop works, the client libraries that automate it, spend controls, and what 20,000+ Apify Actors on x402 mean for agent tool budgets.
In June 2026, Apify — in partnership with Coinbase — put 20,000+ Actors on x402, roughly 10x the ~2,000 payable endpoints the ecosystem offered before. That changed the economics of agent tooling: an agent with a funded wallet can now discover a web-data tool, pay for a single run in USDC, and get results back — no account, no API key, no human sign-up anywhere in the loop. This guide covers the buyer side: what your agent needs to pay per run, and how to keep it from spending your money badly. For the protocol comparison and the seller side, see agentic payment protocols.
What the agent actually does
The x402 loop is four steps, and libraries automate all of them:
- The agent calls a paid endpoint normally (
GET /priced-thing). - The server answers
402 Payment Requiredwith machine-readable payment requirements (price, network, asset, recipient). - The client library signs a stablecoin transfer authorization from the agent's wallet locally (no gas spent at this point) and retries the same request with an
X-PAYMENTheader. - The server (via a facilitator) verifies and settles the payment on-chain, then returns the resource plus an
X-PAYMENT-RESPONSEsettlement receipt.
From the agent's point of view, a paid API call is just an HTTP call that costs money. No OAuth dance, no key vault entry, no invoice.
What you need
| Piece | What it is | Notes |
|---|---|---|
| Wallet | An EVM account the agent can sign with | USDC on Base is the ecosystem default; fund it with small amounts only |
| Client library | Wraps HTTP and handles the 402→sign→retry loop | JS/TS: @x402/fetch or @x402/axios + @x402/evm; Python: x402[httpx] (async) or x402[requests] (sync) |
| Budget policy | Your own spend controls | The upto scheme lets you authorize a maximum and be charged actual usage |
The signing key IS the budget: anyone (any process) holding it can spend the wallet. Treat it like a production credential — a dedicated low-balance wallet per agent, not your main account.
Payment schemes: exact vs upto
exact— fixed price known upfront; the agent authorizes exactly that amount. Right for flat-priced resources (a document, an API call with a posted price).upto— the agent authorizes a ceiling; the service charges for actual usage on completion. Apify uses this (with a deposit-and-refund mechanism) for variable-cost Actor runs, and it is the shape to prefer for batch or open-ended work: your worst case is bounded by the authorization, not by the tool's appetite.
Discovering what is payable
The x402 Bazaar (Coinbase developer platform) indexes payable endpoints with semantic descriptions and payment metadata — a paginated catalog at …/v2/x402/discovery/resources plus a hybrid full-text + semantic search. Endpoints appear there automatically once the CDP facilitator settles a payment for them. For Apify specifically, the integration docs at docs.apify.com/platform/integrations/x402 describe calling any public Actor via x402.
Spend-control checklist (before you fund the wallet)
- Dedicated wallet per agent, funded with a small float (e.g. $10–50), topped up deliberately — never a key to a main treasury.
- Prefer
uptofor anything variable-cost; a stuck crawl should hit your authorization ceiling, not your balance floor. - Log every 402 and every settlement receipt (
X-PAYMENT-RESPONSE) — you want an audit trail of what the agent bought and why. - Price-check before paying: the 402 body carries the price; your loop should compare it against a per-call and per-day budget before signing.
- Watch for facilitator trust: the facilitator sees your payment flow; use one operated by a party you would use as a payment processor.
Paying this site
ChangeGamer itself sells premium resources over a machine-readable paywall. Two rails exist today: the live HTTP 402 + Bearer-key flow (buy a key once via Stripe, retry with Authorization: Bearer — see paying for access) and a native x402 endpoint (/api/x402/<slug>) that is scaffolded but dormant — it returns HTTP 503 until on-chain settlement is enabled on this server. Check /api/payment.json for the current status of every payment method before attempting one; the manifest is the source of truth.
Verified sources
- Apify x402 launch (June 2026): https://blog.apify.com/introducing-x402-agentic-payments/
- Apify x402 integration docs: https://docs.apify.com/platform/integrations/x402
- x402 buyer quickstart (client libraries): https://docs.cdp.coinbase.com/x402/quickstart-for-buyers
- x402 Bazaar discovery layer: https://docs.cdp.coinbase.com/x402/bazaar
- x402 Foundation canonical spec: https://github.com/x402-foundation/x402
- ChangeGamer payment manifest: /api/payment.json