Welcome to the NZRT Wiki Podcast. Today we’re looking at x402 Overview.

So let’s start with the basics. x402 is an open protocol designed for machine-to-machine HTTP micropayments. The name comes from HTTP status code 402, which is called Payment Required — a code that’s been sitting in the HTTP specification for decades but was never seriously put to use. Until now.

The protocol was specified by Coinbase and lives on GitHub, and there’s a facilitator service running at x402.org that handles the verification side of things. We’ll get to what a facilitator does in a moment.

First, why does this exist? Think about how APIs are monetised today. You need to create an account, manage API keys, set up a billing system, choose subscription tiers, and build rate limiting infrastructure. That’s a lot of overhead — especially for automated systems or AI agents that just want to call an endpoint and get a result.

x402 strips all of that away. There are no accounts, because the payment itself acts as your authentication. There are no API keys, because your wallet signature proves you’ve paid. There’s no billing system, because payments happen per request on-chain. And crucially, it’s native to AI agents — machines can pay other machines automatically, with no human in the loop.

So how does it actually work? Here’s the flow. A client makes a request to a paid endpoint. The server responds with that HTTP 402 Payment Required status, and includes a set of payment requirements — how much to pay, which network to use, and which wallet address receives the funds. The client then creates a signed USDC transfer using a standard called EIP-712, which is a typed signature format for Ethereum-based transactions. The client attaches that signed authorisation to a second request and retries the call. The server takes that payment header and forwards it to a facilitator, which is an off-chain service that checks the signature. Once the facilitator confirms everything is valid, the server delivers the content.

The important thing to note is that verification happens off-chain, so there is no gas cost just to verify a payment. And there’s only one extra round-trip per uncached request, which keeps latency manageable.

Now let’s talk about where you’d actually use this. There are five key use cases. First, API monetisation — any HTTP endpoint can become a pay-per-request service. Second, AI agent tooling — agents can automatically pay for the tools and data they need. Third, knowledge base access — you could charge a small amount per document retrieval, like a wiki search. Fourth, metered compute — paying per AI inference, per render, or per export. And fifth, content paywalls — charging a micropayment for access to an article, a report, or a dataset.

The protocol is built on two specific technologies that make micropayments practical. The blockchain is Base, an Ethereum Layer 2 network backed by Coinbase. Gas fees on Base are fractions of a cent, which is what makes tiny payments economically viable. The currency is USDC, Circle’s stablecoin that tracks one-to-one with the US dollar and is native to EVM-compatible chains. On Ethereum mainnet, a payment of a fraction of a cent would cost more in gas than the payment itself — Base solves that entirely.

Finally, there are six key concepts worth locking in. The resource server is the HTTP server that enforces payment — it responds with the 402 and ultimately delivers your content. The facilitator is the off-chain service that verifies payment signatures, acting as the trust layer between client and server. Payment requirements are the details returned in that 402 response — the amount, network, asset type, and payee address. The payment authorisation is the signed transfer the client attaches to its retry request. The payee is the EVM wallet address receiving the USDC. And the payer is the EVM wallet address doing the paying — it signs the transfer to authorise the whole thing.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.