Amir Herzberg and Hilik Yochai
Network Computing and Security Group
IBM Research - Haifa Research Lab - Tel-Aviv Annex
Many promising Web applications could benefit from a payment mechanism for small amounts (micro-payments). Payment by credit cards, which is the common method for on-line consumer purchasing, involves substantial per transaction fee and delay, and are therefore inappropriate for micro-payments. We present MiniPay, a simple system for supporting micro-payments. MiniPay features low cost, negligible delay, natural user interface, scalable design, support for multiple currencies, and high security - including non-repudiation, overspending prevention, and protection against denial of service. MiniPay is currently being piloted with several potential providers.
Many promising applications and services on the Internet depend on an ability to pay small amounts (for information, services, games, and loadable software). Currently, such services and applications are funded by advertising or by subscriptions. A direct payment mechanism would be a great complement for these funding methods, especially to facilitate smaller vendors. Most existing proposals for payment mechanisms, such as SET [SET], support payments based on the existing credit cards infrastructure and backbone network. These involve a substantial per-transaction fee (typical 20 cents minimum), and are therefore inappropriate for payments of small amounts. Therefore, a new payment mechanism, for these `micro payments`, is required. Such a mechanism is presented in this paper (under space constraints; for more details, and more updated version, see our site [HY97]).
Payment is an important aspect of the modern economy, and there are several payment mechanisms which are well established for many years: cash, checks and charge cards among the most important. (see historical review [D97].) Charge cards are the common means of payments by phone, since the semi-secret card number can be passed to the seller over the phone (while physical cash and checks cannot be passed by phone). However, in the last few years, many new schemes have been presented, and quite a few were implemented or are being implemented. There were at least three different motivations for introducing new schemes, rather than passing credit card information as with phone orders:
Our main motivation is the third one, namely design of a payment mechanism appropriate for selling inexpensive information and services, usually delivered on-line. Payments of small amounts may enable many exciting applications of the Internet, such as selling information, software and services (e.g. directory search or games). Therefore, it is important to develop payment mechanisms which would be inexpensive (in percentage) even for small amounts (say, one cent and above). Limited support for anonymity would be added in later versions.
There are many factors to the substantial minimal-fee requirement of existing payment mechanisms. In order to design a mechanism with much reduced costs, we need to consider - and minimize - each of these cost factors. Here is a list of the major cost factors, and the method for eliminating or reducing them in MiniPay.
In addition to these, it is critical to minimize the cost of publishing information and services per fee. In MiniPay, we reduce the expense and effort required to publish by an automated compiler tool, that transforms a site from existing HTML format so that some links become MiniPay links (which are not free). This allows the content provider to use any HTML authoring tool and even modify existing sites (especially attractive to sites that offer presently only subscription-based services).
Existing payment schemes have significant delay. The basic cause is the delay of the on-line authorization through the credit card network. With SET [SET], there are also many public-key operations per purchase, which result in substantial computation burden as well as delay.
Mini-Pay has negligible delay, and small computational overhead. This results from the following techniques:
MiniPay also allows optimization of the storage requirements of the log of transactions. Transactions are accumulated, and signatures are exchanged on the agreed balance, so that the individual transactions do not need to be kept for long.
A key requirement for successful payment systems is universal acceptability, i.e. the support of payments between any pair of buyers and sellers. Specifically, it is important to avoid restrictions such as compatible needs (e.g. barter vs. gold), direct trust (personal checks or IOU notes, vs. charge card and bank notes), physical proximity (cannot send cash over the net), or common provider for buyer and seller (key differentiator between credit card brands). Obviously, acceptability is a challenge to any new payment mechanism. The problem is more complicated as payment mechanisms must also be scalable - i.e., be able to support the entire Internet population - which implies many competing offerings.
MiniPay is designed to maximize acceptability, by avoiding the establishment of any central organization or server. In particular, there would be no `brand`. New billing servers would be able to offer interoperable MiniPay services, by connecting to other existing MiniPay servers. Payment orders would be routed among the servers, similarly to the routing of IP packets (and to the ability to connect additional routers without centralized coordination).
For example, the customer's wallet selects a public / private key pair, sends the public key to its billing system (typically its IAP) protected by a password received from the IAP (e.g. via mail). Then, the IAP would sign (certify) the public key of the customer. Similarly, the public key of the IAP itself would be certified by its peers, who in turn are trusted by their sellers. More details are given below in the description of the protocol and in particular the distribution of the public keys.
There was a substantial number of recent works, proposals and systems attempting to provide low-cost payments over the Web. The most closely related to MiniPay is Agora [GS96], since it also proposes to use offline authorization for most purchases. (MiniPay was developed independently, and indeed we presented many details of it, including the offline authorization mechanisms, in a presentation `Secure payments over the Internet`, in our site as of August 1996; at that time we called it microSET). However, Agora was implemented as a Java applet, which - as the authors indicate - is completely insecure (in fact the `wallet` is always sent from the seller). Furthermore, Agora is not scalable for multiple reasons, e.g. it supports only a single bank (billing system), and it does not address the problems of key distribution, refunds, fees and buyer-defaults. Agora also involves more messages, for goals which we believe to be unnecessary in many `pay per click` applications (e.g. receipt, signed offers), and is less efficient in several aspects (e.g. logging of transactions, expensive revocation mechanism).
Several works attempt to support low-value payments, by avoiding the use of public-key cryptographic operations. The assumption is that these operations, which are computationally intensive, result in significant cost and delay. These works include NetBill [CTS95], NetCheque [NM95], NetCash [NM93], micro-iKP [HSW96], MPTP [H95], PayWord and MicroMint [RS96], Millicent [M95, GM*95 ], chrg-http [TL96] and Subscrip [S96]. There are also some deployed systems which base their security on a shared-key authentication by a trusted server (hence avoiding public key operations), e.g. Click-Share [C95] and First Virtual [FV]. While a complete comparison to these works cannot be done here (due to space constraints), we note that all of them involve on-line authorization checks with a centralized authority; we found that this results in much more significant delay and costs than the few public key operations we need. We note that micro-iKP and Millicent avoid on-line verification on repeated purchases from the same seller, however on-line verification is required at the first purchase. An exception is MicroMint, where on-line communication is not used, however MicroMint suffers from other problems that affect most of these proposals - complex design, and less confidence on their security due to the use of new cryptographic primitives, the concentration of trust in a centralized server, and the lack of non-repudiation. Furthermore, most of these proposals are not scaleable due to their centralized design.
There have been also several announcements of payment systems targeted at low value payments by different companies, however we could not find technical details on these, including CyberCoin [CC], GC-Tech [GC], and CyberCent [CC1].
The security goals of MiniPay are as follows:
We note that several security goals have been left out of this limited scope, in order to keep MiniPay simple and efficient. In particular, the customer does not receive a receipt after the payment, or a signed offer specifying the goods before buying; the privacy of the transaction is not guaranteed; the buyer is not prevented from redistributing the content bought; and anonymity is not supported. All of these would require additional messages, and are not required for many applications. In fact, most of these goals could be implemented by complementary mechanisms to MiniPay. For example, confidentiality of the transaction information can be simply achieved, if desired, by using SSL between seller and buyer. Similarly, intellectual property protection can be achieved by selling the key to a Cryptolope [IBMC] which protects the contents. And, limited anonymity may be achieved by the use of temporary accounts, and minor extensions to the deposit protocols to hide the identity of the specific seller from the IAP. We are considering whether to add these mechanisms to MiniPay.
MiniPay is very similar to the billing mechanism for third-party added value services,
implemented by phone networks (900 numbers in the US). The typical MiniPay
system would consist of four to six parties. A typical five parties scenario
is shown in Figure 1 (see better
figures in our site). The parties are:
MiniPay build on, and extends, the existing account and billing relationship between the IAP and the buyers, and similarly for the relationships between the seller and its ISP. Banks would use the existing relationships among them and the existing relationships with the IAPs and ISPs to provide the exchange services. Note that in many cases, IAPs and ISPs already have established relationships and mechanisms to transfer funds, in particular when they are phone companies. Note the similarity in rules and motivations to the 900 number service. The billing systems may also be implemented by other companies rather than IAPs and ISPs, especially those who have the proper customer and account relationships (e.g. banks, phone companies, utility companies, large content providers, on-line community, or an internal billing server for employees). However, for convenience we will refer to the billing servers as IAP and ISP throughout this manuscript.
Figure 2 shows the basic protocol flows of MiniPay. For simplicity we focus on the four party case (without any exchange) - in Figure 2 and in the rest of the presentation. Figure 2 shows only the most important flows for the operation of MiniPay (for more details see section4).
MiniPay focuses on optimizing most purchases, by avoiding or minimizing additional communication, and by minimizing (computationally intensive) cryptographic operations. In most cases, MiniPay purchases do not involve any extra messages above the normal browsing messages. Specifically, the buyer sends to the seller a signed MiniPay payment order, piggybacked on the normal GetURL message sent normally from browser to server. The payment order also includes a daily certificate, which is provided - daily - from the IAP.
The seller would verify the signature of the IAP on the certificate, thereby confirming that the buyer is still in good standings with the IAP, and learning the public key of the customer. The certificate also includes recommended offline limit, which the IAP suggests that the seller will use as the offline limit. The offline limit is the maximal amount of purchases per day that the buyer can do, before an on-line confirmation from the IAP is required. The IAP can recommend a limit based on its knowledge of that buyer; but the seller is responsible to set its own offline limit, using the recommendation or not, based on its experience with this IAP (this is part of the economic model). If the daily limit is not exceeded, the seller would immediately respond to the GetURL message with the payment order by sending the requested information back (and/or performing the requested service).
If the seller finds that the total spending by the buyer on that day, in this seller, exceeds its offline limit, then the seller will contact the IAP, by sending an Extra-spending request message. (The seller can also do this concurrently with fulfilling the order, to minimize the outstanding amount while minimizing delay.) The IAP would update the known spending by the buyer with the amount in the Extra-spending request, and would send back a signed Extra-spending reply with either approval of some additional amount to spend before asking again, or by refusing. We expect the use of the extra-spending mechanism to be relatively rare.
At fixed periods, the seller would aggregate all the payment orders received from all buyers, and would send them as a single, signed deposit message to the ISP; this is the beginning of the clearing process. The ISP, in turn, would periodically aggregate payment orders from all of its sellers, and route them to the corresponding IAPs, in signed deposit messages. This amortization of the overhead in this process provides high efficiency, much like the routing process used for physical checks today.
At the end of each day, or at the first purchase of the following day, the buyer's wallet would contact its IAP, for their daily process. In this process, the IAP would confirm agreement on the purchases for one day earlier with the wallet - in particular, informing the wallet if there were purchases which the seller failed to deposit, e.g. due to a power failure, so that the balance of the buyer in his wallet matches the balance at the IAP. The IAP and the wallet also sign the balance and sum of purchases to each other, which may allow them to erase some of the records. The signature of the IAP also serves as the daily certificate which the buyer wallet appends to each payment order.
We note that all of these operations are done automatically by the MiniPay modules at each of the parties - the wallet of the buyer and the modules of the seller and of the IAP and ISP.
It is quite likely that the customer's billing server would not be able to interoperate directly with the merchants' billing server. This may be caused by the lack of proper trust relationships between the payment systems, or by the use of incompatible protocols. In these cases, an Exchange may offer intermediation services to enable payments. This is what actually happens in most credit card systems; it is also the design of the Click-Share system. MiniPay supports this in two ways. First, the clearing process allows for additional billing servers between the IAP and the ISP to act as exchanges. Secondly, MiniPay also supports a routing protocol, which allows exchanges to distribute the identities of the IAPs and ISPs they are connected to, and the fees involved. The routing protocol would ensure an efficient competitive market which will keep rates low (more on this in the discussion of the economic model below). For lack of space, we do not describe the routing protocol.
For higher efficiency and reduced costs, MiniPay does not include refund/return mechanisms or policy - `All sales are final - no refunds, no returns`. We believe that bad sellers would be quickly out of business - and buyers can use numerous available and emerging Internet technologies to warn others or to restrict their shopping to reliable sellers (e.g. Platform for Internet Content Selection (PICS)). Of course, individual sellers may offer refunds, returns and exchanges to their customers - and MiniPay will enable them to do this. This policy implies a limit on the total MiniPay transaction per day (of 25-50$), due to laws protecting consumers in most countries [H96].
MiniPay does deal with normal communication problems in a simple way - reloading the document bought is free. In most cases, reloading the page by clicking again on the MiniPay link will also be free, with some exceptions, e.g.: pay per service or per game.
A central part of MiniPay design is the creation of the economic incentives that would create a positive process thru which all the relevant parties - buyers, sellers and billing systems (IAPs, ISPs, exchanges) - profit and benefit. A key goal of this process is to create an open competitive and efficient market, in which the fees charged by the billing systems would be kept low, and most of the money paid would be received by the sellers. A complete description and analysis of this subject is beyond the scope of this work; we will give some general idea, focusing on the major problem - proper rewards to motivate the billing systems (IAPs, ISPs and exchanges).
In order to motivate the billing systems, they will receive a part of every transaction. The problem is to design the system so that billing systems compete on these fees. For example, if consumers are insensitive to the price charged by their IAP as a commission from the sellers, then some IAPs may require hefty commissions (e.g. half of the sale cost). The only option to sellers would be not to accept any payment from these IAPs and their customers. This would give the IAP the ability to charge high fees.
In MiniPay, the IAP charges only the buyer. Similarly, the ISP charges only the seller. MiniPay buyers' wallet and seller software allows buyer and seller to use multiple accounts at different IAPs and ISPs, and to select the one to use dynamically, based on the current rates. Hence, IAPs, ISPs and similarly exchanges are motivated to set competitive prices.
Similar analysis and mechanisms are behind MiniPay's support for multi-currencies. A more subtle economic analysis justifies the off-line limit mechanism (the IAP is motivated to recommend correctly).
MiniPay was designed to support `click and pay` applications, where the user buys the information or service as a part of the browsing process. A central goal was to make buying information and services as painless as possible - we believe the user should not suffer more difficult or slower interface, just because he or she has to pay! One aspect of this was the emphasis on minimizing delay; another aspect is the user interface. Buying with MiniPay is a natural extension of the familiar web surfing interface: to buy information or service, the user just clicks on a MiniPay link, much like clicking on a normal hyperlink.
However, we must ensure that the user pays only intentionally, i.e. the seller cannot trick the user into pressing a MiniPay link without the user being willing to pay the price charged. To this end, we made minor modifications to the existing user interface of hyperlinks, by adding cues for payment. Specifically, when the cursor is over the MiniPay link, its shape changes to either a dollar (if the amount is over a user set threshold) or a cent sign (if the amount is under the threshold). Furthermore, the exact price is indicated in message/status area of the browser (where it normally writes the URL of the hyperlink).
We note that when shopping for physical goods, it may be better to use a different user interface, such as a shopping cart interface where the user can view and compare items added to his or her shopping cart before making a payment for all of them.
We implement the MiniPay wallet with the Netscape Plug-in [NS, O96] mechanism. This mechanism allows the tight integration to the normal browsing process as described above, while maintaining the required level of security. Namely, the plug-in is a trusted piece of software installed by the buyer, with access to secure files stored on the buyers' machine (or on a smartcard). A result of this is some dependancy on the browser - specifically, MiniPay works well with Netscape browsers (version 3 and higher) and with Microsoft Internet Explorer (version 3).
We note that as a Netscape plug-in, each MiniPay link has its own window; therefore, it should be impossible to interfere with it from any Java, Javascript or ActiveX elements (even in the same page).
We considered alternatives for tightly-integrated wallet implementations, mainly Java and JavaScript (or their combination). However, currently, Java and JavaScript are normally loaded from the server (in our case, the seller), and therefore insecure. Java applets may be local, however currently the popular browsers do not allow local Java applets and classes access to access files and behave as other user-loaded programs. Therefore, we believe it is impossible to implement a secure wallet entirely in Java version 1.0. This may change soon, with the introduction of secure Java applets in version 1.1 - however this version is not yet supported in popular browsers. In particular, work is in progress on integrated support in Java for wallet for multiple payment mechanisms (JECF). We will probably re-implement the wallet on these platforms when available.
Since MiniPay is invoked as a Plug-In, the information needed for the wallet to form the payment order resides in the HTML page which contain the link, in the form of an EMBED tag. We now describe the relevant EMBED tag attributes - some of which are general EMBED attributes, others are MiniPay specific. For more information on Plug-Ins and EMBED tag attributes, see [O96] or Netscape Plug-in information [NS]. Here is an example:
<EMBED src= minipay.mpy height= 30 width= 176 costs = "(price1,curr1),(price2,curr2)" PlugInsPage = "install-URL" merchant_id= "19@seller.com" url= "today/sports.html" SiteName= "today/." ValidFor= "100" Merchant_prog="http://seller.com/cgi-bin/merch_cl.exe" text= " Buy the full page " version= "D.7"></EMBED>
The parameters are:
Additional optional parameters:
In many applications of MiniPay, the prices are determined dynamically by the seller's server while generating the MiniPay page. In these cases, MiniPay will pass the price paid to the seller's CGI code rather than directly verifying the price. The seller's CGI is responsible for first verifying the price, then providing the service.
In this section we describe, in high-level and minor simplifications, each of the protocols that are part of MiniPay. In particular, we assume that the buyer knows the public key and identity of the IAP, the seller knows the public key and identities of the IAP and ISP, and the IAP and ISP know each other. Also, we ignore the fees taken by the IAP and ISP, and do not describe the routing protocol which deals with them. Also, we set the periods used by the protocol to be arbitrary one day. These details would be given in a more detailed/technical description.
Each protocol involves just a pair of parties. We use the following Notation:
Parties: B (Buyer), S (Seller), IAP, ISP
Keys: the public key of party x is denoted PUB_x, and the private key is denoted PRIV_x.
Signatures: S_x(msg) denotes a signature over message msg by party x. Most messages are signed (e.g. S_B(Pay_order(...)). Currently implemented by RSA.
Hash: H(msg) denotes a one-way hash of message msg, which all can compute (given msg) but tells `nothing` about msg, also it is hard to find different_msg such that H(msg)=H(different_msg). Currently implemented by MD5.
Time: the value time denotes the concatenation of time and date using the local clock. Time of messages received is always checked to be within reasonable skew from local time and for replays (multiple use of the same time).
The registration protocol is used to establish account for one party at its partner, and certify the public key associated with this account. The most typical case is for a consumer to open an account with its billing system (typically the IAP). However, the same protocol is used to establish the public keys between peer billing systems (e.g. IAP and ISP, or IAP and bank), and between the seller and its billing system (typically, ISP or bank).
This protocol is run once at the beginning of each day (or at the first purchase of the day). It provides the buyers' wallet with a daily certificate from the IAP. The protocol also exchanges the total balance of the previous day, thereby allowing both sides to erase old transactions from the log (if they agree). Note that the balance known to the buyer may be higher than the balance known to the IAP, if some sellers failed to deposit the payment orders.
This is the payment order message, piggybacked on the GetURL request.
We note that the signature operation may be reused to authenticate additional purchases. In order to achieve this, the buyer would add to the (signed) payment order a hashing of random value. In subsequent purchase, the buyer would not perform a public key signature operation, but only expose the hashed value. We did not implement signature reuse yet, since the delay of the public key operation was so far negligible (cf. to network delay), but may implement it if need arise. Similar signature-reuse is possible for the daily certification process.
This protocol is invoked by the seller if the buyer spent over the off-line limit with the seller on that day.
Note that the buyer could anticipate the need for using the extra-spending protocol, and send the payment order directly to the IAP (as part of the payment protocol). This may be more efficient, especially since the buyer is likely to be closer to the IAP than the seller (indeed often the client packets would pass thru the IAPs' machines). We plan to implement this in a future extension of MiniPay.
This protocol is used to deposit and clear the purchase orders. We describe this protocol between Seller and ISP - it is similar between ISP and IAP.
We are currently experimenting with MiniPay, in `alpha` pilots with several customers. We plan to conclude from these experiments whether to evolve MiniPay further, and where should we improve. We also plan to make a demo MiniPay system available on IBM's AlphaWorks site [IBMA], where users will be able to download MiniPay and experiment with it (this is pending legal and technical issues). If we decide to proceed to an IBM MiniPay offering, then we will be looking for `beta` pilot customers soon. For the latest status and information on MiniPay, please visit the MiniPay homepage [MPAY].
There is a strong need for a low-cost, efficient, and univerally accepted mechanism for small payments on the Web. We believe that such a standard will emerge over the next couple of years, and hope that MiniPay is a step towards this goal.
MiniPay is benefiting from contributions from many individuals, in IBM and outside it. We wish to apologize for mentioning just a few of them. Anat Sarig is a lead developer in the MiniPay team. Eldad Shai is a new developer / tester on the team who already made nice contributions. Yosi Mass helped us, in particular with integration with VRML. We also got technical help and feedback from Mark Linehan, Yiftach Ravid, Dalit Naor, and others. In revising this document, we took advantage of excellent comments from our colleague Michael Steiner from IBM Zurich Research Lab.
We will appreciate your comments, and will take them into consideration while improving MiniPay and in future versions of this document [MPAY]; please send to the authors.
Micropayment issues are discussed in the micropay mailing list [MPAYL] maintained by Phil Hallam-Baker from MIT. This has served (and still does) for MiniPay discussions and we are grateful, and wish to recommend it to anybody interested in the area.
[B97] Stefan Brands, Proposal for an Internet cash system, 1997, http://www.cwi.nl/ftp/brands/e-cash.ps.
[C92] Achieving Electronic Privacy, D. Chaum, Scientific American, August 1992, pp. 96-101
[C96] Clickshare Public Information Packet, http://www.clickshare.com/pubpack/.
[CC] CyberCoin, at CyberCash Inc. site. www.cybercash.com.
[CC1] CyberCent, at www.outreach.com
[CTS95] NetBill Security and Transaction Protocol, Benjamin Cox, J. D. Tygar and Marvin Sirbu, in Proceedings of the First USENIX Workshop on Electronic Commerce, 1995.
[D97] Money - Past, Present & Future - Sources of Information on the History of Money, Contemporary Developments, and the Prospects for Electronic Money, collection of links maintained by Roy Davies at http://www.ex.ac.uk/~RDavies/arian/money.html. See also book on the History of Money from Ancient Times to the Present Day by Glyn Davies.
[EMS] EMS credit card rates, at http://www.charm.net/~ibc/ems/index.html#ems11.
[FV] First Virtual, www.fv.com.
[GC] GC-Tech, www.gctech.com.
[GM*95] Steve Glassman, Mark Manasse, Martin Abadi, Paul Gauthier, and Patrick Sobalvarro. The Millicent Protocol for Inexpensive Electronic Commerce. In World Wide Web Journal, Fourth International World Wide Web Conference Proceedings, pages 603-618. O'Reilly, December 1995.
[GS96] The Agora Electronic Commerce Protocol, Eran Gabber and Abraham Silberschatz, presented at Second Usenix Conference on Electronic Commerce, Oakland, November 18-21, 1996.
[H95] Micro Payment Transfer Protocol (MPTP), Phillip M. Hallam-Baker, W3C Working Draft WD-mptp-951122 (22-Nov-95).
[H96] Business and Law on the Internet, Oliver Hance, Mc Grow Hill, 1996, chapter 6, esp. p. 172.
[HY97] Mini-Pay : Charging per Click on the Web, Amir Herzberg and Hilik Yochai, IBM Research.
[IBMC] IBM Cryptolope Technology - digital content distribution and delivery, at http://www.cryptolope.ibm.com/white.htm
[IBMA] IBM's AlphaWorks site, at http://www.alphaworks.ibm.com/
[M95] The Millicent Protocols for Electronic Commerce, Mark S. Manasse, in First Usenix Workshop on Electronic Commerce, New York, July 11-12, 1995.
[MPAY] The MiniPay homepage, at http://www.ibm.net.il/ibm_il/int-lab/mpay
[MPAYL] The micropay mailing list is maintained by Phil Hallam-Baker from MIT. To subscribe, send the word `subscribe` in email to "micropay-request@ai.mit.edu".
[NM93] NetCash: A design for practical electronic currency on the Internet, Gennady Medvinsky and B. Clifford Neuman. In Proceedings of 1st the ACM Conference on Computer and Communication Security November 1993.
[NM95] Requirements for Network Payment: the Netcheque Perspective, Cliff Newman and G. Medvinsky, Proc. of the IEEE Compcon'95, March 1995.
[NS] Netscape Plug-in information, at http://home.netscape.com/comprod/development_partners/plugin_api/index.html
[O96] Programming Netscape Plug-Ins, Zan Oliphant, 1996, Sams.net, ISBN 1-57521-098-3.
[PO95] Scaleable, Secure Cash Payment for WWW Resources with the PayMe Protocol Set, Michael Peirce and Donal O'Mahony, Fourth WWW Conference, Boston, December 1995.
[RS96] PayWord and MicroMint--Two Simple Micropayment Schemes by R.L. Rivest and A. Shamir, presented at RSA Security conference, 1996.
[S96] SubScrip - an efficient payment mechanism for subscription style applications on the Internet, from the Monetary Systems Engineering Group, Univ. of Newcastle, Australia. http://www.cs.newcastle.edu.au/Research/pabolins/mseg.html
[SET] Secure Electronic Transactions, MasterCard and VISA, http://www.mastercard.com/set/.
[TL96] Chrg-http: A Tool for Micropayments on the World Wide Web, Lei Tang and Steven Low, presented at Sixth Usenix Security Symposium, San Jose, July 22-25, 1996, pp. 123-129.
[HSW96] Micro-Payments based on iKP, Ralf Hauser, Michael Steiner and Michael Waidner, IBM Research, 12 February 1996, Research Report 2791 (\# 89269), presented at SECURICOM96.