The consequences of itemization and personalization—micropublishing—micropayment essentials—the telcos—the e-currency issuers—why anyone can have a go!
A micropayment is just a small payment, which, like its larger cousin, is handed over to a merchant in return for the supply of goods or services, and which, like its larger cousin, incurs an administrative overhead that is small relative to the transaction value. The cut-off level, at which micropayments transition into payments, is around a few dollars. Micropayments are ideally suited to the purchase of intangible web-based goods and services.
When JG gets going, he points out that if we look back over the past few decades there is one ever-present trend in retailing, a trend that consists of ever greater “itemization”. There was a time when many services were charged for at a uniform annual rate, even though different people made use of these services to different degrees. Goods were priced on the basis of what was needed to make a profit, on average, rather than by adding up the costs of production and adding on a percentage profit. In the absence of microelectronics and computers, measuring and recording service usage or constituent components was impractical. But now everything is being itemized—people charge for a service by how long it takes and the level of expertise of each person involved, and that newly installed water meter monitors how much water you actually use!
Personalization is a great driver in itemization. There was a time when people watched one channel on TV. Now there are hundreds, but viewers still have the inconvenience of manually changing from channel to channel. Soon a software agent will scan the Internet and download what it “knows” you like, and when you sit down to watch “TV” the software will assess your emotional state and present a personalised channel ideally suited to your current mood. Needless to say, you will only expect to pay for what you actually watch, and each programme will carry a separate charge.
The problem with itemization is how to pay for it. When there are many items delivered by the same supplier then the solution is easy. A computer records the items, adds-up the prices and you pay monthly, quarterly, or annually. The payment method used can have a high overhead which is easily absorbed, since the amount of each payment is relatively large. But what if you purchase just a few items of little value from a supplier—what if you read a few paragraphs of text in an online newspaper or magazine? For itemised charging to work in these circumstances the transaction overhead must be tiny. Welcome to the world of micropayments!
Micropayments facilitate and are ideally suited to micropublishing: you can pay 20 cents for a recipe for some home-baked apple pie, or 10 cents for some rousing polemic against the war in Iraq.
Micropublishing is a potential goldmine, a vast untapped reserve. The conventional newspaper or magazine exists for the sole purpose that until now it has been impractical to pay for the individual articles you read from amongst the hundreds of articles that it contains. Perhaps you pay a few dollars for your magazine but only read 20%. But that means that 80% is wasted. In other words, for the price you’re prepared to pay the publisher could actually provide you with only that 20% and you’d still be satisfied, and he would pocket an enormous increase in profit. But it gets even better for the publishers, for the sum of the parts is far greater than that of the whole: publishers can charge a far higher price for articles when sold individually than when sold in bulk, as people are very insensitive to price when purchasing items of very small value—for example, for an article that should cost 2 cents most people would not bat an eye at paying 5 cents, but if the price of their newspaper jumped from $2 to $5 then they would be up in arms!
Another implication of micropublishing is the vast number of new content creators it brings into the marketplace. Very few people have what it takes to write a book, but many can write a few informative paragraphs on some topic in which they have some special expertise. Even if the number of potential readers is too small or the quality of the writing is too poor to merit conventional publication, search engines will find those paragraphs and micropayments will allow readers to pay for the pleasure, or otherwise, of reading the contents. Even though the Internet is overflowing with the most turgid prose, people still read it, and since people place at least some value on their time, they are effectively acknowledging that they are prepared to pay in order to read poppycock and piffle—after, all you’re reading this, aren’t you? A certain marketing man tells us that if you earn $30,000 a year, then you’re burning cash at the rate of about 6 cents per minute, even while you’re asleep, and so should be prepared to burn your hard earned dollars at a much higher rate to read something entertaining or informative while awake.
A practical micropayments system must embody two things:
- Low transaction overheads
- Ease of use
Low Transaction Overheads
Since the value of a micropayment is small, the overhead that the payment system incurs must be even smaller. This implies that transaction handling must be entirely automated—there must be no people in the loop. As long as people are only required in a support and maintenance role, then a very small profit made on each one of a very large number of transactions will pay for those people, and will lead to a profitable business.
Automatic transaction handling means that transactions must be irrevocable. Any system that allowed chargebacks would require manual intervention for a certain fraction of the transactions and this cost overhead would be prohibitive.
Ease of Use
The key issue as far as users are concerned is not security but ease of use. If a user is paying for each link that he clicks on then it is essential that he does nothing more than “click on that link”. If he has to do anything else, such as enter a password or even press a confirmation button, then the micropayments system is not viable. For a system to work there must be no alteration in the user’s browsing habits!
In practice, a site offering a usable micropayments system might simply add the price of the link to the anchor text. For example, if you were paying for this article you might see “Micropayments, Micropublishing, and E-currency ($1)”—okay, let’s be realistic (1c)! You’d click on the link, this page would appear, and one cent would be automatically deducted from your micropayments account, without any intervention on your part whatsoever!
Price Range Colour Coding
The first problem with the above solution is which currency to use. While gold is an obvious choice, it’s no use using milligrams of gold to display the price as the average punter has absolutely no feeling for what it’s worth!
As web users have many different national currencies a more generic approach would be to divide payments into a fixed set of ranges, and then code the payment into the anchor text using a small icon of a particular colour. A standard payments table would then show the approximate payment range based on the current gold price that each code represented in each national currency. For example,
- Red > 2$
- Orange 1-2$
- Yellow 50 cents – 1$
- Green 10 cents – 50 cents
- Blue < 10 cents
would give a user immediate feedback on whether the price range was acceptable. A percentage figure contained within the icon could be used to indicate the exact price based on the range, so “blue 10%” equals 1 cent, “yellow 50%” equals 75 cents, and “red 500%” equals 10$.
When prices are small, the exact price becomes unimportant; a user just wants to ensure that he is not paying an unexpectedly large amount for an item. It is very easy to check colour coding that is embedded in a link. A user might decide, “I’m prepared to press on anything that isn’t red; if it’s red then I need to pause to see if it’s really worthwhile.”
So we feel that, with a bit of work, a simple and internationally useful system could be devised that would allow users to check the price in a nearly effortless fashion.
Security is of very little importance when it comes to micropayments. Let’s take an example. Suppose you spend $150 a year on micropayment purchases and that on average once a year someone breaks into your micropayments account and appropriates the balance which averages $5. Would this “extra expense” be worth it for the convenience of simply being able to click on a link in order to make a payment, rather than having to type in a password every time? The answer for almost everyone is a clear “yes”.
The only thing that matters for users is the ability to place a limit on their possible losses from a micropayments system that operates at a comparatively low-level of security compared to those designed for standard merchant purchases. As long as users can set the limit according to how risk adverse they happen to be and the degree of inconvenience they find in frequently topping-up their micropayments account then all will be well.
There are many ways in which a micropayments system could operate. In this section we’ll outline a possible mechanism for operating a micropayments system and the sort of characteristics that an account might possess, demonstrating, we hope, that it’s relatively easy to satisfy the needs and address the potential concerns of user, merchant, and micropayment systems service provider alike.
When the first payment on a site is made the merchant transfers the user to a page on the micropayments system’s web site. The user enters one very simple password, and presses OK. The form is sent to the micropayments system service provider (MSSP), who then gives the merchant permission to draw funds from the user’s account for a specified period of time, up to a certain limit, both of which were set by the user when the account was created.
As the user browses the site and clicks on links that incur payments, the merchant keeps a total and at intervals sends the total to the MSSP who debits the user’s account, credits the merchant’s account, and charges one or both a small commission.
Even though the amount of each payment is small no significant additional web traffic is generated, since the merchant simply accumulates the amounts owing until either the limit is reached, the user has stopped generating additional payments for some period of time, or the maximum period of time over which the merchant can collect payments has expired.
The merchant never knows the identity of the user since the merchant generates a payment identifier at the beginning of each session which is included in the form that the user sends to the MSSP, and which is returned by the MSSP to the merchant along with the payments limit and timeout information.
The merchant uses a cookie on the user’s computer to store the payment identifier, so that the merchant can separate payments into separate streams with a cumulative total held in the merchant’s database against each payment identifier (if the user deletes or modifies the cookie, the total owing is not lost, and a new session is started should the user continue to click on payment links).
For efficiency, the merchant could settle up with the MSSP on a daily basis, sending to the MSSP a single file containing a complete list of all payment identifiers and corresponding payments. The MSSP could then update the corresponding user accounts.
On a publicly accessible computer it would be important for the user to either delete the session cookie or indicate to the merchant that the session was at an end by pressing a “no more payments” button on the merchant’s site. But the potential problems here are less serious than those associated with sessions left open on a financial site where the sums available to be appropriated would be much higher.
When creating an account with the MSSP the user sets a limit on the maximum amount that can be in the account at any one time—the MSSP might default this to some low value, and might even set an absolute maximum. The account limit represents the maximum amount that the user could lose if security is breached. If the user attempts to fund his account above this limit then the funding transaction is rejected. If the user changes the account limit then warning messages appear stating that this is a low security account and the user should not put in it more by way of funds than he’s prepared to lose by way of peculation.
Each session with a particular merchant could be time limited. Before the time limit expires the merchant must terminate the session and send a demand for payment to the MSSP. If access is typically from a home based computer and the user does not delete selected cookies then the timeout could run into weeks, so that the merchant steadily accumulates small amounts as the user browses the merchant’s site. If access is typically from a publicly accessible computer and the user spends a few seconds checking some stock market prices, then the timeout could be in minutes. There is a trade-off between storage and communications overheads. Short timeouts require the merchant to generate much more web traffic to and from the MSSP. Long timeouts require the merchant to maintain long lists of payment identifiers and associated payments owing. Irrespective of the user specified timeout, the merchant can terminate the session at any time, forward the current amount owing to the MSSP, and require the user to start a new payments session.
Single Payment Limit
The user could place a limit on the maximum value of any one micropayment. A user who did not want to spend more than 50 cents when clicking on any one link without specific authorisation could say so, ensuring that he is not charged $50 for a miss-colour-coded payment link (though the enforcement of this rule would be up to the merchant if only aggregate totals are sent to the MSSP).
The user could limit the total amount that can be spent in any particular time period, say a day or a week. When starting a new session the limit sent to the merchant would be the lesser of the account balance and the difference between the spend rate less the amount already spent within the current time period.
Approved and Excluded Merchants
As micropayments systems lend themselves to paying for articles or downloading images and music, and users tend to have favourite sites, a user is very likely to use the system frequently, but with only a small number of merchants.
The user could specify that micropayments can only be made to, or can never be made to, certain merchants. This would allow the user the convenience of one-click micropayments for most purchases, while being able to revert to the “always enter a password” mode for others.
Account characteristics, such as the timeout, the single payment limit, and the spend rate could be customized for each approved merchant.
Given that the amounts spent are small there should be no need for a conventional transaction history detailing the name of every link that the user has clicked upon and its cost. We suggest that the following information about a session should be sufficient for the user’s purposes:
- Merchant’s name
- Web address
- Time of first micropayment
- Time of last micropayment
- Total number of micropayments
- Total cost of micropayments
- Average cost of micropayments (derived)
- Cost of highest value micropayment
The merchant’s name, web address, date and times would be sufficient to raise suspicion if anyone had gained unauthorised access to the user’s password. The number and costs of the micropayments would be sufficient for the user to judge whether he was getting value for money, and would make it easy to perform inter-site comparisons for the respective costs of accessing similar material.
By restricting records to totals, averages, and outlying values in this manner the storage requirements for those merchants who have millions of users browsing their sites on a daily basis would be kept to a minimum.
The Telcos have not yet developed useful micropayments systems. Typically, a merchant places a code against each item to be purchased. The user sends the code by SMS text or touch tone to the telco who returns an authorization code which the user then enters into a merchant form. This method is even more cumbersome than password entry, as two codes have to be typed in and there is a delay while the item code is authorized. It is totally unsuitable for micropayments.
However, it would not be difficult to automate this procedure. A Bluetooth USB fob plugged into the computer could talk to a Bluetooth enabled phone, and software could then send the codes back and forth automatically. When suitably equipped mobile phones reach a critical mass we can expect the Telcos to move into the micropayments marketplace.
The E-currency Issuers
It would not be difficult for an e-currency issuer to add a micropayments service to its existing portfolio. But the big three still require the tedious entry of passwords no matter what the value of the payment. The potential revenue from this market is vastly more than that available from either asset storage or conventional merchant sales: the reason is simply that in the long-term almost everything on the Internet is likely to come with a small price tag attached—this is the logical end point of itemization. It would solve the pressing and ever-growing problem of how to pay for the infrastructure that is needed to cope with ever higher bandwidth services—it’s a better solution than the “two-tier Internet” which is the only alternative on offer.
If they don’t get their collective acts together soon the e-currency issuers will be overtaken by the Telcos. And a micropayments service provides an ideal opportunity to be number one: even if the market is small to begin with, the e-currency issuer who is first on board is likely to retain the lion’s share of the market as it grows, and the “johnny-come-lately”s will have the difficult task of playing catch-up. Most of the potential merchants in the micropayment market place are unlikely to be using e-currencies at present, providing an ideal marketing opportunity for either Pecunix or 1mdc to claim the blue ribbon within this sector.
Because of the intrinsically lower security requirements of micropayments systems it would be unwise for an e-currency issuer to just add micropayment functionality to its existing service. That might damage its reputation for security in the asset holding and conventional merchant payment sectors. A sub-brand would reinforce the main brand while providing a sufficient degree of separation so that users would appreciate that the two payment systems offered very different levels of security—anyone for a Pecunix-Lite or a 0mdc?
An empty niche
It’s arguable whether there are any micropayment systems available at present that are easy to use for both merchants and their customers, and which provide a clear separation of payment and content—we don’t like what we’ve seen. And there are certainly no anonymous micropayment systems at present. So there is a definite niche here to be filled by anyone who is prepared to make a modest investment.
You don’t have to be an existing e-currency issuer to develop a micropayments system. You can take a leaf out of 1mdc’s book and piggyback your system on top of Pecunix, e-gold, or even 1mdc itself. With the interfaces provided by these merchants it’s easy to bolt on additional services, and since the big three show no interest in micropayments at present there’s a window of opportunity for any small enterprising organisation to make its mark. But don’t delay. It won’t be too long before the e-currency issuers, and indeed the Telcos, realise that they’re missing out on a very big opportunity, and start mining this seam of pure gold!