Micropayments - Requirements and Solutions

10th January, 2000

Jari Kytöjoki, Vesa Kärpijoki

Department of Computer Science
Helsinki University of Technology
Jari.Kytojoki@hut.fi, Vesa.Karpijoki@hut.fi

The electronic payment mechanisms of today have been designed for handling payments of value over five dollars. It, however, seems that these systems cannot manage a large amount of payment transactions below that value level in parallel very well. Together with the envisioned new opportunities in e-commerce, the difficulties have lead to the development of completely new electronic payment mechanisms such as micropayments that have been envisioned to bring solutions to these problems.

The micropayments have special characteristics and requirements, distinct from those set for electronic payment systems in general. According to our evaluation, the contemporary micropayment models and implementations are, however, still not feasible enough for attaining wide acceptance among the players of e-commerce on the Internet. The developers and business companies behind the current micropayment systems have not evidently been able to apply completely new approaches in the design and implementation in respect of both technological and business-related issues. We see the development of new business and technology models as one of the most important requirement in the development towards a successful micropayment system. We conclude that there is still a lot of future work to do until a working and widely accepted micropayment mechanism can be introduced in the net.

1 Introduction

2 Electronic Payments

2.1 Characteristics of Electronic Payments

2.2 Models of Electronic Payments

2.3 Scenarios with Traditional Money

2.4 The Microcommerce Model

2.5 Content Providers in Microcommerce

3 Micropayments

3.1 Definitions

3.2 Demand for Micropayments

3.3 Actors in Micropayment Systems

4 Requirements for Micropayment Systems

4.1 Micropayments as Electronic Payments

4.2 Criteria for Evaluating Micropayment Systems

4.3 Framework for Micropayment Evaluation

5 Evaluation Issues

5.1 Security Aspects

5.2 Thoughts on Usability

5.3 Micropayments as Business

6 Implementing Micropayment Systems

6.1 Cryptographic Tools

6.2 Protocols and Software

7 Contemporary Micropayment Implementations

7.1 About the Micropayment Schemes and Implementations

7.2 CyberCoin from CyberCash

7.3 MilliCent from Compaq/Digital

7.4 Micro Payments from IBM

7.5 Summary Table

8 Discussion

8.1 Evaluating the Payment Models

8.2 Evaluating the Implementations

9 Future Work

10 Conclusions

Glossary

Acknowledgements

References

Links and Further Information

Provision of content is one of the main attractions and benefits of the Internet [11]. Today the intangible goods and services on the Internet - information and other immaterial resources - are given away for 'goodwill', most likely because the existing payment mechanisms are not seemingly suitable for charging sub-penny amounts of money. Many solutions have been offered to solve the problem but only a few of them have survived in the business. Since for the content providers of the Internet the question of charging is very important, advertising may be an ideal revenue source for large content providers, if they can wisely distribute advertisements among the valuable information in their web pages. According to this approach, by paying a tiny fee the users of Internet would get better and new content as well as services of higher quality. In this seminar study paper we investigate the need for a mechanism designed for handling payments of very small value and present one possible solution, known as micropayments. Considering these issues, let's discuss a pair of use cases.

Would you be ready to pay a very small amount, say, a cent when you are inquiring a timetable on the Internet for some public transportation vehicle? Instead of the small charge, should it be absolutely free - or would you preferably pay a fixed fee every month or year? Many of us hate the whole idea of paying something separately from the receiving the actual service, no matter how little the payment is. What about if you need the service so seldom that it is not reasonable in any way to pay for it regularly?

Today there are already many newspapers available in electronic form. Some of them can be read for free because there are advertisements that make it possible. Several newspapers allow their regular subcribers to read the articles on the net for free while they also get the normal paper copy of them. An alternative way to this is to pay a separate monthly or daily fee to be able to access all of the numerous articles. But what if you were interested in only one or few of them? What would be a sensible and user-friendly way to pay for such information?

The scope of the study was limited to the analysis of the characteristics, requirements and proposed solutions of micropayment systems for public networks. The monetary, political, institutional and legal issues as well as system-level technical aspects related to the micropayments are beyond the scope of this study. For the most part this paper is quite technical but it also covers a few non-technical topics like the business and usability issues. This approach was selected in order to give the reader a more comprehensive view of the field of micropayments.

The paper is structured into ten sections. The first section introduces the field of micropayments as well as the study itself, its scope and goals.

The second section discusses payment models, categorizations and payment scenarios of electronic money that are interesting from the viewpoint of the micropayments. The section also handles the low-value payments from the viewpoint of e-business by introducing the microcommerce model idea. The third section discusses the definitions and characteristics of the micropayments.

The requirements for micropayments are discussed in section four and issues over security, usability and business organization are discussed more in detail in the fifth section. The 6th section gives common answers to the questions over the implementation of micropayment systems by shortly presenting cryptographic tools, protocol and software solutions.

The 7th section applies the previously stated comparison criteria by evaluating three existing well-known systems. A few research papers with new micropayments schemes are also presented very briefly. The results of the evaluation are summarized in the table of the section 7.5. In 8th section the payment models and implementations are evaluated collectively and compared to each other.

Some future work possibilities for the micropayment systems are proposed in section nine. Finally, the 10th and the last section summaries the ideas for this study.

In this section we discuss the field of electronic payments in general. We emphasize the characteristics and models of the electronic payments in respect of payments of very low value and the new business field emerged around these issues - the microcommerce.

In the last few years electronic payments have emerged as a new way to purchase goods. Any method of purchasing, in which the paying takes place by exchanging digitally represented payment instruments - usually through a network connection, can be defined as electronic payments.

The electronic payments are stored and transported in digital form, which poses new problems for the development of secure electronic payment systems: the payments are easy to be duplicated in contrary to the traditional physical paying instruments. Since the digital payments are represented as simple byte arrays or sequences of bits, nothing in them prevents the copying of them as such. If the security of the payment system is dependent on the way the payments are hidden from outsiders, anyone that can have access to payments could use them, possibly many times. This is called the double spending problem [1] which is a central issue to be noted when a safe electronic payment system is being designed.

There are two fundamental ways of managing electronic payments: on-line payments - in which the seller verifies the payment sent by the buyer with a bank before serving the buyer and off-line - in which the double spending is prevented by some previously executed operation, therefore no on-line connection to the bank is required. [1]

Electronic payment models can be divided by Tennant [25] into two groups in respect of their on-line requirements, consumer base stability and basic paying methods. Payments through transactions are individual payments whose utilization requires no prior arrangements between the buyer and the seller. On the other hand, if the payments through accounts model is applied, the buyer and merchant must have set up an account and a some kind of contract before the actual payment transactions can be executed. The payments through transactions can be further divided into two subgroups: The credit card payment transactions are typically designed for large-fee payments of, say, several tenths, hundreds or even thousands of dollars. In contrary, net money transactions are typically low-value payments with hard transaction cost and on-line requirements, thus resembling the idea of the micropayments very closely. [25]

On the other hand, Tennant [25] divides the payments through accounts into three subgroups: Subscriptions form the traditional model applied in credit card systems, in which the credit card is verified before the first actual purchase - after the verification the user is given an identification and a password. This method seems to work well only in the system environments in which the customer base does not change a lot. Purchase orders are commonly used in business-to-business (EDI - Electronic Data Interchange) transactions. They require special a priori agreement between the parties for authorizing a transaction or category of them. Finally, net accounts typically consist of credit card accounts, in which payments are accumulated. The payments may individually be too small to be handled within a system applying the credit-card -style model, but with the accumulation of the payments the authorization of the credit card may be manageable and the transaction costs could stay at a tolerable level, according to Tennant. [25]

Aukia [1] divides the account-based systems in two subgroups, according to the execution model of the transactions. In a notational system the buyer sends his account number (or some equivalent that identifies him) with the sum to be paid to the seller, which contacts the bank that handles the transaction. On the other hand, in bearer systems the buyer requests a token, the digital representation of the payment in question from the bank. The bank debets the account, sends the token that corresponds the sum in question to the buyer. The buyer can then send the token to seller, who forwards the token to the bank when he wants to be credited for the value of the payment. These are direct-payment systems, since both buyer and seller must be on-line at the same time. If they aren't, one of the parties should be represented by an issuer or an acquirer party and the actual credit or debet process would then be executed later with the party that is not on-line during the transaction. [1]

