MiniPay : Charging per Click on the Web

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.

1. Introduction

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.

1.1 Cost Factors for On-line Payments

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).

1.2 Minimizing Delay, Computations and Storage Costs with MiniPay

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.

1.3 Scalability and Universal Acceptance

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).

1.3.1 Public Key Certificates in MiniPay.

MiniPay uses public keys to authenticate parties (servers and wallets). This may seem to imply reliance on a centralized certification authority infrastructure, yet to be established. However MiniPay is based on peer to peer relationships, where public keys are exchanged and authenticated using the existing relationships between the peers. This allows a decentralized, open organization, following the model of the growth of the Internet itself.

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.

1.3.2 Multi-Currencies Support.

We decided to integrate multi-currency support into MiniPay early on, to allow interoperability among the early adopters and pilots. The support follows the MiniPay philosophy of building on the existing relationships. Specifically, the billing systems send to their buyers and sellers a table of supported currencies and exchange rates; we assume that each relationship has a specific reference currency. The MiniPay links will contain the price in several supported currencies. This may enable the wallet to chose whether to pay with its native currency (and let the seller perform the exchange if necessary), or to pay with the seller's currency (and pay according to the exchange rates of the buyer's IAP). We expect that at least one currency, probably the US dollar, would be common to most MiniPay links as well as available to most wallets.

1.4 Related Works

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.

Other works focus on supporting anonymity, but also attempting or claiming to achieve micro-payments. These include Anonymous credit card Protocol, PayMe and the PMTP protocol [PO95], and DigiCash [C92]. All of these require substantial on-line authorization flows, which we found to introduce noticeable delay. An exception is Brand's offline cash scheme [B97], however this system off-line potential requires tamperproof hardware. We believe an approach similar to Brand's could complement MiniPay with anonymity features if desired. We note that all anonymous payment protocols are also substantially more complex to implement and manage.

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].

1.5 Security Scope and Goals

