x402 lets AI agents pay for APIs with on-chain USDC over HTTP 402

A developer post on dev.to documents a working implementation of x402, a payment scheme that lets AI agents buy API access with on-chain USDC, deployed and tested on Base mainnet.

The authors frame the problem plainly: autonomous agents increasingly need to pay for data feeds, compute, storage and services offered by other machines, but existing payment rails such as Stripe and PayPal assume a human participant. Accounts, cards, API keys, approval flows and identity checks all sit awkwardly with software acting on its own behalf.

x402's answer is to turn the HTTP 402 Payment Required status code from a rarely seen error into an actual payment handshake.

How the flow works

According to the post, the exchange runs as follows. The agent requests a paid resource. The server replies with a 402 status plus machine-readable payment terms: the amount, the network, the recipient address and the asset. The agent's SDK signs an EIP-3009 TransferWithAuthorization message off-chain, then retries the original request with the authorization attached in an X-PAYMENT header.

The server forwards that signature to a facilitator, which verifies it and settles the transfer on Base. The facilitator pays the transaction gas — recovering the cost through a commission model — so the agent never submits its own on-chain transaction per request. Once settlement is confirmed, the server returns the resource with an ordinary 200 response, and the seller holds USDC.

EIP-3009 signatures at the core

The signed message carries the payer's address, the seller's address, the USDC amount expressed with the token's six-decimal precision, a validity window, and a nonce that prevents the same authorization from being replayed. The facilitator checks that the nonce is unused before submitting anything to the chain.

In this implementation the facilitator runs as a Fastify module alongside the API itself, which the developers say keeps the deployment self-contained rather than depending on a shared public facilitator service.

Matching SDKs in Python and TypeScript

The team has open-sourced two SDKs that hide the handshake from the caller. In Python, a client initialised with a private key exposes a single fetch call; when the target API answers with 402, the SDK discovers the payment terms, signs, retries and returns both the paid response and a flag confirming payment. A TypeScript SDK mirrors the same shape, so agents in either language get an identical flow.

Discovery, subscriptions and abuse controls

For agents to find priced services, the platform exposes a /discover endpoint publishing a machine-readable catalog. The example payload lists each resource with its payment scheme, network, recipient address and a maximum amount — 50000 units, or $0.05 at USDC's six decimals.

Layered on the pay-per-request model are subscription tiers that lower the platform's cut: a free tier at 10 percent commission, a $29-per-month Pro tier at 5 percent, and a $299-per-month Enterprise tier at 2 percent. Subscriptions themselves are handled conventionally — sign-up through Clerk, checkout through Stripe, with webhooks writing the tier and commission percentage into the database, where the x402 middleware reads them at request time to split each payment between seller and platform.

The post also describes moderation tooling: organizations carry a suspension flag in the database, suspended accounts receive HTTP 403 on payment requests and are dropped from the discovery catalog, and an hourly cron job plus webhook events can trigger suspensions automatically.

Verified on mainnet

The developers report a completed end-to-end payment on Base mainnet, chain ID 8453: $0.05 in USDC for a market-data endpoint, with the transaction hash published and the on-chain commission recorded at 5 percent, confirming that Pro-tier pricing was applied. An earlier testnet transaction was also logged.

Why it matters

Agent-to-agent commerce needs a payment rail that software can actually use. x402 maps payments onto the request-response pattern agents already speak, replacing accounts and approval flows with a wallet and a signature, while the facilitator-pays-gas design via EIP-3009 sidesteps the per-request transaction costs that make raw wallet payments impractical for micropayments. This particular implementation is a single platform's build, and the write-up is its own account of the work. But as a demonstration that a paid API can be consumed by an autonomous client with a few lines of code, it points toward a web where metered, machine-to-machine services are as composable as free ones.