Schmidt and Müller [23] use a relatively different style in their categorization of the payment models than Tennant. They outline three possible payment models - categorized by the paying method they apply - that could be utilized in the development of the low-value payment systems. This categorization was originally constructed by Neumann and Medvinsky [18], who discussed the requirements and categorization of payment models from the viewpoint of the electronic money in general.

Electronic currency, or e-cash, has been designed to allow electronic payments whose properties resemble the characteristics of the physical traditional cash, especially anonymity, which is discussed in the section 5.1. This model corresponds the net money payment model Tennant described.

Credit-debet model, on the other hand, is based on user accounts stored in a bank supporting the payment system and cheque-like payment method. Moreover, most proposals require that the seller and buyer must be customers in the same bank. In contrary to this, a universal credit-debet system would require the involvement of an international well-accepted clearinghouse, not just a single company offering financial services. This model resembles all of the account-based systems Tennant discussed. Neumann and Medvinsky divide this group further to debit or credit approaches, depending on the handling style of the balance of the user account.

Finally, secure credit card transactions require that credit card companies must serve as international clearinghouses. The model can either utilize a TTP (Trusted Third Party) - so that the buyer and seller are authenticated only by PINs (Personal Identification Number) that are sent through a secure web connection, or not - in this case the credit card information is sent directly from the buyer to the seller in an encrypted and signed form [23]. This category is similar to the credit card transaction model Tennant described. [18]

According to Schmidt and Müller, these three models have different pros and cons in respect of implementing systems for handling low-value payments [23]. It seems that not a single payment model is suitable enough for every application as such, especially when the eccentric micropayments are in question. Because of the nature of the new intangible services on the Internet, the traditional payment mechanisms like credit card systems do not seem to be fit for the different conditions the markets of these goods require. Therefore new solutions and technology are needed to enable the introduction of payment systems that can meet these requirements.

Morever, it should be noted that micropayments, as well as other electronic payment models cannot just be reduced to a technological problem [23], which seems to often be forgotten especially in the technologically-oriented Finland, since a working payment mechanism must be integrated to the real world. For instance, the payment scheme chosen must be implemented which is a question of software and hardware. The implementation process itself demands a lot of resources and may produce new problems, like the concerns over the size of the customer base or the required logging resources. But a payment scheme or implementation as such cannot handle the social or business-oriented functions, like customer base and billing, help desk services and usability questions. Considering this, the development of a successful micropayment system is a larger and harder task than it at first glance may seem.

Let's imagine a following kind of scenario: One day you are surfing the net and find something appealing which you want to buy almost immediately. Perhaps you have found an interesting book, CD or just a couple of tracks on that CD. How would you like to pay for it? Would you enjoy making small payments on the net?

Most likely the current method you want to pay on the net applies the credit card model. It is no wonder that the most common method of charging for goods over the Internet is carried out by utilizing credit cards, since they have been around for over forty years. Credit card purchasing is a publicly accepted paying method and the handling of them is familiar to most consumers. Moreover, they are considered to be relatively safe [25].

But the disadvantage with the credit cards is the cost of transactions, especially from the viewpoint of the sellers that have to pay certain bills to the clearing house they have made contract with. This of course, will have direct influence on the pricing policy - and the interest among the potential customers. Normally when intangible goods are purchased over the Internet, there is a base cost for each transaction plus some percentage of the payment value. The base cost is necessary, since the banks and clearing houses often set (high) fixed prices for every transaction they execute for the seller.

Another problem is that some people are concerned about the security of credit card use in the Intenet shopping. Some time ago the users gave their card numbers in plaintext format to the Internet. The well-known credit card systems of today, however, offer adequate protection for instance by allowing the transportation of the PIN codes over secure web connections. Figure 1 represents a model how credit cards can be used in a secure way across the Net. The protocol is called SET (Secure Electronic Transaction) which is standardized and is nowadays recommended by most credit card companies. The transaction on the credit card network - from the acquirer bank to the issuing bank - is similar to the traditional charge card scenarios, just with an added indication of SET being used and the terms of the transaction. In particular, the signature on the payment order is not forwarded to the issuing bank. In this sense, SET does not provide the non-repudiation one would expect to achieve with digital signatures.

Credit card payments rule the payment business on the Internet today. If this is the situation then an obvious question arises: why should we even bother to utilize and study new payment solutions, if the good old systems work well enough? The short answer to the question is that the credit cards seem to simply be unprofitable for the seller at purchases for small amount of money [7].

Microcommerce is a field of commercial business where each payment may be inexpensive, only tiny amount of money [14]. From the viewpoint of the microcommerce the micropayments can be seen as one possible solution to allow the low-value payments for purchasing news articles, stock quotes, index queries, per-click purchase and other services. The World Wide Web is a useful content delivery mechanism for especially on-line merchandise which may offer great opportunities for the emergence of the microcommerce.

On the other hand, the application of the microcommerce model may be difficult, since the latency requirements and the large amount of low-value payments demand a lot from the systems of the merchants. The content providers want to be compensated for their hard effort and the substantial utilization of resources. The need for reasonable commissions for applying of the micropayment mechanisms is an obvious problem to be solved. Moreover, this may lead to the scenario in which the merchants are required to agree to liabilities so that the micropayment system to be applied could gain significant user and merchant bases - without a successful startup, the payment system may soon be forgotten and dead.

Jones [13] has discussed some possible microcommerce content providers which are presented in the Table 1. Micropayments seem to form an ideal way to pay for this kind of content.

The micropayments have attracted quite a lot of publicity in the last few years. Even though they are still a rather young innovation, the number of micropayment proposals, articles written about them and the public discussion prove that the micropayments as such should be taken seriously. This section defines the term micropayments and introduces concepts that are closely related to the field of electronic money. Then micropayments are discussed as the possible solution to provide the basis for mechanisms to handle the payment traffic of the low-value goods in the Internet. Finally, the typical actors of micropayment systems are briefly discussed.

Some instances define the term micropayment as low-value electronic financial transactions [23]. What the word 'low-value' actually means, usually depends rather heavily on the micropayment system in question. Generally, the value of an individual micropayment range as much as from a fraction of a cent to a few dollars. Some schemes define the payment interval more strictly, since some micropayment systems have been constructed to offer a solution to a rather specific electronic payment problem. Micropayment systems can, however, be described by setting the upper bound of the sum in question, which can be as high as, say, five dollars or as low as a couple of cents [1].

Sometimes another term, minipayments, is used in parallel with the word micropayments. In this case the micropayments refer to sums perhaps under one dollar, while the term minipayments are defined as payments larger than micropayments, but smaller than the traditional payments, e.g. credit card transactions, which are typically the size of 80 dollars in average [7].

Before we go into the world of micropayments deeper, some definitions should be given. We use different terms with the word micropayment when we want to emphasize certain aspects of the micropayment field: The term micropayment system or mechanism refers to the micropayment utilization as a whole, ranging from software and hardware implementations to the logistics and business organizations needed to support the payment handling. The term micropayment scheme or proposal can be described here as an equivalent of a theoretical and abstract definition of a micropayment system without any concrete implementation in itself. On the other hand, micropayment implementation is used to emphasize the software and hardware implementation of the scheme which does not include the business or legislation issues.

Finally, the payment information as such can be expressed and delivered in many ways, but in this study we call the micropayment instrument in general as a token. The token or digital coin itself can be an encoded, signed and encrypted field in a payment protocol message. The protocol applied to carry out the transportation of the tokens, however, may partly determine the form in which the digital payment abstraction is exchanged from a party to another.

