← All resources

Agent Wallets: Paying Per Run with x402

Guide · updated 2026-07-02 · Markdown variant

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.

Key facts

• In June 2026 Apify teamed with Coinbase to list x402 pricing across more than 20,000 Actors, a roughly tenfold jump from the prior payable-endpoint count — a fast-growing figure the page itself flags for re-verification after roughly Q4 2026 — letting a funded agent pay per run in USDC without an account, an API key, or a human sign-up step anywhere in the flow.
• The payment loop is four steps handled by client libraries: call the endpoint, receive a 402 with machine-readable pricing, sign a stablecoin authorization locally and retry with a payment header, then get the resource back with a settlement receipt once a facilitator checks and finalizes the transfer on-chain.
• Because the signing key is effectively the spending limit, the guide advises scoping a single low-balance wallet to just one agent, funded only with a small float — USDC on Base is named as the ecosystem's default asset.
• Two payment schemes exist: a fixed scheme for a known price authorized upfront, and a ceiling scheme billed to actual usage at completion — the latter is the shape Apify applies to variable-cost Actor runs through a deposit-and-refund mechanism.
• Payable endpoints surface through a Coinbase-run discovery catalog combining full-text and semantic search, which lists an endpoint automatically the moment its facilitator settles a first payment for it.
• Recommended spend controls include funding each wallet with only a small float, preferring the ceiling scheme for variable-cost work, logging every payment request and settlement receipt, price-checking against a budget before signing, and vetting the facilitator's trustworthiness.
• On ChangeGamer itself, the live rail is a Bearer-key flow bought via Stripe, while the native x402 endpoint remains unbuilt-out and inactive, answering with an error status because on-chain settlement isn't turned on for this server yet.

What the agent actually does

The x402 loop is four steps, and libraries automate all of them:

1. The agent calls a paid endpoint normally (GET /priced-thing).
2. The server answers 402 Payment Required with machine-readable payment requirements (price, network, asset, recipient).
3. 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-PAYMENT header.
4. The server (via a facilitator) verifies and settles the payment on-chain, then returns the resource plus an X-PAYMENT-RESPONSE settlement 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

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 upto for 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

Content freshness

This page's Apify Actor count, client-library names (@x402/fetch, @x402/axios, @x402/evm, x402[httpx], x402[requests]), and the x402 Bazaar discovery layer describe a fast-growing ecosystem, not a fixed spec — package names get renamed, catalogs grow, and marketplace-scale figures age quickly. Treat these specifics as most reliable as of this page's updated date (2026-07-02); if you're reading this after roughly Q4 2026, independently re-verify the current Actor count and confirm the client libraries above still match what's published on npm and PyPI before wiring them into a build.

#x402 #payments #wallets #agents #usdc #apify #autonomy

Category: Guide