How does an AI agent pay for an API call?
An AI agent trying to use a paid API hits a wall that has nothing to do with intelligence. It cannot sign up.
Signup assumes a person: an email to confirm, a card with a billing address, sometimes a captcha or an SMS. An agent has none of that. What it can have is a wallet — and if a service is willing to be paid by wallet, the entire onboarding problem collapses into a single HTTP exchange.
The status code nobody used
HTTP has reserved 402 Payment Required since the early nineties and essentially never used it. There was no interoperable way to say what payment, so servers returned 401 or 403 and pointed humans at a pricing page.
The x402 pattern fills in the missing half. An unpaid request gets 402 back, and the response body carries a machine-readable description of the payment: how much, in which asset, to which address, on which chain. That is enough for a client to act without reading documentation. It pays, then retries the same request with proof attached, and gets the resource.
Two round trips, no account, no key issued ahead of time. On BT365 the 402 response carries that payment block alongside the standard error shape, so a client that does not understand x402 still sees a well-formed HTTP error rather than something malformed.
Two ways to prove you paid
There are two flavours in practice, and the difference matters more than it looks.
Proof by transaction hash. The agent sends the payment on-chain itself, then presents the hash. The server verifies the transaction really happened, went to the right address, carried the right amount, and has not been presented before. This works and is easy to reason about, but it requires the agent to hold native gas on the settlement chain and to wait for confirmation before it can retry.
Proof by signed authorisation. The agent instead signs an off-chain message — under EIP-3009, a transferWithAuthorization — that authorises the service to pull a specific amount. The signature travels in a header. The server verifies it cryptographically, then submits the transfer itself and pays the gas.
The second removes a whole category of failure. The agent needs the stablecoin and nothing else: no gas token on the settlement chain, no confirmation wait, no separate funding step for a chain it may never otherwise touch. In our implementation the platform's own wallet pays that gas, and it costs a fraction of a cent per call — cheap enough that eating it is simpler than making every caller solve gas provisioning.
The parts that stop it being exploitable
A payment scheme is only as good as its replay protection, and this is where most of the real engineering sits.
A signed authorisation is a bearer instrument. Anyone who obtains it can submit it. So each carries a nonce, and the nonce is enforced by a unique database index rather than by a lookup-then-insert check. That distinction is the whole thing: a check-then-act can be raced by two concurrent requests presenting the same authorisation, and both will pass the check before either writes. A unique constraint cannot be raced — the second insert simply fails.
Pricing fails closed. Prices are stored per endpoint, and asking the price of an endpoint that has no price configured throws rather than returning zero or a default. The failure mode of the alternative is a new endpoint shipping without a price row and being silently free until someone notices. Throwing means an unpriced endpoint denies access instead of giving itself away.
Amounts are validated as integers, in the asset's smallest unit. No floats anywhere near a payment amount.
Not the only door
Worth saying, because a payment-per-call scheme is not always the right fit: x402 is one of three ways into the same API surface here.
An agent can pay per call as described. It can present a pre-issued MCP key, which suits a caller with an ongoing relationship who would rather not sign a payment every time. Or it can fall through to a sponsored allowance, where the platform covers a bounded amount of usage — useful for evaluation, where asking someone to fund a wallet before they can see whether the API is any good is a poor trade.
They resolve in one guard, and the endpoint does not care which one you used.
Why bother supporting this at all
The honest answer is that the audience is small today and structurally growing, and the cost of being early is low.
An agent that can pay for a call can also discover what it is paying for. Publishing a machine-readable description of your service, at a well-known location, alongside a payment method an agent can complete unattended, makes you callable by software that was not written with you in mind. That is a different distribution channel from search — and it is one where almost nobody has bothered to show up.
For a service whose value is execution rather than content, that asymmetry is the interesting part. A human reads an article and might sign up. An agent reads a manifest and can be a customer in the same request.
Part of our guide to making an API usable by AI agents.
BT365 exposes its trading surface to agents over x402 and MCP, with machine-readable discovery. Explore the platform or read the API documentation.