According to Aukia [1] the paradigm of buying is changing in many ways - previously the buyer had to be directly involved in the payment process to be able to buy something, for instance by showing an identity card, by using credit card over telephone or by using EDI connections between contractually bound parties. The modern paying systems, however, should not set these kind of requirements for the customers, who seem to want to purchase goods on the Internet without having to comply to restrictions in respect of their physical presence, the purchasing time and the paying instrument. The spectrum of purchaseable goods is changing since the emergence of the Internet - thus the payment systems must adapt to these changes. [1]

By now many micropayment systems have been proposed and implemented to meet the requirements set by the rapidly growing markets of the Internet. The developers have envisioned that the growing number of Internet users will want to purchase services, like pay-per-view TV channels or Web pages, by using micropayment mechanisms supporting easy payments of small amounts [2]. It seems that the micropayment systems are usually meant for buying the low-value services only in pay-per-visited-link -style in the Internet. Since the services and goods that can be purchased in the Web are intangible, micropayment systems have been seen as the solution to the growing demand of better electronic payment systems. The problem with the intangible goods is, however, that their true value is relatively difficult to be determined. According to Jacob Nielsen [19], the traditional products can be bought with the payment instruments implemented for the purpose in question. On the other hand, these new intangible services offered on the Internet seem to require other solutions than heavy one-time payments, such as incremental and light payments - or should we say - micropayments? [9,19]

What the intangible goods purchased with micropayments can then be? The range of possible goods is not yet very wide, but it is growing. The intangible goods can be divided for instance in three groups: Information can be any piece of useful digital information of very small value, like web pages, articles, stock quotes, comic strips, individual database queries, clip art and music tracks. The list is not currently very long, but it seems to be growing very fast as new applications are introduced in the Internet. Software can range from individual small scripts or programs, like Applets or Active-X controls, to computer games or to a large compiler software. Finally, meter access means the access to some shared resources, like databases, applications or common services. The access is thus usually controlled by some security clearance mechanism. [17]

Many of the intangible goods, like web page articles that can be purchased on the Internet should not cost more than a fraction of a cent or a couple of cents at maximum - otherwise the acquisition of these goods would not be sensible from the viewpoint of the customer at all. Moreover, the transaction cost of single payment should be very low for the merchants' sake. It certainly should be lower than the actual payment, so that the merchants could even survive in their business. But since the value of individual payments is very small, this problem sets the major requirement for a working micropayment implementation: the transaction costs must be kept down. This is not, however, nearly the only requirement for an efficient micropayment systems, since the payment implementation must work properly on-line, in contrary to many traditional payment mechanisms, like those that apply digital cheques transported by connectionless e-mail services. As the value of individual micropayments can be very low, so the system may have to handle a huge amount of parallel transactions. These hard requirements and the lacking of suitable payment schemes has become the bottleneck for the electronic commerce. The requirements are discussed more in detail in the requirements section. [1,23]

All commerce requires at least two actors, a buyer and a seller [1]. In electronic commerce, the names of the parties have many synonyms: for instance the buyer is often called as the customer, and the seller as the merchant. In a world of digital micropayments, however, a TTP, like a bank is also usually needed. The bank can serve as e.g. a trusted depository in which the buyer and the seller keep their accounts. It can take part in the actual payment transaction for instance by verifying the identity of the user and the validity of his account when the seller requests the payment sum to be transferred to his account in the bank. It should be noted that the buyer and seller need usually not be customers of the same bank [1].

There are, however, also other actors or groups of actors in the micropayment world as well as other possible categorizations than the one just described. For instance Stalder [24] divides the actors into three groups: Industry actors are the ones that handle the financial information, like banks, and the ones that develop the hardware and sofware needed to set up the mechanism, the developers. Governments - national and multi-national - control the legal framework in which the micropayment systems can operate. Finally, the group of users consists of both merchants and individual customers purchasing and selling intangible goods. [24]

In this section we discuss the requirements for electronic money, which are interesting and important especially in respect of micropayments.

Micropayment systems can be described as a subset of electronic payment systems and thus they inherit many of the general requirements set for them. By 1997, there were already over dozen micropayment proposals in the Internet [23] - today the number is even larger. According to Aukia [1], some of these requirements have purposely left out in the development of the contemporary micropayment systems, where they are not necessarily needed and where the developers have wanted to concentrate on only few aspects that are important in the environment the payment system is applied.

We discuss the requirements for micropayment mechanisms by referring to two research papers of Aukia and Lehmann [1] and Schmidt and Müller [23] and noting a few others. The descriptions of these two frameworks form the next two sections, from which we have selected and categorized the most important and interesting ones in the respect of the scope of this study. The security-related issues are discussed in the section 5.1 and the technical aspects in the section 6.

Aukia & Lehmann [1] have formed a five-dimension set of criteria for evaluating micropayment systems from different points of views. The dimensions are Intrisic characteristics, Extended features, Security, Privacy and System aspects. We emphasize the three last ones the most, since the criteria of the two first groups are closely related to the general criteria and features of the electronic money we assume the reader already is aware of. The criteria are constructed by applying the general characteristics of electronic money described by Stalder [24] and Matonis [15] as the basis and by considering the special characteristics of the micropayments. [1]

Intrisic characteristics

Intrisic characteristics form the base of the criteria for the micropayment systems. According to Aukia & Lehmann [1], the characteristics are:

• Bounds of value. The micropayment system should allow the creation of payment units of arbitrary size. The lower bound of the value is, however, usually defined so that the cost of transaction is smaller than the price. The upper bound is usually fixed in micropayment systems for different reasons - e.g. the number of bits used to express the value restricts the interval of the possible payment values as such.
• Divisibility. The micropayment system should allow the creation of (nearly) any value from the specified interval so that the client is able to buy any item at the advertised prices. The client must also be able to receive the change money from the payment.
• Duration. Ideally the electronic cash should never expire - compared with the traditional money that can expire - e.g. when the euro replaces the national currencies of the countries in the European Monetary Union totally in 2012.
• Portability. Micropayments should be independent of the transportation method (network) and storing media utilized. Moreover, the Independence criterium of Stalder [24] states that electronic payment information should be transferrable as independent of the physical condition. Note that if the system is developed to be unportable, then the transactions can be directed through well-defined and controlled interfaces - and of course, taxed!
• Offline-capability. The micropayment systems should not force the user to contact a TTP during every transaction. This is a very important criterium considering the very hard latency requirements for the micropayment transactions. [1]

Extended features

Extended features include the following criteria:

• Transferability. Micropayment cash should be transferrable without any registration. Most of the contemporary systems do not support peer-to-peer transactions, which is a central feature of the traditional cash.
• Multi currency. The micropayment systems should be able to operate with multiple currencies, by converting the currencies either inside or outside the system.
• Cancellation. The systems in which the payment transactions cannot be executed in both directions, should allow the undoing of any payment, if the parties agree to do so.
• Fault tolerance. Latency in network or the failure of the software or hardware of any party should not generate any inconsistencies in the transactions. [1]

Security aspects and Privacy

Security aspects form an especially interesting dimension we will discuss further. Aukia and Lehmann [1] have categorized the underlying criteria for security. Privacy is closely related to the security issues, so we handle them collectively:

