How to read this toolkit

"Top tools for agentic payments" is not a list of competing products; it is the toolkit a single build uses together. Paying, earning, and operating agentic payments each need a different tool, and they compose rather than compete. So this page walks the toolkit job by job, naming the tool for each and what it does, so you know which to reach for at each stage of a build.

Read it as a parts list, not a ranking. You will use most of these in one production system: a client to pay, an adapter to receive, an SDK to manage the agent, webhooks to confirm, a limit read to respect budget, and testnet tooling to verify before going live. Knowing the job each does is what lets you assemble them without guessing.

The six tools

The agentic payments toolkit has six tools by job: the pay-side client, the receive-side adapters, the wallet SDK, webhooks, spend-limit reads, and testnet tooling. Each does one job, and together they cover the full flow of making, taking, confirming, and controlling payments.

Tool 1: The pay-side client

createX402Client from @blockchain0x/x402 is the tool for paying. It wraps fetch so that when a call returns an HTTP 402, the client settles the amount in USDC on Base and retries automatically. You wrap it in your agent's tool, and the agent pays for what it calls without your code handling the protocol.

This is the first tool you reach for on the pay side, and the one an agent's wallet tool is built around. It does one job, answer a 402 and retry, and does it for any endpoint that speaks x402. For the walkthrough of wiring it into an agent, see how-to-add-usdc-payments-to-ai-agent.

Tool 2: The receive-side adapters

createX402Plugin (Fastify) and createX402Middleware (Express) are the tools for earning. You register one in front of a route with per-route pricing, and it returns the 402, verifies the payment on the retry, and runs your handler only once paid. They are the mirror of the client: the client pays, the adapters charge.

These are the first tools on the receive side, and they cover almost every per-call earning case on a standard Node server. When your server is non-standard, the wire helpers, parse402Response, buildPaymentHeader, parsePaymentHeader, and X402WireError, let you handle the protocol by hand, which is the lower-level companion to the adapters.

Tool 3: The wallet SDK

@blockchain0x/node, initialized with createClient, is the tool for managing agents and wallets. It creates and reads agents with client.agents.create and client.agents.get, reads a transaction with client.transactions.get, revokes a key with client.apiKeys.revoke, and manages webhooks. It is the control plane behind both the client and the adapters.

This is the tool you use to provision the agent that pays or earns and to manage it operationally. The client and adapters do the payment flow; the SDK is how you create the agent, look up a transaction, and rotate or revoke credentials. Most builds initialize it once and share the instance across the pay and receive sides.

Tool 4: Webhooks

The webhooks tool, managed through the SDK with client.webhooks.create and verified with webhooks.verify, is how you confirm payments durably. It delivers payment.received and payment.sent events when payments settle, plus wallet.deployed and a webhook.test event, and you verify each delivery against your signing secret before trusting it.

This is the operational backbone. The adapter verifies a paid call inline, but webhooks give you an independent, durable record to reconcile revenue and attribute spend per agent, which is what you build reporting on. Treat webhooks as the source of truth for what settled, and verify every delivery so a forged event cannot slip in.

Tool 5: Spend-limit reads

A GET to the agent's spend-permissions endpoint is the tool for respecting budget. It returns the limit fields, per_tx_wei, allowance_wei, and period_seconds, so a planner can read what the agent is allowed to spend and avoid attempting a call it cannot afford.

This is a read-only tool: spend limits are set and edited in the dashboard, not through the API, so the tool reads the budget rather than changing it. The limit is enforced server-side regardless, so reading it is for smarter planning, not safety. Use it when you want the agent to reason about budget before spending, and let the enforced limit be the backstop.

Tool 6: Testnet and explorer

Base Sepolia, with a faucet and a block explorer, is the tool for testing before you go live. A sk_test_ key settles everything on eip155:84532, you fund the agent with test USDC from a faucet, and you confirm each transaction on the explorer, all with no real money.

This is the tool that makes the rest safe to build against. You wire the client, adapters, SDK, and webhooks on testnet, watch real settlement on the explorer, and only swap to a sk_live_ key for Base mainnet once the flow works. Because the network is read from the key prefix, that swap is the only change between testnet and production.

What is not in the toolkit

It is as useful to know what you do not need. You do not need a framework-specific payment package, because none exists; the toolkit above is assembled from the client, the adapters, and the SDK, and framework integrations wrap those rather than adding a new dependency. You do not need a receipt cache or session store on the receive side, because the adapter verifies each call independently through settlement, so the server stays stateless. And you do not need a separate billing system for per-call agent payments, because the per-call settlement is the billing.

Knowing what is absent prevents over-building. A common mistake is to reach for a heavyweight billing or session layer that the per-call model makes unnecessary, or to look for a Python payment package that is not there and build awkwardly around its absence instead of using the small local proxy pattern. The toolkit is deliberately small: a client, an adapter, an SDK, webhooks, a limit read, and testnet tooling. If you find yourself adding much more than that for a straightforward agentic-payments build, it is worth checking whether one of these six tools already does the job you are about to build by hand, because usually it does. The smaller toolkit is also the more secure one, since there is less of your own code in the payment path to get wrong.

How they fit together

A production build uses these together: the SDK creates the agent, the client pays and the adapters charge, webhooks confirm what settled, the spend-limit read keeps the agent within budget, and Base Sepolia plus the explorer prove it all before mainnet. None replaces another; each does its job in the flow.

So the right way to read this toolkit is as a sequence, not a shortlist. Start on testnet, wire the pay or receive tool you need, add the SDK to manage the agent, attach webhooks to confirm, read the limit if the agent should plan around budget, and switch keys to go live. For choosing the underlying x402 implementation these tools come from, see best-x402-implementation, and for the paying walkthrough see how-to-add-usdc-payments-to-ai-agent. Pricing is on the pricing page.