The security goals of MiniPay are as follows:

  • Authorization: money is moved from a buyer (to a seller) only if the buyer has authorized the payment (to that seller).
  • Non-repudiation: the fact that a payment was authorized can be proved to a third party (immediately or later).
  • No framing of merchants: Deposits should be authorized by the merchants. (Non-repudiation is optional).
  • Proof of deposit: Deposits should be acknowledged, in a non-repudiable manner, by the merchant's billing server.
  • Overspending prevention:
  • Merchant is guaranteed to receive any payment authorized by the buyer's billing system.
  • Buyer's billing system will not authorize more than the buyer's limit.
  • Protection against denial of service: the buyers are able to buy as long as their balance is over the limit (i.e., sellers cannot cause funds to be kept `on hold`). All parties are protected from `clogging` - bogus messages designed to cause them excessive computations or other overhead. (Attacker can cause one verification of signature on incoming message.)
  • 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.

    2. MiniPay Overview

    Figure of MiniPay parties and financial flows 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:

  • Buyer. We often refer to the MiniPay software running on the buyers' machine as the MiniPay Wallet (or just wallet).
  • Seller (or Merchant) - online content or service provider.
  • The buyer's billing system, typically an IAP (Internet Access Provider).
  • The seller's billing system, typically an ISP (Internet Service Provider) or a bank. Note that the ISP may sometimes also be the IAP, which results in a simplified, three parties system. For simplicity, we refer to this party as the ISP.
  • An exchange connecting the buyer's billing system (the IAP) to the seller's billing system (the ISP or bank). This would typically be a bank, or a similar financial institution. MiniPay supports the connection of the IAP and ISP directly (see Figure 2) or thru one exchange (e.g. the bank in Figure 1), or even two exchanges (replace the one bank in figure 1 by two banks).
  • 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.

    2.1 Routing protocol to support many decentralized billing systems

    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.

    2.2 Risk model and legal issues

    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.

    2.2.1 Risk Management.

    There are several types of risks involved. Here are the major ones:

  • Over-spending risk (1000-seller attack): the buyer buys under the off-line limit, at a very large number (say 1000) of sellers, all on the same day, thereby exceeding the total limit on the buyers' account. In this case, each seller loses up to the offline limit (i.e. up to the amount over which the seller decides to ask for approval from the IAP). The seller can adjust the offline limit (from the IAP's recommendation) based on history for this buyer or IAP, as well as on the nature of the goods; some goods would not be of much value to an attacker or loss to the seller, while others - e.g. 1$ worth of e-cash - may require on-line verification. Note that this attack requires defeating the limit imposed (in software or smartcard) by the buyers' wallet.
  • Stolen account: in MiniPay, this risk would be entirely on the buyer, up to a maximal amount of outstanding balance or or daily spending which will be set by the buyer (to limit the risk) - and we expect this to be be low enough so that the risk would be reasonable. This results in some limitations on the overall spending (so that it is under the maximal buyer liability as set by law, e.g. 50$ per section 1693g of the EFTA [H96]).
  • Credit risk: buyer does not pay the IAP. This is a risk to the IAP, who still needs to pay the ISP (and indirectly, the Seller). The IAP may protect itself by requiring a deposit from the buyer, and by terminating MiniPay and other services (e.g. Internet access). A similar risk exist for an exchange and for the ISP. The non-repudiation (use of signatures) would facilitate automating insurance mechanisms against such risks.
  • 2.3 Economic model

    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).

    3. User Interface and Software Architecture

    3.1 User interface for spontaneous, single-item purchases

    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.

    3.2 Java vs. plug-in

    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.

    3.3 MiniPay Link format

    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= "" url= "today/sports.html" SiteName= "today/." ValidFor= "100" Merchant_prog="" text= " Buy the full page " version= "D.7"></EMBED>

    The parameters are:

  • SRC= filename: this invokes MiniPay plug-in, by referencing an empty file of MiniPay mime-type.
  • Height, width: define the size of a small `MiniPay link window`, which will be owned the Plug In and will display the link text. We note that the text is displayed inside this window - therefore the sizes must be appropriate.
  • Costs: the cost of the link in cents, or as a list of currencies and the respective price.
  • Text: the text MiniPay will write in its small window (the text the users sees as the link).
  • URL: the URL of the page bought, relative to the root of the `MiniPay protected` directory which the seller defined.
  • Merchant_id: the identifier of the seller.
  • Merchant_prog: the identifier of the CGI script for MiniPay at the seller.
  • PlugInsPage: a page with instructions on installing MiniPay - will be invoked automatically by Netscape if the MiniPay plugin is not installed.
  • Version: MiniPay version (to verify compatibility).
  • Additional optional parameters:

    3.4 Dynamic Prices and Services

    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.

    4. MiniPay Protocols

    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).

    4.1 Registration and routing (public key distibution) protocols

    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).

  • Initially: buyer receives secret code_B from IAP, and generates PUB_B, PRIV_B.
  • B sends IAP: PUB_B, S_B( Reg_req, H(code_B, salt1, PUB_B, acct_B, time)), salt1: registration of user acct_B, using a secret code code_B received previously from the IAP. The IAP should be able to find the code from the account, so encryption is avoided. The value salt1 is a randomizer, to protect code_B from guessing (dictionary) attacks.
  • IAP sends B: S_IAP ( Reg_res, OK/fail_code, acct_B, PUB_B, time, fees): response. The fees field define the fees imposed by the IAP, which the wallet would add to the cost sent from the seller.
  • 4.1.1 Properties.

    The buyer is authenticated (i.e. an attacker who does not know the code cannot get a different key registered).

    4.1.2 Routing and public key distribution protocol.

    MiniPay assumes that the keys of all billing servers are known to all billing servers and sellers (we do not want to have to query for unknown keys on-line as this would be inefficient and allow clogging attacks). This is achieved easily by a periodical public key distribution protocol run between every two peer billing servers, and billing server to seller, where new (or updated) public keys are distributed. This protocol also distributes fees information for each billing server, which helps sellers and billing servers select best routing of payment orders among alternative routes to a billing server. Therefore, we call this protocol the routing protocol. We will not describe it in details in this manuscript.

    4.2 Daily buyer protocol

    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.

  • B sends IAP: S_B( Daily_req, balance, PUB_B, acct_B, time): buyer submits his daily total spending.
  • IAP sends B: total_lim, salt, real_bal, Daily_B=S_IAP ( Daily_res, OK/fail_code, acct_B, PUB_B, time, reco_offline_lim, H(total_lim, salt, real_bal)): daily certificate. Note that the total limit and real_bal are not explicit in the signature, for privacy (the buyer does not have to reveal them to the seller). Also, note that the IAP sends back real_bal which is less than or equal to balance (it would be less if some payment orders were lost). Both total_lim and real_bal are hidden by the randomizer salt.
  • 4.2.1 Properties.

    The signature implies that the buyer (resp. IAP) agree to the balance real_bal. The daily certificate also implies the buyer is still a good customer of the IAP. The value total_lim gives a total limit on daily spending - to be imposed by the software, smartcard or proxy gateway.

    4.3 Purchase protocol

    This is the payment order message, piggybacked on the GetURL request.

  • B sends S: Daily_B, Pay_Order=S_B (Order, amount, day_total, acct_B, time, URL, acct_S): payment order (sent with daily certificate and GetURL). The wallet would issue this only if the amount is less than the currant balance kept by the wallet. day_total is the total amount spent by this buyer in this seller on this day, including this purchase.
  • Seller verifies (if necessary, using Extra-spending protocol) and responds with the requested page/service or with error information. Off-line verification includes checking certificate, signature, time and total daily spending (in that seller).
  • 4.2.1 Properties. Each payment order was generated by the buyer - no forgery or replay.

    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.

    4.4 Extra-spending protocol

    This protocol is invoked by the seller if the buyer spent over the off-line limit with the seller on that day.

  • Seller forward Pay_Order to IAP.
  • IAP responds to S with S_IAP ( Extra_res, OK/fail_code, acct_B, PUB_B, time, amount, acct_S)
  • 4.4.1 Properties.

    the seller would authorize payment only if the total purchase by this buyer in this seller on that day is less than the off-line limit, or if the IAP has approved an additional amount to that specific seller. The buyer is guaranteed that amount of money that the IAP puts `on hold` is bounded by the amount of money paid by this buyer on that day (prevent denial of service).

    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.

    4.5 Deposit and clearing protocol

    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.

  • Deposit: Seller sends: S_S( {Pay_Order_1, Pay_Order_2, ...}, time)
  • ISP responds with its signature over the message received, to acknowledge it was received and verified to be valid. It would later forward the payment orders to the corresponding IAPs.
  • Clearing: seller sends: S_S(Clear_req, time, time_of_last) where time_of_last is the time of the latest clearing response (reply) received
  • ISP responds with: S_ISP(clearing_res, time, amount, {(rejected1, reason1), ...}, {pending1,...}) where amount is the amount cleared, and containing a list of rejected messages and a reason why those message here not approved and list of messages that has not been approved yet. The reasons to reject a payment order are either that it was not valid (e.g. not signed properly by the buyer), or that the buyer defaulted (the `thousand sellers` attack) - in which case the amount is only what was not approved by the IAP in the extra-spending response (Extra_res) message.
  • 4.5.1 Properties.

    The seller will get paid only for authorized purchases. For every purchase order deposited, the seller either gets paid, or gets a reject message with a reason.

    5. Status and Conclusions

    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,

    [C92] Achieving Electronic Privacy, D. Chaum, Scientific American, August 1992, pp. 96-101

    [C96] Clickshare Public Information Packet,

    [CC] CyberCoin, at CyberCash Inc. site.

    [CC1] CyberCent, at

    [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 See also book on the History of Money from Ancient Times to the Present Day by Glyn Davies.

    [EMS] EMS credit card rates, at

    [FV] First Virtual,

    [GC] GC-Tech,

    [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

    [IBMA] IBM's AlphaWorks site, at

    [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

    [MPAYL] The micropay mailing list is maintained by Phil Hallam-Baker from MIT. To subscribe, send the word `subscribe` in email to "".

    [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

    [O96] Programming Netscape Plug-Ins, Zan Oliphant, 1996,, 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.

    [SET] Secure Electronic Transactions, MasterCard and VISA,

    [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.

    Return to Top of Page
    Return to Technical Papers Index