The status code that waited thirty years

The specification has carried a reserved status code for payment since the beginning, and it sat unused because the human web settled on subscriptions and advertising. Neither works when the client is a program making a thousand requests an hour on behalf of somebody else.

An autonomous client cannot enter card details and should not hold a subscription to every service it might need once. Per-request payment fits the access pattern exactly, and it only became practical when settlement got cheap enough that the fee was smaller than the thing being bought.

What a working implementation needs

• A price quoted in the response, machine-readable, before the client commits.
• Settlement cheaper than the resource, or the whole arrangement inverts.
• A spending policy the client cannot exceed, enforced outside the client.
• A record tying the payment to the decision that caused it, retained as long as the payment.

Where it is actually running

Paid API access for agents, metered data lookups, and inference capacity sold per call. All three share a property: the buyer is a program, the amounts are small, and no prior relationship exists. That last point is what conventional payment rails handle worst.

Our largest customer signed no contract and has no account. It is a process, and it pays per call.

What to watch

Refunds. Every deployment we looked at handles the happy path and improvises when the resource fails after payment. That gap will decide whether serious providers adopt it.