• Security model. The security of micropayment system depends on the underlying trust and security models applied. In an ideal micropayment system heavy a priori assumptions of the trust between the parties should not be required. In the payment systems of today, however, the trust relationships are usually asymmetric - the customer must always trust at least one of the other parties such as the bank or the merchant. On the other hand, the other parties are often protected by the payment protocol itself.
• Authenticity. Authenticity means that every party of the payment protocol should be able to confirm the origin of any message dedicated to them.
• Integrity. Integrity of the payments means that the payment data - protocol messages in the network or stored transaction data - cannot be tampered or copied. The integrity requirements is linked to the double spending prevention: when the integrity of the stored and transported messages is protected, double spending should not be possible.
• Interruption tolerance. The micropayment mechanism must support atomicity - the transactions must be executed at both ends either entirely or not at all. Atomicity is one of the ACID properties defined for transactions, see [26] for further information about the transaction atomicity issues.
• Non-repudiation. Non-repudiation means that a party cannot a posteriori deny event history in which he has been a participant. Moreover, non-repudiation should be required for all parties.
• Unobservability. This criteria states that the other parties not involved in the transaction have no other knowledge of the transaction after the transaction has been run than what a priori was available for anyone. It may also be required that the transaction is completely hidden from all the parties not taking part in it.
• Parameter secrecy. Parameter secrecy concerns the payment protocol - the other parties of the transaction and complete outsiders must not be able to uncover the contents of the transactions such as the parameters used in the protocol run. These parameters to be protected could for instance include the financial information of the payment like the sum to be paid or the balance of the customer account. Note that if the identity of the party participating in the transaction is unknown, the contents may still be uncovered and vice versa.
• Anonymity. Anonymity concerns the amount of knowledge other parties have of others (see Parameter secrecy). Merchants or banks usually have no anonymity, while customers may have at least partial anonymity. Anonymity is discussed further in the section 5.1.
• Unlinkability. This criteria states that two events of the same party cannot be linked by another party. [1]

System aspects

According to Aukia and Lehmann [1], system aspects are rather broad and difficult issues, so they mainly describe two general criteria:

• Scalability. The micropayment system to be developed should respond to the (possibly very rapidly) growing markets in the Internet. The micropayment system must be scalable, both in technology- and business-wise.
• Universality. A successful micropayment system that is envisioned to be in wide utilization should not be restricted by any financial contract made with e.g. an organization operating in a single country. In theory, a world-wide system could be constructed some day. There are, however, lots of other issues that may prevent this - these aspects are discussed in the conclusions of the study.

Müller and Schmidt [23] have taken a somewhat different approach to the evaluation of micropayment systems. They have formed a three-dimensional requirement framework, which include technological, economic and social dimensions, which are rather directly derived from the work of Neumann [18] about the requirements on network payments in general. Two other very important dimensions, institutional and legal, are mentioned, but not discussed further. The requirement framework is applied to the evaluation of a few contemporary on-line micropayment implementations but it is also meant to be applied to the design of future micropayment systems. [23]

Technological dimension

According to Schmidt and Müller [23], Technological dimension consists of requirements for micropayment systems whose fulfillment is (here) mainly an issue of proper (technical) implementation.

• Security. Security of the micropayment systems is partly an issue of the security of the technology used. For instance, failures of the underlying technology - software or hardware - can substantially decrease the trust on the payment system. The security issues are further discussed in the subsection 5.1 and their implementation aspects in the section 6.
• Scalability. In micropayment systems, a scalable distributed design is required to prevent the possible bottlenecks that may emerge if the system cannot respond to the requirements set by the potentially rapid increase of the transaction traffic through it.
• Reliability. The micropayment system must serve customers 24 hours in a day and seven days a week, having no point of failure in the system at any time. Matonis [15] discussed this further, when he introduced the concept of availability from the viewpoint of the requirements on electronic money in general: the system must be available at any time for any (valid) customer and it must be off-line capable so that no on-line TTP involvement in respect of authentification is required.
• Latency. This is a very important requirement for an on-line oriented micropayment system - even at peak times the response times must be bearable. Neumann and Medvinsky emphasized both the significance of the efficiency of an individual transaction and the transaction costs in general with the efficiency requirement for the electronic payment systems [18].
• Interoperability. Interoperability in the technological dimension means that the currencies like digital cheques and tokens applied in different micropayment systems are fully interexchangeable between the systems and protocols.
• Hardware independence. For instance, to prevent double spending, credit card systems rely on hardware protection which produces additional costs. An ideal micropayment system should not depend on the underlying hardware or the lower network levels. [23]

Economic dimension

Economic dimension consists of the non-technical economic questions that Schmidt and Müller divide into two subgroups: monetary and network economic problems. The former issues are not handled in this paper.

• Transaction costs. These are the costs the merchant must pay to be able to perform the final payment-committing transaction. The costs can be divided into direct losses - the cost for executing transaction itself - and indirect losses - e.g. rent losses.
• Atomic exchange. This requirement resembles very much the atomicity issues also Aukia and Lehmann mentioned - see [26] for further interest on the ACID properties of transactions.
• Customer base. The feasibility of the micropayments systems relies heavily on the size of the customer base. With no customers and no previous experience on the electronic payment business, the merchants may have significant startup problems.
• Convertibility. Currencies used by different micropayment systems must be exchangeable which means that they must be exchangeable also to and from the currency the bank uses - thus the currency applied in micropayment systems must have monetary value. According to Neumann and Medvinsky, several payment mechanisms will emerge, with different tradeoffs in the implemented features which is one reason why it is important that the currencies are convertible with each other [18]. [23]

Social dimension

Social dimension handles the 'soft' issues that is mainly a concern of the customers.

• Anonymity. Anonymity is defined quite the same way than Aukia and Lehmann did [1], as the protection of the identity of the parties participating in the protocol [18].
• Flexibility. The flexibility requirement means that different payment models can be used concurrently, depending on the guarantees (e.g. digital receipts confirming that the party has shown a valid identity and is allowed to buy the product) needed by the parties of transactions [18]. It should be noted that the extension of flexibility may implicate the degradation of the level of anonymity, since the different models offer different features and set varying requirements on the payment mechanism. For instance, credit card transactions often offer only partial anonymity.
• Peer-to-peer payments. Peer-to-peer payment requirement states that everyone should be able to use micropayment mechanism with any other valid party, not just asymmetrically with the merchants. [23]

In this section the security-, usability- and business-related issues described in the previous section are discussed further and some other aspects are left for smaller notice.

General issues

This paper emphasizes the security-related requirements for the micropayments, derived from the previous discussion. We are especially interested in the technical side of the security aspects and thus many non-technical issues are left purposely out of the discussion. As Neumann and Medvinsky discuss in their paper [18], a secure micropayment system must be both usable and resistant in respect of the underlying infrastructure - the lower network levels and physical devices that e.g. handle the connections and storing. Since these underlying systems usually are prone to easy eavesdropping and message tampering, they cannot be trusted to provide adequate security services. Therefore no trivial assumptions about the security level of the underlying technology should be made in respect of the design of the micropayment system. [18]

Categorization

The security issues can be categorized in many ways depending e.g. whether the emphasis of the categorization is in the security of transaction parties or protocol messages. One typical grouping consists of confidentiality, integrity, authenticity, non-repudiation, usability and authentication of which integrity and non-repudiation have already been defined in this paper. Confidentiality is basically the same thing with anonymity, the ability to remain unidentified in respect of other parties and outsiders of the transaction. It can also mean the protection of the transported and stored data from the other parties, in parallel of the protection of the identity of the party in question. Authentication is the ability to confirm that certain party really is the one he claims. Authenticity, on the other hand, is typically defined as the possibility to confirm the origin of protocol messages. Finally, usability means that the parties should be able to apply the payment mechanism easily so that they don't need to concentrate on issues irrelevant in respect of the paying. Usability is handled more in detail in the next subsection.

Anonymity

Anonymity is an especially interesting requirement in respect of both the user and the implementation of the micropayment systems. The contemporary systems - like credit card and cheque based payment systems - have usually compromised the security by giving full anonymity only to the merchants, while the user has been offered only partial anonymity [18]. The degradation of anonymity enhances the traceability of the transactions, which has often been envisioned as the device for a Big Brother -style control from the viewpoint of the customers. The possibility to trace one's own transactions can, however, also be seen as an advantage for the customers, since they are probably interested in a service that allows them to check what has been bought using their account.

Partial anonymity usually implicates the collecting of long-term logging data of the micropayments of the user [2] which could yield significant information of the purchase patterns of single users, when the protection is not at adequate level. In addition, sometimes when even a single micropayment transaction, such as request of a naughty picture, can be uncovered, the user may encounter inconveniencies. Therefore we can conclude that, as Schmidt and Müller state, it is very likely that micropayment systems with different levels of anonymity will be developed [23].

Traceability

