I find it interesting that so much of the response here is negative, to the tune of "This shouldn't have been part of the HTTP protocol, it's useless". From my

I find it interesting that so much of the response here is negative, to the tune of "This shouldn't have been part of the HTTP protocol, it's useless". From my point of view, a web where this status code works correctly would be very different, and mostly in a good way - so I find having this in the protocol a noble attempt that didn't pan out. But that's not a failure of the design - the reasons 402 is not able to do anything are more political/environmental than technical in nature, having more to do with how the world works, not with how HTTP works. From the technical point of view, it's very easy to imagine how it could work, for example: The site says 402, with some standardized headers telling my browser the amount and purpose. Browser pops up a dialog to let me confirm (if I want) and choose a payment method from the ones I registered with it. If I confirm, browser resends the request with a "ChargeTo: pay://visa.com/<token>". No special interface needed on the website, no need for me to give credit card info to random websites. That's a preferable outcome to what we have now. Sure, it didn't end up working that way. But: a) it's hard to predict what'll get traction at the time of protocol design, b) it's never too late for somebody to salvage this status code, like the REST revival did with so many other HTTP status codes that were rarely used.