One of the challenges–if not the challenge–for bringing alternative monetization methods to the web is finding a way to have a "conversation" with readers about how they want to support the content they love. For many sites, the default right now is "ads", but what if you're ok with contextual ads and not behavioural? Or what if some new web-wide method emerges that you want to use.
How do you signal to websites your desire to pay in a different way?
Recently I've revisited some previous thinking about how we can use HTTP Status Codes and a new Content Negotiation header to start a dialogue between client and server. It's my hope that this can improve the user experience while providing guidance for sites who wish to navigate growing monetization offerings. Ideally this puts the user in control to specify the kind of experience they desire.
Before we go further, note that I'm not talking about ecommerce use cases now–I think other proposals have already covered these kinds of payment schemes where you're selecting your favorite credit cards, etc. What I'm talking about is passive browsing that is historically supported by advertising, "for free".
I've found that when brainstorming new ways to support content on the web it's increasingly likely that someone will bring up the [402 Http Status Code](<https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#402>) and point out that it's been "reserved for future use" since the dawn of the web. It's the future, so let's use it. But how?
By itself, the status code doesn't do much. It's a response to some request, so it has to happen after a request.
Consequently, browsers have to have built-in user interface patterns, or websites have to add things to web requests so that servers know what a client's desired payment method is. Indeed if you look at most current uses of the 402 status code, you'll find that they are API response codes which make sense in the controlled context of a web API.
How could a web browser let the web server know what its payment intentions and desires are? At the moment, there's no one standard way to do this, which is why I'm proposing the addition of the Accept-Payment Header which would be sent be the client with most requests.