x402 Spending Limits: Can You Cap What an AI Agent Pays?

Short answer: no. x402 has no spending limits, and that is by design. The protocol defines how a server quotes a price and how a client settles it, and nothing else. An agent using a naive x402 client will sign whatever amount the server puts in the 402 response, whether that is a fraction of a cent or ten thousand dollars. Limits have to come from the layer you put around x402: your client, your wallet, or a control plane in front of both.

Last updated July 2026.

What x402 actually does

x402 revives the long-dormant HTTP status code 402 Payment Required. A server that wants to charge for a request answers with a 402 and a machine-readable quote: this is the price, this is the asset, this is the address, pay and try again. The client pays, retries with proof of payment, and gets the resource. Settlement happens on-chain in stablecoins, typically USDC, on networks like Base, Polygon, Arbitrum and Solana.

It is a genuinely good piece of engineering for one specific job: agent-to-API micropayments. There are no accounts, no API keys, and no onboarding, because a wallet address is the identity. There are no protocol fees. Coinbase contributed x402 to the Linux Foundation in April 2026, which launched the neutral x402 Foundation with backing from Google, Microsoft, Visa, Mastercard, Stripe, Cloudflare and AWS, so this is not a fringe experiment anymore.

For payments of a cent or two, this is the correct architecture. Card interchange makes charging a cent economically absurd. x402 makes it trivial.

Can you set spending limits on x402?

Not in the protocol itself. x402 specifies the quote and the settlement, not the policy. There is no field for a daily cap, no per-merchant allowlist, no velocity rule, and no notion of "this agent may spend up to this much this month." The specification simply does not model any of that, and the maintainers do not claim it does.

The practical consequence is that the ceiling on an x402 agent's spend is whatever is in its wallet. If you fund a wallet with 5,000 USDC and hand the key to an agent, the agent can spend 5,000 USDC. The only hard limit is the balance.

Why the missing limit is a real risk, not a theoretical one

An agent that pays per request can make a lot of requests. Consider a research agent that pays each time it fetches a page from a web scraping API that returns clean, LLM-ready data. At a tenth of a cent per call that is cheap, right up until a retry loop fires the same call forty thousand times because a downstream parser keeps throwing. Nothing in x402 notices. Every one of those payments is individually valid, individually tiny, and individually irreversible.

The second failure mode is price, not volume. The server sets the quote. A compromised, buggy, or simply greedy endpoint can answer with a 402 quoting a much larger number than usual, and a naive client signs it. The agent has no baseline for what the call "should" cost. We wrote about the adjacent version of this problem in prompt injection and agent spend, where the attacker steers the agent rather than the price.

Are there chargebacks with x402?

No. x402's own FAQ is direct about this: the exact scheme is a push payment, irreversible once executed. There are no chargebacks and no dispute process. If an agent overpays, or pays the wrong party, or pays for something it never receives, the only remedy is a compensating transfer that the seller chooses to make. Nobody can claw the money back for you.

This is the sharpest difference from card rails. When an agent pays with a card, the dispute machinery of the card network still exists behind it. That is not a small thing to give up, and it is worth being clear-eyed that x402 gives it up deliberately in exchange for speed and near-zero fees.

How do you actually cap an x402 agent?

There are three places you can put a ceiling, and they are not equally strong.

The first is the one most teams reach for and the one that fails first. Telling an agent in its system prompt not to spend more than 20 dollars is not a spend limit. It is a request, made to a system whose entire job is to be talked into things.

Thin wallet funding is genuinely useful and you should do it regardless. It is the crypto equivalent of not handing someone the company card. But it only bounds the total loss, and it says nothing about rate, vendor, or purpose.

The durable answer is to move the decision out of the agent entirely. A control plane sits between the agent's intent and the settlement: the agent asks to pay, the policy engine checks the amount, the counterparty, the velocity, and the agent's remaining budget, and only then does money move. Our spend controls work this way, and anything above your threshold can pause for human approval instead of being declined outright.

Should you use x402 at all?

Yes, for what it is good at. This is not an argument against the protocol. If your agents are paying pennies to APIs, x402 is the right rail and the alternatives are worse. The mistake is treating a payment protocol as if it were a governance system.

The honest framing is that x402 and a control plane are complementary, not competing. x402 answers "how does the money move." A control plane answers "should it move at all, how much, to whom, and who signs off." You want both, and we lay out that split in detail on our Coinbase x402 comparison.

What about the audit trail?

On-chain history is not an audit trail in the sense a finance team means. The chain records that an address paid another address. It does not record which agent that was, which human owns it, what the agent was trying to accomplish, which policy allowed it, or who approved it. When a controller asks "why did we spend 4,000 dollars on data last month and who authorized it," a block explorer cannot answer.

That attribution has to be written by the layer that made the decision, which is another reason the policy check and the audit trail belong together.

Common questions

Is x402 free?

The protocol charges no fees. You pay network fees, which on Base or Solana are a fraction of a cent. Facilitators may charge: Coinbase's facilitator has been free for the first 1,000 transactions a month and 0.001 US dollars per transaction beyond that since January 2026. Other facilitators set their own terms.

Do agents need wallets for x402?

Yes. Payment is on-chain, so the agent needs a funded wallet and a way to sign. That does not mean handing an agent a private key with your treasury behind it. Give it a scoped wallet with a small balance and a policy in front of the spend, which is the whole idea behind an agent wallet.

Can you build spending limits on top of x402 yourself?

You can, and some teams do. You wrap the x402 client so every quote passes through your own checks before it is signed. The work is not the first check, it is everything after: per-agent budgets, velocity rules, counterparty allowlists, an approval path for the edge cases, and an attributed record of every decision. That is a control plane, and building one is a bigger project than it looks.

Does x402 support refunds?

Not natively. A refund is just a new payment from the seller back to the buyer, entirely at the seller's discretion. There is no protocol-level reversal.

The takeaway

x402 has no spending limits because it was never meant to have them. It is a clean, fast, cheap way for an agent to pay an API, and it deliberately stops there. The cap, the approval, the vendor allowlist, and the record of who authorized what are your responsibility, and putting them in the agent's own code is the one place they reliably fail. Fund thinly, enforce policy outside the agent, and keep the receipt. Next, compare the x402 alternative for teams that need governance, read how the same pay-per-request pattern shows up in MCP payments and paying per tool call, or read agentic commerce explained for how x402, AP2 and ACP fit together.