How to let an AI agent pay for an API with x402

The problem: agents can act, but they cannot pay

An AI agent working through a real task often needs to spend money. It might call a premium data API, buy a single search result, run an inference on a paid model, or pay a per-request tool. The moment it hits a paywall, the flow breaks. Card forms assume a human. API keys with monthly invoices assume a signed contract and a finance team. Neither fits an agent that spins up, does a job, and needs to pay a few cents for one call, right now.

This is exactly the gap the x402 standard was built to close, and pairing it with a spend-capped stablecoin wallet lets an agent pay for what it needs while you stay firmly in control of the budget.

What is x402?

x402 is a payment standard built on the HTTP 402 "Payment Required" status code, a response that has existed in the spec for decades but was never really used. With x402, a server can answer a request with a 402 and a small machine-readable description of what payment it wants. The caller pays, retries the request with proof of payment, and gets the response. No account, no invoice, no card form. It turns any endpoint into something that can be metered and paid for one call at a time.

Because the whole exchange is just HTTP and an on-chain payment, an agent can handle it in code without a human in the loop. Read more on the x402 payments page.

The pieces you need

• A Sendbase account to create the agent's wallet. It is free to open and self-custodial, so you hold the keys.
• An agent wallet with spend caps. Per-transaction, daily, and monthly limits plus an address allowlist define the budget the agent can never exceed.
• An x402-aware client in your agent so it knows how to respond to a 402 by paying and retrying.
• Stablecoins to spend, USDT or USDC on BNB Smart Chain, which settle in seconds for a few cents of gas.

Step 1: Create a spend-capped wallet for the agent

In your Sendbase dashboard, create a dedicated wallet for the agent and set its limits. The key idea is that the wallet is scoped: even if the agent misbehaves or a prompt goes wrong, it can only ever spend what you allowed, and only to destinations you approve.

• Per-transaction cap, for example $2, so no single call can drain the budget.
• Daily cap, for example $50, to bound a runaway loop.
• Monthly cap for overall spend.
• Address allowlist so the agent can only pay services you trust.

Fund the wallet with a small amount of USDT or USDC. The balance stays in a wallet only you control, and you can pause or defund it at any time.

Step 2: Handle the 402 in your agent

When your agent calls a paid endpoint, it may get back an ordinary 200, or a 402 asking for payment. The pattern is simple: try the request, and if you see a 402, pay the amount it names from the agent wallet, then retry the same request with the payment proof attached. Conceptually it looks like this:

// Illustrative flow. See docs.sendbase.io for the exact SDK calls.
async function paidFetch(url, options, agentWallet) {
  let res = await fetch(url, options);

  // Endpoint wants payment for this call.
  if (res.status === 402) {
    const invoice = await res.json();       // amount, asset, payTo

    // Pay from the spend-capped wallet. If the amount is over
    // your caps or payTo is not allowlisted, this throws.
    const receipt = await agentWallet.pay({
      amount: invoice.amount,               // e.g. "0.02"
      asset:  invoice.asset,                // "USDT" or "USDC"
      payTo:  invoice.payTo,
    });

    // Retry with proof of payment.
    res = await fetch(url, {
      ...options,
      headers: { ...options.headers, "X-Payment": receipt.reference },
    });
  }

  return res;
}

That is the entire idea. Your agent's tool-calling code wraps its paid requests in something like paidFetch, and payment becomes a normal, automatic part of making a request. The exact method names and headers come from the API reference; the shape above is to show the flow.

Step 3: Let the caps do the worrying

The reason this is safe to hand to an autonomous agent is that the wallet enforces your limits, not the agent. If a call asks for more than the per-transaction cap, the payment is refused. If the day's spending is used up, further payments fail until tomorrow. If the destination is not on the allowlist, nothing moves. The agent cannot talk its way past any of this, because the enforcement lives in the wallet you control, not in the prompt.

Every payment settles on-chain and is verifiable on BscScan, so you get a complete, auditable record of exactly what your agent spent and where.

Step 4: Watch the spend

Because each payment is an on-chain transaction, you can reconcile agent spending the same way you reconcile any other Sendbase activity: statements, a transaction log, and the public record on BscScan. If something looks off, you pause the wallet and the agent stops spending immediately.

Where this goes next

Pay-per-call is the primitive. Once agents can pay for a single request, they can subscribe to services, top up usage, and settle with each other, all without a human clicking through a checkout. If you are building agents, or building a service you want agents to be able to pay for, this is the rail to build on. See AI agent wallets for the full feature set, or the developer API to start wiring it up.