What happens in those 1.4 seconds
The x402 protocol reuses a status code the web reserved decades ago [1]. RFC 9110 describes 402 Payment Required in one sentence: it is "reserved for future use" [5]. The x402 README calls itself "an open standard for internet native payments" and lays the flow out as fixed steps, ending in a 200 OK that carries a payment response header [1].
Here is that flow as it ran against our endpoint. The agent sent a plain GET. Our server answered 402 with a machine-readable body: the asset (USDC), the exact amount, the address to pay, and one entry per network we can settle on. The agent picked USDC on Base, signed an authorization for that amount, and retried the same GET with a PAYMENT-SIGNATURE header, the name the x402 client and server docs specify [9]. Our server asked the facilitator to verify, then to settle, and returned the resource with a PAYMENT-RESPONSE header naming the Base transaction. That round trip is the 1.4 seconds we measured.
Two design choices make x402 payments fast in our experience. The agent never waits for a block before retrying, because the signature is the payment. And the seller never touches a private key, because the facilitator is only "the transaction broadcaster" and "cannot modify the amount or destination" [2]. The real request and response pair is on our x402 page for agents; seller setup is in how to get paid by AI agents.
Who pays the gas: the EIP-3009 trick
On an EVM chain a token transfer costs the sender gas in the native coin, so an agent holding only USDC on Base would be stuck. The x402 exact scheme solves this with EIP-3009, a standard for moving tokens "via a signed authorization" [4]. The holder signs a message naming the recipient, amount, validity window and nonce; anyone can submit it, and the contract moves the funds. EIP-3009 says it outright: the user can "delegate the gas payment to someone else" [4].
In x402 payments that someone else is the facilitator [2]. The exact scheme spec states that settlement "is performed via the facilitator calling the transferWithAuthorization function" with the client's signature [2]. So the agent pays no gas, and neither does the seller. The facilitator pays it and recovers the cost through its own pricing. On SpendTheBits the payment lands at an address only your device's keys control; we never hold it.
It is the same mechanism behind gasless USDC transfers for ordinary wallets.
What the facilitator costs, and what SpendTheBits costs
Our seller endpoint settles through the Coinbase Developer Platform facilitator. CDP publishes its pricing: the first 1,000 onchain transactions a month are free, each additional one costs a tenth of a cent, and "Payment verification is always free" [6]. Pricing is "based on onchain activity, not payment requests", so unpaid 402 challenges cost nothing [6]. The x402 docs add that CDP's facilitator "offers fee-free settlement on Base and Solana" [3].
Which networks a seller can offer depends on the facilitator. CDP lists Base, Polygon, Arbitrum and World on the EVM side, plus Solana, and warns that "Support can change as new networks and schemes are added" [6]. Our seller code reads the facilitator's live supported list rather than hardcoding it: Base first for every seller, then Polygon and Arbitrum, and Solana with its own fee payer. Base was the cheapest and fastest path we measured.
Our own pricing is stated in ranges on public pages by policy. A small service fee, under 1%, applies only when a payment actually settles on SpendTheBits; nothing is taken on an unpaid 402, a failed verification or a replay. The in-app Fees screen shows the exact figure, and our pricing page explains the ranges.
Where the latency goes
A settled payment in 1.4 seconds sounds too quick for a blockchain, so here is what we observed. Signing is local and takes milliseconds. The verify call is off-chain: the exact scheme spec requires the facilitator to confirm that "the signature is valid and recovers to the authorization.from address", that the balance is sufficient, that the amount and validity window meet the requirements, and that "the Token and Network match the requirement" [2].
The settle call is the only on-chain step. The facilitator broadcasts the authorization and "waits for the payment to be confirmed on the blockchain" [3]. Most of our 1.4 seconds was waiting for one Base block to include the transaction. The seller's own work, building the 402 body and forwarding two facilitator calls, was a rounding error in our logs.
Two notes for builders. Verify before expensive work and settle after, the order the x402 flow prescribes [1]. And expect settlement time to track the destination chain's block time.
Replay, wrong network, wrong amount: three attacks, three refusals
After the first successful payment we tried to break our endpoint. These are the three failures every seller of x402 payments must handle, and how each played out in our run.
Replay. We resent the identical request with the same PAYMENT-SIGNATURE header. Our server answered in about 0.1 seconds with the same receipt and the same Base transaction hash, and no second transfer happened. Two things make this safe. EIP-3009 uses "random 32-byte nonces", and the token contract will not honour a nonce twice [4]. On top of that, our seller records every settled nonce per resource, so a replay never reaches the facilitator, and an authorization already spent on a different resource gets a fresh 402 from our server.
Wrong network. Our 402 lists one accepts entry per network. If an agent signs for a network we did not offer, verification fails on the Token and Network check [2], and our server returns a fresh 402 with the valid list. We also refuse to build a 402 for a network the facilitator's list omits, so a seller can never advertise a rail it cannot settle on. Token identity matters too: native vs bridged USDC explains why an authorization on the wrong contract is worthless.
Wrong amount. We sent an authorization for less than the price. Verification failed on the amount check, no settlement was attempted, and our server sent a fresh 402 quoting the correct amount. The resource was never served. The facilitator cannot fix an amount for the client because it "cannot modify the amount or destination" [2], which is what lets a seller trust the flow without trusting the facilitator with custody.
Getting found: the Bazaar and the discovery documents
A payable endpoint nobody can find earns nothing, so we tested both discovery paths. The first is the x402 Bazaar, which CDP describes as "a catalog of payment-gated services discovered by the CDP Facilitator" [7]. It offers search by intent, browsing, and lookup by a merchant's payTo address, and "Bazaar discovery is public", with no API key needed [7]. Our proof resource appeared in the catalog about 30 minutes after the first payment carrying the discovery extension.
The second path is documents a crawler can read. We serve a manifest at /.well-known/x402 that declares an x402Version, names the resource server, and lists each payable resource with its method, description and price [8]. We also publish llms.txt for model-driven agents. Both list only public resources on our own domain, because a manifest that points elsewhere is a phishing vector.
Building the agent side instead? See our how to pay an x402 API from your wallet: paste the URL into Send, review, sign on your device. The AI agent builders page covers both directions.
What this means if you want agents to pay you
The economics of x402 payments are unusual for anyone used to card processing, in our experience. There is no monthly minimum, no chargeback, and no settlement delay in days. The costs that exist are mostly not yours: gas is paid by the facilitator, verification is free, and settlement is free or a tenth of a cent depending on volume and network [6]. What you pay for is correctness. In our experience a 402 body with the wrong amount format, or an accepts list naming a dropped network, silently turns every customer away.
That is the work SpendTheBits does for you. Your SpendTheBits @handle becomes an x402-payable endpoint, the accepts list comes from the facilitator's live capabilities, replays are answered idempotently, and every payment settles to an address only your keys control. SpendTheBits takes a small service fee, under 1%, only when money lands.
One cent on Base is a tiny payment, but a complete one: every part of the protocol exercised against real infrastructure and real money. That is the bar we hold before we call x402 payments live.
Hold your own keys, keep the yield, skip the middleman.
SpendTheBits is a fully non-custodial wallet for 13 chains, free on iOS and Android.