The traceability of payment systems is a useful feature and basically a must for merchants, since any criminal or abnormal action should be noted as quickly as possible. According to Neumann and Medvinsky, anonymity is much more important in some transactions and applications than in others. In micropayment systems, however, the issue does not seem to be that important, since a single payment is usually of a very low value and the transaction costs must be pressed down. In these cases, the tracing of individual transactions may be vainless, even impossible. Though totally anonymous micropayment systems would be ideal from the viewpoints of many users, the contemporary payment systems like credit cards and cheques offer only partial anonymity [23]. This may not be a problem in every system, since the users seem to accept the degradation of the security level to be able to purchase goods easily, depending on the other features of the payment mechanism can offer to them.

Fraud and network errors

Every now and then network errors may occur that are indistinguishable from fraud. Well-designed micropayment system implementations allow exact replay of the messages to the same origin within a few minutes interval by identifying the double spending attempts. Some contemporary mechanisms, like MilliCent system (discussed in the section 7.3) allows the brokers of the system to accept low-level of complaints automatically and without any questions [14]. The complaints are logged and pattern of abuses can be used to identify the culprit - this way a suspected fraud can be traced quite easily. It is, however, absolutely impossible and unprofitable to investigate every complaint due to nature of the micropayments, as was discussed before.

The disappearing of a single micropayment is not dangerous or fatal for the security of the system or the user. The micropayment systems need not be as secure as for instance the credit card systems, since the potential loss of a single payment is not financially disastrous for any party of the transaction because of the very low value of the payments. Moreover, the data of low-value transactions is probably not valuable to the attacker as such.

Discussion

Thus we can conclude that anonymity is still a hard issue to be solved in the micropayment system. This may be emphasized in the future when the fight for advertising power will become even fiercer and the service to the users will be more and more personated probably leading to the compromising of the user anonymity. Even though anonymity and other security features described here are important, these are not the only issues in the security field, since also reliability and fault tolerance requirements set on the micropayment systems relate closely to it.

General

Usability issues form a special field of security, since they closely relate to the "softer" requirements, like the social dimension Schmidt and Müller [23] formulated in their paper. The field, however, can also include the criteria on system efficiency and reliability, like latency and fault tolerance issues. The usability criteria consist of requirements from many different dimensions which should not be separated from each other in the discussion.

Acceptability

One of the most important criteria for a merchant utilizing a micropayment system is the ability to interest new users and gather a solid customer base - so called critical mass - by offering value-added services for which the customers are willing to pay for. This may be harder problem to be solved than it seems at first glance since the micropayment markets form a completely new venture business area. Neumann and Medvinsky have defined a requirement that should be mentioned here: acceptability requirement states that the payment system must be widely accepted to be able to survive in the business [18]. We think that acceptability is also related to the social side of the anonymity issues in respect of the micropayment systems, since anonymity can be a very important feature to many users that may accept the offered mechanism more easily if adequate anonymity is guaranteed. From the viewpoint of acceptability, also the trust model applied may have influence, since the users want to know who to trust (if anyone).

Ease of Use

Usability is often described as the ability to use certain system smoothly and easily, without considerable familiarizing with the user interface of the system - an important issue also in micropayments' world. According to the ease of use requirement set by Neumann and Medvinsky [18], requesting identification and authentification information from the users before any payments can be made should not be required all the time, since the amount of transactions are high and the latency requirements especially for micropayment mechanisms are very hard. The browsing between pay-per-link web pages should not irritate the user because of high latency [1]. The user buying a web page with a micropayment system will want the page in a one or two seconds, not in 10 or 30 seconds a credit card transaction may require [7]! [18]

Authorization

Considering the usability issues, automatic authorization and other transparent features are thus definitely needed in micropayment systems. Users, however, should able to limit their losses, which may be very hard task to be managed in micropayment systems with badly-designed user control. This leads to another problem, the authorization: what is the value level, below which the customers can be automatically billed, who sets it and how can it be controlled? According to Neumann and Medvinsky, payments over certain threshold should be approved by the user. Since individual micropayments may be just a fraction of a cent, this constitutes another hard problem for the implementation of low-value payment systems: the payment services must be carried out efficiently and in a user-friendly way at the same time, still allowing the users to have control of their purchases.

Consumer Base

We still have not discussed one of the areas that have often left for little attention - the issues the business organization introducing the micropayment systems will have to handle. Many papers, like the one by Neumann and Medvinsky [18] state that the size of the customer base of the micropayment system provider is really the key issue (and possibly the bottleneck) of the micropayment business. The problem has two sides: Currently only the credit card companies and other large financial service providers have a solid and large customer base to operate with on the Internet. But what the credit card and cheque-like systems do not have currently is the micropayment-oriented systems or business models - the 'old' payment methods and models cannot seem to work for low-value payments directly. They would need to start a completely new venture business which will require a lot of investments and the system update cost may be too high for many actors. [9]

On the other hand, without a large consumer base and possibly without previous experience from the financial business in digital world, the merchants may not necessarily accept the system if the future is viewed as too risky and users do not seem to have trust on the new system. Optimists, of course, may say that for every new participant in the micropayment system, there will be 2 * (N - 1) new business opportunities (for N-participant system) [23], if we assume that the micropayments offer peer-to-peer payments. In real life, however, this will surely never be the case.

Costs

Another extremely important issue is the cost of a single transaction as well as the cost of the running the whole micropayment mechanism, as was discussed before. The introduction phase of the system will eat a lot of investments in advertising and arousing interest among new users and merchants. The micropayment systems will require additional funds for acquiring banking services, handling databases and customer accounts and a lot of contractual work with merchants, institutions, possibly government and users. But the main concern of the merchants may still be, whether any micropayment implementation as such can even ideally press the transaction costs to the level that is tolerable without any external (financial) support. [7]

User Support

Crocker [7] adds an interesting point of view in this discussion: the user support required to run the micropayment mechanism. User support includes '24/7' help desks, complaint handling, backcharging and recovering from unexpected situations like crashes that require substantial additional costs. Thus the building of proper customer service functions may become a bottleneck in respect of the business of the micropayment providers. The profit margins may be high for individual transactions, if the customer base is solid enough, transaction costs are low enough and the service request level is high enough. Still, the total profitability of the system may be close to nil. This naturally sets hard requirements from the reliability of the underlying technology to the user support. Considering these pessimistic thoughts, an additional requirement could be stated as: the need for customer service support must be optimized.

Cryptography, protocols, markup languages and software issues related to these fields of technology form the basic toolkits for implementing electronic payment systems. Many implementations may also utilize hardware-based functions, like hardware-level signatures with smart cards. We, however, leave the hardware- and system level issues for little notice - the basic requirements on these issues were described briefly in the requirements section and they are not discussed further. In this section we describe the cryptographic tools and software issues that are important in respect of the micropayment system development.

Overview

Cryptographic algorithms and protocols belong to the group of the key concepts in implementing secure micropayment systems, since the security level of the payment system depends substantially on the low-level building blocks applied. We discuss briefly only the most important issues of cryptography in respect of micropayment system implementation, without going into details. We assume that the reader is familiar with the fundamental issues of cryptography.

The basic cryptographic building blocks include the implementations of public- and secret-key cryptography, one-way hash functions and pseudo-random number generators. It should be noted that these basic building blocks can, of course, be implemented either in software or hardware level. All the low-level digital information sent and received in the cryptographic protocols, such as the payments itself (tokens), digital receipts generated for the customers and certificates needed for authenticating certain participant can basically be constructed by applying these primitives.

Public vs. Secret-key Cryptography

Secret-key cryptography is usually applied to provide so called session keys to protect a single transaction for a very short time period or to secure the confidentiality of digital receipts related to the payments. Public-key methods, on the other hand, may offer also other features than just encryption: since they use asymmetric keys, of which one is private and one is public, they can be utilized to construct digital signatures, certificates and other higher-level entities within the protocol. The advantage of secret-key cryptographic functions, especially in respect of micropayment systems, is that their implementations are very fast - the most well-known and fastest algorithms offer a couple of hundred or even thousand times faster encryption throughputs than the corresponding public-key algorithms. Another problem with the public-key cryptography is that the key management may require more resources than in secret-key cryptography. The key management in secret-key cryptography, on the other hand, may cause different kinds of concerns since the symmetric keys must always be kept secret in contrary to the public keys that can be freely distributed and published, for instance in certificates.

