Open the HTTP specification and walk the 4xx range. 400 Bad Request, used constantly. 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests: every one of them has a job, a lib
Open the HTTP specification and walk the 4xx range. 400 Bad Request, used constantly. 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests: every one of them has a job, a library, a middleware, a muscle-memory reflex in every developer alive.
Then there's 402 Payment Required. It shipped in the earliest HTTP drafts and was immediately marked "reserved for future use." And there it sat. For twenty-five years the web had a status code that said, in plain language, "you have to pay for this," and no standard way to actually do it.
It's not that nobody tried. The web has attempted micropayments roughly once a decade since the 1990s: W3C working groups, browser wallets, tipping widgets, metered paywalls. They all broke on the same rock: the web had no native money. Every attempt bolted payments on from the outside, which meant an account, a credit-card form, a merchant relationship, a $0.30-plus card minimum that made a one-cent API call absurd, and a login wall between you and the thing you wanted. You can't build per-call settlement on rails whose smallest viable unit is thirty cents and whose "hello" is a signup form.
Three things changed at once. Stablecoins gave the internet a unit of account that clears in seconds for fractions of a cent. On-chain settlement gave it finality without a merchant account. And AI agents (programs that call APIs on your behalf, thousands of times, with no human at the keyboard to type a card number) gave it a reason. An agent can't sign up for your SaaS tier. It can't remember your API key. But it can hold a wallet and pay for exactly what it uses, the instant it uses it.
That's the opening 402 was reserved for. The protocol that finally fills it is called x402, and three.ws brought the whole thing into the one place developers actually wire up, test, and ship paid endpoints: VS Code. This is the kind of thing three.ws does: take a piece of the agent economy that was theoretical and ship it as a tool you can install today.
x402 is a payment protocol for developers and agents. Strip away the branding and it is four moves:
No accounts. No API keys. No subscriptions. No "contact sales." Just per-call settlement, on-chain, in the time it takes to retry a request.
The challenge itself is a small JSON envelope (x402 version 2). Its heart is an accepts[] array: one entry per way you're allowed to pay. Each entry names a network in CAIP-2 form (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp for Solana mainnet, eip155:8453 for Base), an asset, an amount in atomic units, a scheme (exact, pay exactly this), and a payTo recipient. A single endpoint can advertise several at once: pay in USDC on Solana, or $THREE on Solana, or USDC on Base. Your client picks the rail it can satisfy and signs for that one.
This is the part that matters and the part that's easy to miss: the price and the payment instructions are data, not a webpage. That's what makes 402 finally usable. A human never has to read it. A fetch wrapper reads it, a wallet signs it, and the call goes through, or an autonomous agent does the same thing at three in the morning with no one watching.
Here's the workflow the tooling forgot.
You find a paid endpoint. To understand what it costs, you curl it and read a raw 402 blob by eye. To pay it, you copy an amount and an address into a separate wallet app, sign, wait, copy the transaction hash back. To confirm it settled, you open a block explorer in a browser tab. To publish your own paid endpoint, you clone a starter repo, wire up a facilitator, and hope you got the challenge format right. Four tools, three context switches, and a wallet holding real money one alt-tab away from the code you're writing.
Every one of those steps is something a developer does in the editor, or would, if the editor could do it. Discovering an API, reading its contract, calling it with a test body, checking the response, scaffolding a new one: that's the inner loop of building against any API. Payments were the one part exiled to other windows, which is exactly why paid APIs felt heavier than free ones even when the payment itself takes a second.
So we collapsed it. The x402 Pay-per-call APIs extension puts the entire loop (discover, inspect, pay, receive, publish) inside VS Code. The wallet lives in your OS keychain, the receipt renders next to the response, and the endpoint you scaffold is a file in your workspace. Nothing leaves the editor. That's not a convenience feature; it's the difference between paid APIs being a first-class thing you build with and a chore you avoid.
The extension ships as three-ws.vscode-x402 (v0.2.0, Apache-2.0, VS Code 1.85+). Its own description is blunt about the scope:
"Browse the x402 bazaar, decode 402 payment challenges, and pay per call for paid APIs and MCP tools in USDC or $THREE on Solana and Base, without leaving VS Code."
Four moves, all in the editor.
Run x402: Inspect Endpoint (decode 402 challenge), paste a URL, and the extension makes an unpaid request and decodes whatever 402 comes back. It reads the challenge from the payment-required / x-payment-required header (base64 JSON) or the response body, then lays out every accepted requirement in plain terms: network, asset, payment scheme, price converted to USD, and the payTo address. The one requirement your wallet can actually satisfy is flagged, and each entry is tagged with its rail: Solana or EVM.
No wallet. No signing. No configuration. Inspecting is a pure read: you can point it at any x402 endpoint on the internet and see exactly what it would cost before you decide to spend a cent. Free endpoints just return their result; there's nothing to decode.
Run x402: Pay & Call Endpoint (or hit "Pay & call" on a service in the sidebar) and you make a genuine paid request from a panel. You get a method selector and a JSON body field; the panel shows the price, and then three things happen before any key touches the request:
Then the response body and the on-chain receipt render inline: status, amount paid, paying address, token, network, and the transaction signature. The whole round trip (challenge, sign, retry, settle, receipt) happens in the panel, and you never leave the file you were in.
The x402 Bazaar view lives in the activity bar. Point it at a discovery origin (threewsX402.origin, default https://three.ws) and it lists paid HTTP APIs and MCP tools pulled live from the bazaar's discovery API, which itself merges multiple facilitator feeds (PayAI and Coinbase CDP) into one normalized list. Filter by type (http / mcp), price, network, and tag; run a full-text search with x402: Search Bazaar; click any service to open its detail panel and pay it. Discovery and payment are the same surface: find a tool, read its contract, call it, all in the sidebar.
Run x402: Scaffold a Paid Endpoint, answer three prompts (URL slug, price in USD, description), and the extension generates a self-contained handler at api/x402/<slug>.js. It follows the canonical paidEndpoint() pattern from the platform's own server library: it advertises a 402 challenge on an unpaid request, and runs your handler only after payment verifies and settles on-chain. The generated handler echoes the request as proof the whole thing is wired end to end: you replace that body with your real logic and you're a paid-API publisher. The scaffold prices in USDC on Base out of the box; adding the Solana / $THREE rail is one option flag on the server side (below).
The extension sends your request unpaid (free endpoints just work), parses the 402, and picks a payable requirement across both rails, honoring your network and token preferences. Then, depending on the rail, one of two payment paths runs.
For Base and other EVM chains, the extension uses the vendored @three-ws/x402-fetch client to sign a USDC transferWithAuthorization (EIP-3009), structured and signed as EIP-712 typed data. EIP-3009 is the right primitive here: it lets you authorize a transfer by signature without a separate on-chain approve, so a single locally-produced signature is the payment. The message carries from, to, value, a validAfter / validBefore window, and a random nonce: signed once, submitted once, never replayable.
What's notable is that @three-ws/x402-fetch is genuinely zero-dependency ("dependencies": {}, verified). The entire cryptographic stack is inlined:
The only outside primitives are HMAC-SHA256 and SHA-256, taken from Web Crypto (globalThis.crypto.subtle), present in Node 18+ and every modern browser. Nothing exotic, nothing to audit but the code in front of you, and no payment SDK pulled at runtime.
For Solana, the extension does not use x402-. It uses the real @x402/svm ExactSvmScheme, the same buyer that powers @three-ws/x402-mcp in production. It loads your Solana key (base58 or JSON byte array), builds a signer with @solana/kit, registers the scheme against solana:*, filters the challenge's accepts down to your preferred token, and signs a real SPL transfer of the selected asset:
No mocking, no stub: the same settlement path a headless agent would use.
Either way, the extension retries the request with an X-PAYMENT header carrying the base64-encoded payment payload. The merchant verifies it, does the work, settles on-chain through a facilitator, and returns the result plus a receipt in the x-payment-response header. The extension decodes that receipt and renders it inline (token, network, transaction signature) right under the response body.
The default facilitator that actually settles both Solana and Base is PayAI (facilitator.payai.network); Coinbase CDP shows up as one of the discovery feeds the bazaar merges, not as the settler. Any route can override the facilitator, so nothing is bolted to a single provider.
The threat model here is simple to state: there's a private key on a developer's machine that can spend real money, and the editor is asking it to sign things. Every design choice follows from taking that seriously.
The guidance the extension itself gives is deliberately blunt: use a dedicated, low-balance wallet. Treat it like the petty-cash drawer, not the vault. The point of per-call micropayments is that the amounts are tiny, so the wallet backing them should be too.
A detail worth pulling out: on the merchant side, @three-ws/x402-server can advertise both USDC and $THREE in a single 402 challenge. Turn on acceptThree and a Solana endpoint emits two accepts (USDC first, then $THREE) inside the same envelope. The buyer picks. That's the whole point of the accepts[] array being plural: a publisher doesn't have to choose their audience's currency in advance. A USDC-holding agent and a $THREE-holding agent hit the same URL and each pays in what it carries. $THREE is the platform's native token and the one it promotes; USDC is the neutral stablecoin rail. The protocol lets both ride in one response, and the extension routes to whichever you told it to prefer.
The extension has no dependency on any specific provider. Point it at any compliant x402 endpoint, or any bazaar that serves the discovery API. It's the open protocol all the way down. Discovery is optional: inspecting and paying a single URL needs zero configuration, no origin, no account. The vendored client means there's no payment SDK fetched at runtime and no service you're implicitly trusting beyond the merchant you chose to pay. That openness is a point of pride: three.ws built the extension to serve the whole x402 ecosystem, not to fence it in. It works with any compliant endpoint or bazaar, three.ws's own or anyone else's, which is exactly how a tool from one team becomes infrastructure for everyone.
The scaffold command is the fast path, but here's the shape of what it produces, because it's the same server library any publisher uses. @three-ws/x402-server's paid() wrapper gates a handler behind payment:
import { paid } from '@three-ws/x402-server'; export default paid( { price: '10000', // 0.01 USDC, in atomic units (6 decimals) asset: 'usdc', acceptThree: true, // also advertise $THREE in the same 402 payTo: { solana: '<your-sol-addr>', base: '0x<your-base-addr>' }, }, async (req, res) => { // Runs ONLY after payment verifies and settles on-chain. const body = await readJson(req); return { ok: true, result: doTheWork(body) }; }, );
An unpaid request gets a 402 with your price on both rails. A paid request gets verified against the facilitator, runs your handler, settles, and returns the work with a receipt. The library also gives you buildChallenge, verifyPayment, settlePayment, and a feeSplit helper that carves a platform fee out of the price without ever marking it up to the buyer. The whole thing is zero-dependency and ESM, and it defaults to the PayAI facilitator for Solana + Base; override per route if you want your own.
That's the symmetry the extension is built around: x402-fetch / @x402/svm on the buyer side, x402-server on the seller side, and one editor that speaks both. You can inspect someone's endpoint and scaffold your own in the same window, minutes apart.
This extension is one surface of three.ws, an open-source, browser-native platform for 3D AI agents that can earn, pay, and coordinate. The same team that wired 402 into your editor is building the whole loop around it: give an AI a body, a brain, an on-chain identity, and a wallet, then let agents transact with each other in real time. It ships from a single npm-workspaces monorepo, published under the @three-ws scope. $THREE (Solana: FeMbDoX7R1Psc4GEcvJdsbNbZA3bfztcyDCatJVJpump) is the native token.
Type a prompt and Forge turns text, an image, or a sketch into a textured, rig-ready 3D model: free draft tier, no account. Rig it, animate it, give it an LLM brain, embed it anywhere with <agent-3d>, register it on-chain (ERC-8004), and let it pay for tools and get paid for skills over x402. The extension you just installed is the payments edge of that platform, pulled out so any developer can use it standalone. You don't need a single 3D asset to get value from it.
Everything the platform can do is exposed over the Model Context Protocol, listed in the official MCP registry: 32 install-and-run servers on npm (stdio) under @three-ws, two more top-level npm servers (@three-ws/mcp-server, the full 3D + agent toolkit; @three-ws/mcp-bridge, an x402 HTTP→stdio bridge that auto-pays endpoints), and 7 hosted remote endpoints (Streamable HTTP, nothing to install). A sampling of the fleet:
The @three-ws scope holds more than 70 published packages: zero-dependency, pure-ESM, typed, and tested (216 green tests across the SDK suite, per the repo's own STRUCTURE.md). Each wraps a live platform capability into a single import:
three.ws builds in the open and earns its integrations. The reach is real and growing:
Open the Extensions view, search x402, and install threews.vscode-x402, or run ext install nirholas.vscode-x402. Requires VS Code 1.85+. You only need a funded wallet to pay: a Solana wallet holding $THREE or USDC, or a Base USDC wallet. Inspecting endpoints and browsing the bazaar are free and need no wallet at all.
It's free, on the VS Code Marketplace now → https://marketplace.visualstudio.com/items?itemName=threews.vscode-x402
Explore it:three.ws · MCP registry · github.com/nirholas/three.ws · $THREE on Solana FeMbDoX7R1Psc4GEcvJdsbNbZA3bfztcyDCatJVJpump
The extension is the easiest door into a much bigger build. three.ws is giving AI agents a body, a brain, an identity, and a wallet, and wiring them into an economy where they can actually pay each other. Payments an agent can make on its own, identity it can carry, skills it can sell: three.ws is turning each of those from a whitepaper idea into something you can install and use today, all in the open, all under @three-ws. This is just the first piece you can hold.
Twenty-five years is long enough. Let's use the code.
Do I need crypto to use it? Not for inspecting or browsing: decoding a 402 challenge and searching the bazaar are pure reads with no wallet. You only need a funded wallet to actually pay a call.
Which chains and tokens? USDC or $THREE on Solana (via the real @x402/svm exact scheme), and USDC on Base (via @three-ws/x402-fetch, EIP-3009). The extension auto-routes to whichever rail your challenge and preferences point at.
Where does my private key go? Into your OS keychain via VS Code SecretStorage: never settings.json, never disk plaintext, never a log. It's loaded only at the moment of payment.
What stops an accidental overspend? A per-call spending cap (default $0.10) checked before signing, plus a per-payment confirmation showing the exact amount, token, network, and payer. Use a dedicated low-balance wallet.
Is there vendor lock-in? No. It speaks the open x402 protocol to any compliant endpoint and any compliant bazaar. The payment client is vendored and zero-dependency: no SDK fetched at runtime, no service trusted beyond the merchant you chose to pay.
Can I publish my own paid API? Yes: one command scaffolds api/x402/<slug>.js around @three-ws/x402-server's paid() wrapper. Your handler runs only after payment settles on-chain. You're a publisher in about a minute.
