HTTP's status code registry has had 402 reserved for "Payment Required" since the earliest specs, and for roughly three decades it did almost nothing - unused long enough that it became a trivia fact rather than a working status code. That it existed at all, this early, says something about API economics that's worth taking seriously on its own, separate from the history of why it sat idle.
Every other way the web has monetized access bolts payment on from outside the protocol: sign up for an account, get billed monthly, maybe get an API key gated behind a plan tier picked from a pricing page. None of that lives in the HTTP exchange itself - the request and the payment are handled by two separate systems that have to be kept in sync by whoever built the integration. 402 encodes a different idea: that a response to a single request could just say "this costs X," inline, as part of answering the request. The short history of the code itself covers how it got into the spec; the economic idea embedded in it - price as a response, not a side-channel - is the part that outlived three decades of the code doing nothing.
An inline 402 response is only useful if whatever's on the other end can actually pay in response to it, in the same request-and-retry cycle, without a human stepping away to enter a card number. No payment rail cheap or fast enough to clear a few-cent charge, synchronously, inside an HTTP exchange existed for most of that thirty years. Card networks are built around human checkout flows with fixed per-transaction costs that don't scale down that far; micropayments generally didn't work for human commerce for the same underlying reason. Stablecoin settlement on a low-fee chain is what finally makes "sign a payment and retry in the same breath" a realistic thing to build - see why USDC on Base specifically.
Once the price for an action is something a caller can read directly off an API response instead of off a pricing page a human skimmed once, a program can act on it. It can compare the price against what the task is worth, decide whether to proceed, and pay inline - no separate account lookup, no plan tier check. That's the capability discovering live prices programmatically is actually about: not a nice developer-experience feature, but the precondition for a caller that isn't a person to make its own purchasing decision at all.
Price-as-a-response-field is also what makes pay-per-call pricing practical instead of theoretical, and what makes genuinely small prices - cents, not dollars - worth charging at all. None of that required a new idea about pricing. It required the one idea that was sitting in the HTTP spec since the beginning to finally have a caller that could act on it without a human in the way, and a rail that could settle it for less than the transaction was worth.
Compare it to how most paid APIs work today, 402 or no 402: a developer signs up, gets an API key, and the key is matched server-side against a plan that was chosen separately, often by a different person, weeks before the first call ever happens. The price was decided once, in advance, disconnected from any specific request. 402 proposes the opposite ordering - decide what a specific response costs at the moment of answering it, and let the requester decide whether to pay for that specific answer. That ordering only matters if the requester can actually act on it immediately, which is exactly the piece that was missing for thirty years.
It also reframes what "pricing an API" even means. A pricing page is a summary for a human to read once. A 402 response is closer to a receipt printed in advance of the purchase - the exact figure, attached to the exact thing it's charging for, delivered in the same channel as the thing itself. Comparing that to API-key auth directly makes the contrast concrete: a key grants access to a plan; a 402 response prices one specific call.
Agentic commerce, as a category, is downstream of that: 402 wasn't a solution looking for a problem for thirty years so much as a solution waiting for a caller, and that caller only showed up once software started making its own small purchasing decisions at execution time. What comes next for API monetization follows the same logic forward - the question stops being "what's our pricing tier structure" and starts being "what should this specific action cost, and can the caller read that off the response."