The choice between these must be made carefully. Since secret-key algorithms offer speed, they could be applied in latency-critical on-line phases of the protocol, while public-key algorithms are useful in respect of, for instance, off-line signing and certifying features. Since the public-key based digital signatures are needed in most of the implementations of the micropayment systems, public- and secret key cryptography features are often utilized in parallel in payment protocols.

Trusted Third Parties

The concept of the TTP relates closely to these issues, since the signing of a receipt or certificate in particular payment protocol may require the involvement of a TTP. It should not, however include any on-line requirements, as was discussed before, since the amount of individual transactions can be staggering and the micropayment protocol must optimize the latency very efficiently. In most systems the participation of TTP is a necessity, but it should be required only rarely and off-line, not during every transaction.

Hash Functions and Random Number Generators

The other primitive features of cryptography, one-way hash functions and pseudo-random generators are ofter left for smaller attention than the encryption and signing functions. Still they may sometimes form the weakest link of the micropayment system in respect of security. Therefore only well-known, publicly accepted, secure and fast implementations should be chosen as the building blocks of the system, so that attacks against them are possible only in theory or in an attacker's dreams. If, for instance, a random generator that produces too small or an uneven spectrum of random numbers is chosen, the attacker may sometimes be able to "guess" some or possibly all the values from the interval and try to apply them to the protocol one-by-one. This can easily be avoided by choosing strong random generators that produce large numbers that look random enough. The pseudo-random number generators can be used in the payment protocols in e.g. situations where the user generates a random number that will identify and authenticate the user later in the protocol and prevent double spending.

One-way hash functions, on the other hand, are very fast algorithms that produce typically a fixed-length random-looking output from input data of arbitrary size. Thus they have many uses in micropayment implementations, for instance in signatures and double spending prevention, since they can be applied in integrity checking.

Protocols

Protocol- and software-related issues are important technical questions to be answered when an efficient micropayment system is being designed. The choice of the protocol to be applied depends on the specific features required in the envisioned utilization environment with requirements on e.g. flexibility and interoperability. There seems to be three different approaches for selecting the protocol applied: According to Schmidt and Müller [23], the contemporary payment systems have applied simple payment-scheme -specific protocols that have been designed for the specific purpose in that environment, possibly omitting some of the features required in an universal payment mechanism. On the other hand, some electronic payments systems, especially the ones designed for handling high-value payments have applied existing network services like e-mail as the mechanism for transporting the payment information. The third alternative for transporting the payment data is to apply a protocol derived from a generic payment system -specific protocol. Such proposals, like MPTP (MicroPayment Transfer Protocol of W3C [29]) exist by now formed, but so far with no success. The common requirement for these protocols, however, is clear: these high-level protocols must be independent of the underlying protocol stack and network architecture so that they can be applied in as wide range of payment applications as possible. [23]

Markup Languages

The utilization of a high-level protocol is, however, not the only possible approach for implementing micropayment system. The application of markup languages in micropayments has been the interest of many people for several years already. The contemporary Internet markup languages, like HTML (HyperText Markup Language) and especially XML (Extensible Markup Language) are interesting in respect of micropayments, since the success of Internet has been based on single transport protocol - HTTP (HyperText Transfer Protocol) and markup language - HTML [1]. Aukia and Lehmann propose that the markup language standard should include definitions for a "commercial link" which could e.g. tag a price within a link leading to a commercial service or web page. One advantage of it is that if the cost of the item to be purchased is known beforehand, the customers may be more interested in the payment mechanisms and safe (see [1] for further information on the relation of the micropayment systems to HTML). For instance, W3C is currently working on a web project that aims at developing an extensible way to embed in a web page adequate information to initialize micropayments and allow several micropayment system implementations to coexist in an interoperable way (Common Markup for micropayment per-fee-links) [27]. Another interesting new invention is the ECML language (Electronic Commerce Modeling Language) [8]. It will be interesting to see whether these proposals can ever be standardized and widely accepted, the hyped ECML solution is certainly one to be watched closely in the near future.

Software Models

The micropayment mechanism is also an issue of the implementation model, whether to choose between the traditional client-server model or the newer web browser (with possibly no plug-ins) approach. This depends on many things, like protocol - what data must be transferred and stored and where in different protocol phases. The browser approach seems to be much more fit for the micropayments, since the users are very familiar with the contemporary web browsers and the client-server model with a client program that must be downloaded and installed may require substantial use of resources from the business organization, for instance user support.

According to McCrory [16], any other client solution than a browser-based one simply produces too many risks for the business and decreases profitability - the client-server model seems to set too high expectations to the unsophisticated user community of the Internet! Morever, although originally the safety and anonymity of the customer were the main goals in the payment system development, according to analyst Cliff Condon, these features may become obsolete by the emergence of standard browser security services [20]. In fact, also Aukia and Lehmann claim that standardization of the linking method will make the browser add-ons obsolete and systems easier to use [1]. Thus the model of a thin (or non-existent) client with the well-known 'de-facto standard' browsers could lure many more customers at system startup than a large software module that must be installed to the personal computer.

Thoughts on Implementation

Finally, Neumann and Medvinsky have formulated two requirements for payment system implementations that we think are important also in respect of micropayment mechanism: Ease of Integration means that a common API (Application Programming Interface) for electronic payments should be defined so that the mechanisms would not be specific to some payment instrument (like credit cards). The other requirement states that ease of use and integration should be addressed mechanism-independent way. In this way the integration cost does not duplicate for every new system. According to Neumann and Medvinsky there is also need for a common API, standard user interface and conversion of instruments between different payment services. [18]

Thus we can conclude that the implementation and protocol issues of the micropayment system should be independent of the underlying platforms an network service infrastructure. The key concept seems to be the standardization of certain proposals, like micropayment-specific new protocols and web-based markup languages. Without the standardization and the modularity and independence features discussed, the payment mechanism may never reach public acceptance among the actors of the Internet business.

In this section a few proposed micropayment schemes and already existing systems are represented. Three well-known mechanisms which have been in test use in public networks systems are compared to each other and evaluated to the criteria discussed before in this study.

Today there is a variety of schemes and systems proposed in the Internet that can be utilized to handle micropayments. The processing of very small amounts of money seems not be a problem for any of them as such and perhaps surprisingly, it has actually never been the main problem. The primary concern has been the question: how to keep the cost of an individual transaction low enough?

Two simple micropayment schemes were presented by Rivest and Shamir in May 1996. They are intended for making small purchases over the Internet. The first scheme, PayWord, applies the credit-debet model and is based on chains of 'paywords' (hash values) and the second scheme, MicroMint, was designed to eliminate the costly public-key operations altogether [22]. The implementations of MicroMint scheme seem to offer better speed but lower security level than PayWord - a prototype implementation of MicroMint was presented by Burstein in May 1998 [3]. Although its feasibility in real commercial applications is still a question to be answered, the prototype implementation itself has generated a few future work ideas.

Currently there are quite many micropayment technology providers. A good and rather comprehensive list of them can be found in W3C's page Micropayments Overview - Section Related Reading [28]. The competition in the Internet commerce is tough, also in the world of micropayments. For example, one of the early players, First Virtual has left the business and their project is discontinued. They exited the payment business in July 1998. [4,21]

CyberCoin is a quite new proposal from CyberCash, Inc. It is meant to compete as a micropayment protocol. Their first scheme, named CyberCash is an electronic credit card scheme. The scheme as such, however, seems to be not feasible from the viewpoint of the utilization in the micropayment systems, since the transaction costs cannot perhaps be pushed to a tolerable level by just applying the methods designed originally for credit card handling.

