Sooner or later an agent hits a paywall. An API returns 402 Payment Required, a data vendor wants four cents for a lookup, a compute endpoint meters by the second. The instinct is to hand the agent a payment method — a card number in the prompt, a Stripe key in an environment variable — and let it sort itself out. That instinct is the problem, and it is worth being precise about why.
A card is an unbounded instrument. It authorizes an amount decided by whoever presents it, against a limit set by a bank, with a chargeback window as the only real control. Handing that to a process whose context window contains text written by strangers is not a payments design; it is an open tab. Anything an agent holds can be read out of it, so the question is never "how do we stop the agent from leaking the instrument" but "how much can be lost when it does."
x402: payment as an HTTP status code
x402 takes the status code HTTP reserved in 1997 and finally gives it a body. The flow is small enough to hold in your head:
- The agent requests a paid resource. The server answers
402with its payment requirements — amount, asset, recipient, network. - The agent signs a stablecoin authorization off-chain and retries the request with an
X-PAYMENTheader. - The resource server forwards that payload to a facilitator, which verifies and settles it on chain, then serves the response.
The signed blob is an EIP-3009 transferWithAuthorization — the reason this works without the agent ever holding gas. The authorization is signed off-chain; the facilitator submits it and pays the gas itself. No wallet top-up in ETH, no nonce management in the agent, no key in the prompt.
What makes it fit agents specifically is that it is stateless and account-free. There is no merchant onboarding, no card on file, no subscription to cancel. A payment is a header on a request, the same way a credential replaces a signup form. Machine-to-machine commerce does not need a checkout page; it needs a value that fits in a header.
Signing is not the hard part. Bounding is.
Every x402 explainer stops at the signature, which is the easy half. A signed authorization moves exactly the amount it names — good — but nothing in the protocol says how many of them an agent may produce, or to whom. Ten thousand correct four-cent payments is a correct protocol doing four hundred dollars of damage.
So the bound has to live outside the payment. In Notlogin's design it lives in two independent places, and the independence is the point: for money to leave, both must permit it.
- Level 1 — the budget ledger. Every credential carries a USDC budget denominated in cents, signed into the payload alongside the scope and expiry. A payment request beyond budget minus spent is refused with a
402. This is the ceiling that protects the human from an over-charging or malfunctioning vendor. - Level 2 — the funded wallet. The human funds one managed wallet, once. Its on-chain balance is the unforgeable ceiling: a compromised agent, a broker bug and a hostile vendor combined cannot move more than what was deposited. Level 1 is policy and can have bugs; level 2 is arithmetic on a chain and cannot.
Two ceilings instead of one is not belt-and-braces theatre. The failure modes are genuinely different — one is "this vendor charged more than agreed," the other is "something has gone very wrong." A single limit answers one of those and silently trusts the other.
The detail that decides whether the cap is real: reservations
A budget check that reads the spend, compares, then writes the payment is not atomic. Fire twenty concurrent requests at it and all twenty read the same total, all twenty see room, and all twenty commit. The cap held only because nobody raced it — which is exactly the condition an agent running a parallel tool loop does not satisfy.
The fix is to make reservations first-class. A payment reserves budget the moment it is authorized, not when it settles, and the reservation is written before it is validated — because once a row is committed, every concurrent request can see it and they all compute the same answer. Order the committed ledger deterministically, keep the prefix that fits, and the rest void themselves and release their hold. Declined, expired and failed payments give the budget back.
Anyone building agent spending controls will meet this race. It is worth designing for on day one, because the symptom — a cap that works in testing and leaks under concurrency — is the kind of bug that only shows up with real money moving.
When the vendor initiates
Not every charge starts with the agent. A vendor may need to bill later for work it already did, which is the card-on-file shape, and card-on-file is where unbounded instruments do their worst damage. The safe version keeps three things pinned: the vendor authenticates with its own secret rather than the user's token, the payout destination is fixed to the vendor's registered address rather than one supplied in the request, and anything above the human's auto-approve threshold waits for an out-of-band confirmation before it settles. A pending charge holds its reservation for a bounded window and then expires, so an abandoned confirmation never strands budget forever.
The through-line: the vendor can request money, and only the human's prior configuration decides whether the request needs them again.
Test on a testnet, because "it worked in staging" is not a payments strategy
Stablecoin settlement should default to a test network — Base Sepolia in Notlogin's case — and require an explicit flip to mainnet. Nothing moves real money until a wallet is actually funded. That default costs nothing and removes the single most expensive class of mistake in this domain: a misconfigured environment variable pointed at production the first time you ran the happy path.
What this buys you
A payment carrying a credential is not an anonymous transfer. The vendor knows which agent, acting for which human, under what scope, against which budget — and can revoke that specific credential without touching anything else the human issued. That is the difference between a leaked card, which is an emergency, and a leaked credential, which is a click.
If you are running agents: fund a wallet, issue a credential with a budget you would not mind losing, and let the agent transact inside it. Start there. If you are a vendor who wants to be paid by agents directly, register and accept credentials — the same verification step that authenticates the caller is the one that carries its money. And if the broker model itself is new to you, start with what an auth broker is.