Headlines | Linux | Apps | Coding | BSD | Admin | News
Information for Linux System Administration 

Proposal: A Web Bug-based Micropayment Model


The problem
The trouble with paying for web content suffers from the inherent nature of web interaction. The fundamental problems with paying for online content are these:
  • Very small payments are economically infeasible because the transaction costs for a payment are far too high with existing payment methods.
  • The Internet is a huge resource where literally millions of disconnected individuals own the content and hundreds of millions of others use that content.
  • The fast-moving and anonymous nature of surfing doesn't lend itself to creating an account at every site you deem worthy of a mere micropayment, even if small payments were economical.

The first constraint makes pay-as-you-go prohibitively expensive. The second prevents subscriptions from being a viable solution for websurfers who are likely to visit hundreds or thousands of websites in a year, and worse, don't know which websites they will be visiting tomorrow. And, of course, the third makes it too inconvenient even if transaction costs were lower and you knew which sites you were likely to go to.

Note that a single website can charge a subscription by the month or the year in order to spread the transaction cost of the payment over a large number of uses. Unfortunately, that solution only works for large websites with very specific and compelling content that are used repeatedly by mostly the same users. Obviously, subscriptions solve the problem for only a tiny fraction of websites and an even tinier fraction of web users.

Look to the dark side
What I propose is a system based on the (previously) unmitigated evil known as the web bug. A web bug1 is a tiny, typically 1 pixel by 1 pixel, stealth image embedded in a web page.

The way the web bug-based micropayment system would work is simple. The three parties to a transaction would be:

  • Participating websites
  • A micropayment clearing house
  • Participating web surfers

The roles of those three types of participants are as follows:

A web user purchases a web surfer account at the micropayment clearing house and funds it with, for example, $20. The web surfer can now log into the account from any computer and be issued a funded surfing cookie.

A website owner opens a website account with the clearing house. The website owner receives account information and instructions from the clearing house. The webmaster updates the website with code to display the web bug on the priced documents. In that code is embedded information containing that website's account number. For example, each website could be given a different URL for the image file at the clearing house's web bug server in order to identify the website associated with a request.

The web user tries to access priced content at a participating website. At that point the user is prompted to authorize micropayments to that website. The surfer authorizes the payments and surfs into the priced area of the website. There, each page contains a web bug which causes the user to fetch the invisible image from the clearing house. The web bug causes a counter to be incremented in the web surfer's account and another counter to be incremented in the website's account. The web bug could also be used to have the clearing house send a small confirmation message to the website with an IP address and a referring URL to authenticate the web surfer as a micropayment member with surfing funds available.

Since the user has a cookie from the clearing house and the web bug code identifies the website, the clearing house has all of the information necessary to move a cent -- or ten -- from the user's account into the website account. The clearing house, of course, takes a piece of the micropayment -- the house cut. It'll be a small slice, naturally, but perhaps they can make up for that in volume.

This system would have tiny overhead for each micropayment. The web bug plus the code and cookies could be as small as a few hundred bytes, perhaps less than 1 percent of the size of the typical web page. All of the actual micropayment would be automated, lowering the overhead cost for the micropayment to a properly micro amount. My guess based only on the costs of online advertising is that payments under a cent would be viable with this method.

The clearing house gets to validate the web surfing action independently from the website. The web surfer gets to authorize payment for each website used. The website owner would be able to allow anyone with an account access to priced pages without requiring a subscription.

This micropayment model could be used to implement a 'tip jar' or a 'cover charge page' where a user simply clicks to make a donation or to gain access to other content for a flat fee. In the second case, the user clicks the 'cover' page, the micropayment is made, and a 'membership' cookie is issued that might last a day, a week, or a month, depending on the contribution level. I think the 'cover charge' method is the most viable of the options covered so far. Users might not be comfortable with surfing where each page could cost a penny. However, it may be less stressful to click a page for a flat fee, then surf without additional charges until the cookie runs out.

Ideally, a web surfer account would be configurable to cause a confirmation for either:

  • All payments, or
  • Payments above a specified threshold
For example, one might choose to not be asked for charges of one cent or less, to be asked for authorization for charges between one cent and one dollar, and to have the clearing house automatically refuse any page priced above a dollar.2

This might not be possible with static websites. I haven't thought about ways of getting around the dynamic requirement of verifying that a surfer has a funded account on-the-fly.

The system would either require a flat fee per page or a new authorization page to be acknowleged by the surfer if a page on a single website had a price different from the last acknowleged one. I think that would be necessary in order to overcome any uncertainty about how much a surfer was spending. (Note that this doesn't apply to the 'cover charge page' fee method.)

The Chicken-and-egg problem. Without surfers using the system, websites won't create accounts. Without enough websites with accounts, people won't open and fund surfing accounts. In practice, it may be possible to get around this problem. A few websites with very compelling content and currently surviving on a subscription model, might form, along with their users, the initial body of content and population of micropaying surfers. More likely, however, those sites won't change what already works. Instead, marginal websites -- those almost compelling enough to survive on a subscription model -- just might form a large enough group collectively to jumpstart this system.

Obviously, an exact protocol would have to be worked out. The core of this proposal is the simply the idea of using a web bug carrying some encoded data for third-party verification and accounting -- an extremely low-cost method of accruing many tiny transactions across multiple websites into a single charge. That charge would have normal transaction costs and might only happen once per month per account.

-Ray Yeargin

(1) In this system the term 'web bug' is a slight misnomer since the use of the hidden tracking image would be well known to all participants. Of couse, there isn't an actual requirement that the web bug be hidden -- it might be best for the web bug to be a small logo for the micropayment system and visible on all priced (or cover charge) pages. That is, the practical matter of identifying all priced pages explicitly might override any aesthetic desire to use a hidden image.

(2) If a visible web bug is used, it might display an admission price, a price per page, or even an accumulated price for the current session.

mail this link | score:8280 | -Ray, January 13, 2003 (Updated: March 19, 2009)
More Sysadmin articles...

Abstract Art Prints for Sale

Selected articles

Testing the Digital Ocean $5 Cloud Servers with an MMORPG

VPS: Xen vs. OpenVZ

Apple DIY Repair

Librenix T-Shirts and Coffee Mugs!

Linux dominates Windows

How to install Ubuntu Linux on the decTOP SFF computer

Microsoft to push unlicensed users to Linux

Space Tyrant: Multithreading lessons learned on SMP hardware

Apple to Intel move no threat to Linux

Linux vs. Windows: Why Linux will win

Scripting: A parallel Linux backup script

Space Tyrant: A threaded C game project: First Code

Space Tyrant: A threaded game server project in C

Missing the point of the Mac Mini

MiniLesson: An introduction to Linux in ten commands

Tutorial: Introduction to Linux files

Mono-culture and the .NETwork effect

Hacker Haiku

Closed Source Linux Distribution Launched

The Supreme Court is wrong on Copyright Case

Why software sucks

Why Programmers are not Software Engineers A simple directory shadowing script for Linux

The Real Microsoft Monopoly

Programming Language Tradeoffs: 3GL vs 4GL

Download: Linux 3D Client for Starship Traders

Graffiti Server Download Page

Beneficial Computer Viruses

The life cycle of a programmer

The short life and hard times of a Linux virus


Firefox sidebar

Site map

Site info

News feed


(to post)


Articles are owned by their authors.   © 2000-2012 Ray Yeargin