David Humphrey takes time to make a good case for adding payment mechanisms to web browsers:

What if, in addition to responding to 200s, 404s, 401 (unauthorized), 403 (forbidden), and 405 (not allowed), web browsers made it possible for sites to send the nascent 402 HTTP response code: Payment Required. The spec says this code is reserved for future use. Friends, I’m here to tell you that we’re living in the future, and it’s time to figure this out.

Humphrey gets several things right here. He draws the comparison between the “normal” web and proprietary markets like Amazon and Netflix, showing that users are happy to pay directly for content if the price is right and if paying is easy and trustworthy — and he understands that in order for us to accomplish this on the web, we need to build support for it into the browser itself.

The biggest rough patch for me was his concept sketch for a blog post demanding a payment, which could probably use some re-thinking:

From the article: concept for price-setting at an independent food blog
From the article: concept for price-setting at an “independent food blog”

This is exactly the kind of scenario I was trying to avoid when developing my own concept for web payments. For one thing, people don’t want a tin cup shaken in their faces every time they visit a daddy blog or a news article. For another, the real value of a pageview on an “independent food blog” is probably closer to $0.0015 than $0.15; direct web payments need to enable transactions at these kinds of price levels just as the ad market does for advertisers. Finally, payments should be voluntary (on the reader’s part) and price levels should be suggested. Ideally I’d be able to tell my browser to take a fixed dollar amount and divy it up between all the sites I visit every month based on visit frequency and suggested prices.

All things considered, though, I’m really glad more people are thinking along these lines. Spread the word.