status class

RFC 9110 states that the digit a status code starts with defines the class of the response, and it names five classes: informational, successful, redirection, client error and server error. The class is a coarse instrument by design — it says what kind of answer arrived, and the code inside it says which answer.

Within a single class the codes mean different things, and a payment question turns on exactly that difference. HTTP 402 is registered as Payment Required, and RFC 9110 reserves it without defining a format, so what would satisfy the payment is carried by whatever protocol sits above. 403 is a refusal from a server that understood the request. 429 reports that a client has sent too many requests in a given amount of time — rate limiting, in that document's own gloss. It is registered by RFC 6585 rather than by RFC 9110. All three are client errors, and a reader holding the class alone cannot tell a price from a refusal from a throttle.

A status class also cannot report what never arrived. A request that fails to connect carries no status code at all, so an observer holds an absence rather than an answer. The difference between an endpoint that refused and an endpoint that did not respond is not a difference of class: in one of those cases there is no class. A record that files both under one word has decided something the responses did not say.

So a single reading licenses a narrow claim — this address answered this way at this moment, from wherever the request was made. Whether an endpoint is payable, and whether it stayed payable, are claims about a series of readings taken on a clock. That is a different instrument from a status code, and it has to exist before the question can be asked.