Some have said (including myself, initially) that Bitcoin would be the way to go. I think the truest thing ever said about Bitcoin is that everyone who touches it becomes either a thief or a victim. It's possible that Bitcoin could be incorporated, but in my experience and from what I've seen keeping an eye on Bitcoin since near the beginning, it's just far too complex for average people to secure their Bitcoin wallets.
Matthew Butterick's web-only book Practical Typography had 650,000 readers in its first year.
Suppose those readers averaged 10 page views each, and MB asked for $0.05 per page with a 50% collection rate. That's $162,500 in book sales.
Marco Arment says he averages 500,000 page views per month.
Supposing he asked for $0.02 per page and averaged a 50% collection rate, that's $5,000 a month -- not a bad living for an independent blogger. (It's not his only source of income either.)
In the first three months of 2-14, they had $290 million in revenue. Digital subscription revenue was $40 million.
So this isn't accurate for the NYT specifically, but if we suppose an NYT-type operation serving up 106.5 million page views every three months, they'd need to collect micropayments of $0.37 USD per page view just to make up for the digital subscription piece (they'd still be running ads).
Is that too high? I think I'd be much less inclined to click on NYT stories if I knew they were asking $0.37 per page view. That would be somewhat irrational of me because I can totally afford it, but that would be my cheapskate instinct.
Suppose the NYT removed their paywall and requested only $0.15 per pageview -- would they have more pageviews because more people could access them? Or would traffic remain constant?
It's likely that high-value web properties like the NYT would probably not see a benefit towards moving to micropayments, or perhaps they would at least keep the subscription model and experiment with a micropayment/paywall hybrid aproach.
All of this would create essentially a new market for content. In that market, prices would find their own levels.
Ideally those levels would be small enough that users would be pleasantly surprised at how cheap it is to make the expected contribution, in comparison with the value they're getting. ("Only $1.13 for the last two weeks! huh!")
Once payment is approved, the plugin would connect to the micropayment processor's API securely over HTTPS using an API token and send them the list of approved payments in a standardized format.
Every user should be prompted (most ideally as part of the web browser setup process) to sign up with a micropayment processor, and to support the websites they use.
Every so often -- say once a month at a minimum -- the user should be prompted in some way with a report saying "here's the $ of total payments that have been requested for websites you visited since your last payment."
The user should be able to adjust the total amount up or down (adjusting each site's amount proportionally) and to drill down and modify or zero out individual sites.
Separate from this, the user should be able to specify in preferences:
Regardless of the settings above, every site HTTP payment request would be logged, and accessible in the regular payment report.
When the browser sees a
Resource-Price header in the response, it would, at a minimum, log the pageview, the price, and the requested payee specified in the
It could also display a clickable indicator in the status bar or the address bar, noting that the server requested payment for the current resource.
Adding headers to HTTP responses is trivially easy for web servers to do right now. Any CMS could be augmented to allow authors/publishers to configure price settings for specific resources.
And that's all the web server would have to do. The rest is up to the browser, and the payment processors.
I also considered the creation of a new request header as well, allowing the browser to signify that it is micropayment-aware (without promising payment for the request). This would allow the server to keep stats on how many clients are signalling support for micropayments, and possibly to serve different content depending on its presence or absence.
However, there would be nothing to stop a client from sending this header regardless of whether or not it actually facilitates micropayments, so in the end I'm not sure how useful it would be.
I'd suggest we create some new HTTP response headers. I'm not wedded to these names, but I think the role of each is important.
Resource-Owner: This could be defined as an email address. This allows a way of identifying who should be paid that A) can be tied back to domain registration, and B) allows for specifying both the organization as well as the author (allowing a site to divvy up revenue by contributors for example).
Resource-Price: Formatted as a number followed by an ISO 4217 currency code
Notes before I get into details:
Price is $0.01, payment should go to firstname.lastname@example.org.
The goal is for a web publisher to be able to say, for any given URI, "please pay $0.01 in exchange for downloading this resource." In addition, readers should have a non-cumbersome way of honoring those requests that always keeps them in full control of their money.
In this article I outline a few big changes I would make to the internet to empower small, independent creators, and to make certain kinds of huge online businesses unprofitable to run.
Adding universal micropayments to the web is a core piece of that proposed set of reforms. Here I muse about how that could actually be implemented.