# Implementing universal micropayments on the web

15 thoughts
last posted April 24, 2015, 2:29 p.m.
0
get stream as: markdown or atom
1

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.

0

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. 1 ## Overview of my proposed method 1. The web server, responding to a request for a web page, includes an HTTP header that says, in effect, Price is$0.01, payment should go to john@hisdomain.com.
2. The user's browser sees this header and notes this amount in a ledger.
3. Every so often (exactly when would be configurable) the user would see a report saying "Here's how much web usage you've incurred", breaking the amount down by site
4. The user would have the ability to adjust payment up or down. This could be done on a total basis (thus adjusting payments to individual sites proportionally) or on a site-by-site basis. Payments are voluntary.
5. The browser connects securely to a payment processor (I nominate Gratipay or Patreon for starters) with whom the user has already signed up. It sends a list of payees and amounts for each, in a standardized format.
6. The payment processor pays sites out of the user's balance as directed.
0

Notes before I get into details:

• On the browser's side, it would make most sense to integrate this functionality into an ad-blocking plugin. This allows the user to send a double-message: no, I won't watch your ads, but I will give you the $0.01 that you would have gotten directly if you allow me to. Ideally the browser itself would support this as part of a new standards push. However, that is unlikely to happen for some time. • In all the UI/UX design, one key goal (not the only one of course) would be to plant a kind of "inception": to grow the idea in the reader's head that he or she is expected to support the websites they read and use with at least some tiny amount of change, to make them feel good about doing so. • Sites like Gratipay and Patreon currently do not support micropayments based on individual pageviews, but could well be made to do so. Pay-per-pageview is important because in most cases users are not deeply connected enough to any one site to bother committing to a regular "subscription" or other patronage-type relationship. • The communication to payment services needs to be standardized, to allow multiple payment processors to compete. 0 ## 1. HTTP Headers 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 0 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. 0 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. 0 ## 2. Browser behaviour 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 Resource-Owner header. 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. 0 ### Approving Payment 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:

• Favoured sites (approve by default, optionally add $n.nn or %n by default) • Never-pay sites • Option to default to approving or not-approving payment to all sites Regardless of the settings above, every site HTTP payment request would be logged, and accessible in the regular payment report. 0 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. 0 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!")

• Individual articles would be priced low enough to be infinitesimal in cost to any one reader, and still have extremely high upside if traffic takes off.
0

### Scenario: New York Times

The New York Times reportedly had 35.5 million pageviews in May 2013. Their "Snowfall" story reportedly got 3.5 million page views in one week but that was kind of an outlier.

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.

1

## 3. Payment Processors

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.