To be able to purchase an item, the buyer first sends a payment order to the merchant who forwards it to CyberCash Gateway Server for verifying. Both buyers and merchants have an electronic wallet of their own. The wallets are required for bookkeeping the financial information of the parties but no actual value, such as the account balance, is stored in the wallet - this is a big difference between CyberCoin and other payment models. The funds are held in escrow in a proxy account set aside for the particular buyer at CyberCash's bank in Virginia, USA [1]. The processing of the transactions does not require inter-bank clearing [1]. The wallet system supports both CyberCoin and CyberCash.

According to the very concise documentation that is available, the CyberCoin system seems to resemble the credit card model a bit, as can be seen from the Figure 2.

As far as we know the CyberCoin protocol has never been published [1]. Most of this analysis is thus based on hypothesis by Aukia and Lehmann.

The flow of Money

1. To be able to use CyberCoin system the buyer must have executed an off-line withdrawal of electronic money onto the wallet.
2. The buyer wishes to initiate a purchase by contacting the merchant.
3. The merchant receives this request and sends the buyer the electronic merchandise encrypted with DES (Data Encryption Standard - a block cipher developed by IBM in mid 70's), without the corresponding DES key.
4. The buyer confirms the purchase and acknowledges that he has received the purchase request data by sending back the notational order which contains the financial information about buyer's account. This transferred data must be hidden from the viewpoint of the merchant.
5. The merchant sends this payment order to CyberCash for verifying purposes.
6. Then CyberCash sends its approval to the merchant if the payment order is valid. It should be noted that CyberCash need not contact the actual bank for this transaction because CyberCash maintains the equivalents of the accounts of both the buyer and the merchant. The buyer's and the merchant's wallet balances are adjusted according to the payment value of the purchase.
7. Finally, the merchant can send the DES key to the buyer who can decrypt the previously received encrypted digital goods. [1]

Aukia and Lehmann make an assumption that the authentication is performed by the use of RSA (Rivest-Shamir-Adleman a public key encryption algorithm) digital signatures [1].

Digital Equipment Corporation, which is nowadays a part of Compaq Computer Corporation, has presented their proposal as a micropayment system, MilliCent, that is perhaps the smallest and simplest implementation of the contemporary systems. The system has been in beta tests and it is very well documented and thus rather interesting. The mechanism is basically a very simple protocol for two participants which is extended in the realm of systems to cover a multitude of payment situations. It is, however, designed for the handling of a series of inexpensive and casual transactions. [1]

Instead of using traditional money for purchases, the MilliCent implementation is based on a new kind of currency that is called scrip. Scrip is an electronic manufacturer coupon that has a pre-paid value, just like the conventional cash does. It has an intrinsic value, but it is valid only with a specific vendor. In other words, it can be spent only in the context to which it was originally meant. The Figure 3 presents the basic idea of the protocol. More detailed information is available on the home page of the MilliCent system [5].

In the MilliCent system, scrip is issued by brokers that act as simplifying intermediaries between customers and content vendors [6]. The brokers represent a sort of agents that produce scrip on behalf of many vendors. An unused scrip associated with one vendor can definitely be exchanged, via a broker, for a scrip of another vendor. When a customer wants to buy a MilliCent scrip, just a simple click of mouse button is required to start the purchase transaction. The whole process operates automatically in the background.

The brokers can make a profit if they buy scrips in bulk from vendors at a discount price and then correspondingly reselling these to customers at a retail price. Of course, the customers can also buy scrips directly from the vendors. The use of the brokers, however, eliminates the need for customers to set up accounts with multiple content vendors [6].

The flow of Money

>From the viewpoint of electronic commerce the MilliCent protocol will not alone be sufficient because there is no direct way to transform ordinary money into scrip and vice versa.

Building up a relationship in the MilliCent system can be described for instance like this:

1. The customer requests a broker scrip.
2. The broker sells the scrip to the customer.
3. The broker requests a scrip from a vendor.
4. The vendor sells the scrip to the broker. [24]

One purchase scenario in MilliCent could go like this:

1. The customer sends a request to the broker for a specific vendor scrip along with the broker scrip bought previously.
2. The broker sends the vendor scrip back along with the possible change in the form of a new broker scrip.
3. The customer send the scrip to the vendor.
4. The vendor accepts the scrip, delivers the service and sends back the possible change in the form of a new vendor scrip.
5. The customer sends the possible vendor scrip to the broker.
6. The broker changes it back to a broker scrip and sends it back to the customer. [24]

The micropayment system proposal from International Business Machines Corporation (IBM) was previously named as MiniPay. The IBM's implementation is a registered payment system in the working draft, Common Markup for micropayment per-fee-links from the W3C group. Its registered short code name is known as mpay [27]. To avoid confusion later in this paper, we will use this short form name when we refer to this micropayment system of IBM. In that W3C working draft the current list of registered payment systems includes only three implementations, mpay, MilliCent (mcent) and France Telecom Micropayments (mft).

Mpay is intended for very small payments. The system has been in internal tests and is also available to anyone in the Internet for testing purposes. The system version 1.3 [30] was released in October 1999. Mpay system implementation is very similar to the normal billing mechanism of the third party value added services of the phone networks [1]. Mpay would not be very suitable for high-priced purchases because the design of the whole system is aimed for selling inexpensive information and other similar services which are usually delivered on-line. This is reflected in the protocol [1].

To be able to use mpay the buyer must connect every day to the server of the access provider who will send a daily certificate to the buyer. The signed certificate states that the buyer has an account and tells the recommended offline limit for the daily purchases. The protocol is shortly presented in the Figure 4. A more comprehensive model description can be found from IBM micropayments' home pages [12] and from the paper by Aukia and Lehmann [1].

The flow of Money

The financial structure of Micro Payments from IBM is based on the idea that issuer could be the client's ISP (Internet Service Provider) and the acquirer could be the merchant's IAP (Internet Access Provider - a subset of ISP). Thus agreements would be required and the added cost of billing for micropayments would be smaller than for a company with no previous relationships with either the clients or the merchants. [1]

The three previously presented micropayment systems have been compared with each other. Comparison criteria is based on those presented in section 4 and also some selected references are used [1,24,30]. For a more comprehensive evaluation and comparison of the systems the reader is adviced to take a look at those papers.

A separate wallet software of their own is required in all these three system implementations. For mpay it was still optional in version 1.2 but now the latest version also requires it.

In this section we emphasize the primary advantages and disadvantages of the different payment models that are interesting in respect of the micropayment systems. We also discuss the primary problems of the contemporary systems.

Electronic currency model

An advantage of the electronic currency model is that the payments offer (possibly full) anonymity to the user [18], which may encourage some potential users to start using the payment mechanism. The anonymity is an important issue also in respect of the micropayments - the purchase patterns of individual users can be protected.

Disadvantages, however, also exist: the servers that handle payment transactions need to collect data from the past transactions to prevent the double spending of the tokens. This leads to the problem of large databases in these payment systems [18]. Moreover, in micropayment systems applying this payment model the number of transactions to be logged may be huge (certainly larger than e.g. in credit card systems), thus requiring substantial storage and processing capabilities from the servers that handle the transactions. These requirements also make the tracing of the payments harder from the viewpoints of the merchant and bank. [18]

Credit-debet model

One of the main advantages of the credit-debet model is the auditability of the transactions which is certainly a pro from the viewpoint of the merchants and banks. The transactions can always be traced so that it can be determined, "who paid, how much, for what, with which instrument and when". This implicates that these systems often lack implementation of full anonymity. The model is most important in respect of business applications, not for micropayment systems intended for wide and public use in the Internet. In addition, this model does not require substantial processing for every transaction because of the accumulating payment method it applies. [18]

Disadvantages do exist - one of the problems in this approach is that the storing and processing capabilities for user accounts are needed. In addition, conversions between electronic currency applied, the balance of the user account and the "real" money the bank handles is needed [18], since the paying is based on the accumulation of the payments. To achieve this, contractual agreements with merchants and customers are required, which always causes additional stress for the customers. Morever, the implementation of this payment model (with payment accumulation) causes imbalances that must be explicitely settled, at least as long as the traditional bank systems cannot be adjusted to the world of digital payments. Another problem in this model is that according to Schmidt and Müller [23] the customer bases of the merchants have not been in the level that makes the running of the business profitable enough. [18]

Secure credit card model

A principle advantage of the secure credit card model is that the user need not be registered to the payment service, only the transportation of the credit card number is needed for instance in encrypted form [18]. Another important advantage to be noted is that the credit card organizations already have business experience of the similar systems they have established name in the world and many of them have very large customer bases already.

The principal disadvantages in the context of the micropayments is that the costs to run the business seem to be too high, since the credit card transactions - also with micropayments in this case - are processed with the existing systems designed to handle the payments valued tenths or hundreds of dollars [18].

Conclusions

It seems that the latter model of the secure credit card transactions does not meet the micropayments requirements, the technology and business model of these systems are not suited for low-value payments. On the other hand, the second model with credit-debet approach does not offer strong anonymity and may be too inflexible in respect of currency conversions and the account handling. According to to work of Schmidt and Müller the credit debet model with electronic checks seem, however, to be best suited for constructing micropayments systems [23]. In contrary, the electronic currency model with innumerable transactions of small token-based payments may set too hard requirements for the resources needed in the system implementation. Even though the credit card model is seemingly least suitable from the viewpoint of implenting a working micropayment system, all the three models lack some essential features and have disadvantages considering an ideal micropayment system. Therefore perhaps a successful micropayment system should have features from all of these systems as long as the new system is designed from the viewpoint of micropayment requirements and features and not by just taking the union of the useful properties of the existing mechanisms.

Aukia and Lehmann [1] state that many contemporary systems cannot handle high loads of very low cost payments in cost-efficient manner, because the systems are not especially tuned for handling transactions of this kind. Considering this, the systems which can handle the majority of the protocol functions off-line, have latency- and cost-related advantages. In addition, these systems seem to model the partial off-line features rather well already. On the other hand, applying on-line request mechanism may result substantial long-term storing capability requirements especially when the payment traffic is heavy - on-line systems are as weak as the link to the buyer. [1]

Crocker [7] has discussed the problems of the contemporary micropayment systems in general. He states that the micropayment mechanisms of today have required too much and too heavy authentication from the customers - possibly multiple screens for every transaction. This may work for high-value transactions but not for low-value micropayments which must be able to be handled very fast and transparently from the viewpoints of the demanding customers. Another problem with these systems has been the latencies in the processing of the user accounts - the micropayments should not require these kind of operations during every transaction. The payment systems with incremental cost features, however, may offer a partial solution to the problem. [7]

According to Crocker, the contemporary micropayment systems have been in trouble because of the amount of participating merchants has not reached adequate level - thus the critical mass of customers and merchants has not been attained. Perhaps the amount of purchaseable and interesting low-cost intangible goods is still too small. Crocker claims that merchants may not be the ones that introduce successful payment mechanisms - the incentive may come from companies offering financial, services when a group of powerful actors, perhaps large publishing companies demand it loud enough. [7]

Because there is still a lot of to implement in the contemporary systems we think that none of existing implementations would totally solve the use cases presented in the introduction section. MilliCent and IBM Micro Payments look currently as the most promising alternatives.

As we have pointed out, there is still a lot to do in respect of building a working micropayment system, both from the technological, usability-related and commercial points of views. The areas in which there is still a lot of work to do are described below.

The technological issues - some technological requirements like low latency, have not been met in the contemporary micropayment systems, especially those intended for public and wide utilization. The technology of electronic payments will surely evolve: the networks and servers are getting faster and the micropayment implementations are probably optimized better in the future, which may solve the latency problems and lower the currently too high transaction costs. Still, the technological issues must not take anything away from the usability. If the micropayments are too hard to use, only marginal user groups may be interested in it.

The low-value payment model - as we have said, the contemporary micropayment systems have applied the payment models designed for electronic payments in general. Unfortunately these models are best suited for payments, say tenths or hundreds of dollars. To be able to note all of the important micropayment requirements, the design of the payment system should be executed from the viewpoint of the low-value payment model. Another problem with the micropayment systems has been that while technology aspects have been widely discussed, the business models and other non-technological issues have often been left out of the discussion. Moreover, it should be noted that the micropayments are not just downsized large-amount payments - the transactions for intangible goods are truly different from e.g. the credit card payments. It seems that development of a successful micropayment mechanism require especially new approach in respect of functional design and business models. [9]

Lowering the prices - many contemporary sites sell web pages that cost a dollar or several dollars. This obviously is too high bid for a small article or a comic strip, since the pricing of an item like this is reasonable only if the item can offer truly value added service. Moreover, the prices of the goods like these should be known beforehand, which is not always the case. The real low-value payments - those of e.g. a cent - should be enabled by the micropayment systems of the future. [19]

Life without subscription - the subscription to the sites with micropayment capabilities is seemingly a bad idea, it does not attract newcomers at all. The micropayment approach requires that the users can freely move from a site to another, buying items that cost only a couple of cents, without the bother of registration. [19]

New venture - the micropayments are a new venture, the risks are high and the interest in these systems is not wide enough. But in the future this may change, as more and more proposals are implemented, introduced and tested with larger and larger customer bases thus adding to the experience of the system developers, users, merchants and other actors. According to Clark, 1,8 trillion dollars was spent last years on transactions lower than 10 dollars [4]. If the spectrum of the offered goods in the Internet can reach the critical mass, the problem of too small customer bases may be relieved in the future. [7]

As it was discussed in this study, the contemporary payment models seem to lack many features a successful micropayment system should have. The requirements this kind of system must meet are rather tough, both by their number and variety, so no system seem to be able to fulfill all of them. Even though the payment mechanisms of today have usually not even tried to include all the needed features, they still have failed to gain significant success because of the many problems described in this study. In fact, perhaps the development towards successful micropayment systems would still require new implementations in technology- and businesswise so that experience of the mechanisms in the Internet can be gained bit by bit. By allowing the systems to evolve in time, they can be tested thoroughly in demanding environments and large-enough customer bases, thus giving the developers a better picture of what the micropayments are all about. The problem in this approach is, of course, that the trials and development demands substantial financial resources and a lot of work.

It seems that no universal micropayment system can be constructed in the near future, thanks to the anarchic structure of the Internet which has no central authorities. Moreover, there is still simply too many open questions from the institutional, economic, social and technological points of view. The development of non-interoperable and environment-specific payment mechanisms seems probable and in some cases even feasible approach in the near future. Several mechanisms may coexist in the business using different currencies, fighting for market shares and trying to acquire as many customer bases, merchants and large financial companies behind their backs as possible. There will probably be many losers, but will there be any winners? We will see.

For comments and advices the authors wish to thank our tutor Yki Kortesniemi, professor Arto Karila, Administrative assistant Marja-Leena Markkula and our opponents Erka Koivunen and Matti Mäenpää.

A lot of micropayments and microcommerce related terms are available in Web. For example the following links could be useful alongside with the references of this study.

Link Lists

• Small change: Micropayment
• Jan97-Microcommerce or Payments
• eCoin: Micropayment Links
• Micropayment

Technical Research Papers

• Electronic Micropayments
• Ronald L. Rivest: Publications
• NetBill Security and Transaction Protocol
• NetCard - e-payment mechanism for electronic commerce - Deliverables/Publications
• Micro-Payments based on iKP

Reports and Articles

• Millicent: FSTC General Meeting, New Orleans, LA
• Micropayments are Crap the same as an archive file
• Micropayments: No Small Change
• Micropayments still the Internet dream

Micropayment Implementations

• MilliCent glossary
• CyberCash Glossary of Terms - CyberCash and E-Commerce terms defined
• Micropayment Bookmarks
• Tech Report: HPL-97-14: Evaluation of Micropayment Schemes
• Transaction Net: Micro payment methods online
• Payment mechanisms designed for the Internet
• eCoin Home -- Your Internet Micropayment Solution
• What is Clickshare and what does it do?