Electronic Payment Systems on Open Computer Networks: A Survey

Electronic Payment Systems on Open Computer Networks: A Survey Working paper Thomi Pilioura Abstract The extraordinary growth of international interconnected computer networks and the pervasive trend of using these networks as a new field for conducting business processes is stimulating the demand for new payment methods. These new methods must attain high levels of security, speed, privacy, decentralisation and internationalisation for electronic commerce to be accepted by both consumers and businesses. This paper surveys the state of the art in payment technologies and sketches emerging developments. 1 Introduction New electronic technologies are combining with an emerging global information economy on the Internet to change the way we do business. In the centre of these developments are electronic payment mechanisms that provide the financial infrastructure needed to open the electronic marketplace. This paper gives an overview of these new payment mechanisms by describing and evaluating some of those that currently exist or are being developed. These reviews and evaluations are necessarily somewhat tentative, because the various systems are at different stages of development and the various companies operate at different levels of public disclosure. This paper is organised in the following way. In the second section, we propose a classification schema for the different electronic payment systems. For each category we choose a few representative systems to be examined in this paper. In the third section, we propose an evaluation approach. This evaluation approach uses some of the most important parameters associated with a financial transaction including security, privacy and transaction cost. In the fourth section, we use these evaluation parameters in order to give a structured overview of the different systems. The fifth section summarises the evaluation results. We conclude this paper with some general remarks on the future of electronic payment systems. 2 A Classification Schema for electronic payment systems At this moment in time, there are many different companies trying to position their products as the dominant way to transfer money across the Internet [1] [2] [3]. In this survey we classify the electronic payment systems according to the following schema (illustrated also graphically in Figure 1): 197

198 Electronic Payment Systems: A Survey Electronic payment systems Token-based systems Notational systems Electronic payment orders (credit/debit) transferred over the nets Open Computer Networks Electronic cash Credit card billing over the nets Encrypted credit cards Third-party authorization numbers Smart Card Technology Electronic purse systems Smart-card based notational systems Figure 1 The Classification Schema Token-based systems: these systems use tokens, objects that are generally agreed to carry value themselves. The value carried by the tokens is conventional, a matter of consensus. These systems are based on prepayment, i.e. drawing on one s bank account in advance to get possession of payment instruments, token money, to be used in later transactions. We have two subcategories of token-based systems: Electronic cash: it attempts to replace paper cash as the principal payment vehicle in online payments. Electronic purse systems: they are based on smart cards, also called stored value cards, which use integrated circuit chips to store electronic money. Notational systems: in these systems the transaction is directly or indirectly tied to value stored elsewhere. The three subcategories that we can distinguish here are: Electronic payment orders (debit/credit) transferred over the nets: the transaction is directly tied to value stored elsewhere (usually in a bank account). These systems are also called pay now systems because they transfer deposit money immediately after the initiation of a payment order. Examples of these systems are debit cards, checks and credit transfers). Credit card billing over the nets: the transaction is indirectly tied to value in that when you use it you undertake to become liable for the amount of the transaction. These systems are also called pay later systems and they are based on consumer credit and/or delayed debiting of the payer s current account. They can be implemented in two ways: encrypted credit cards or third-party authorisation numbers.

T. Pilioura 199 Encrypted credit cards: in these systems, credit card details are encrypted before they are sent out over open computer networks. Third-party authorisation numbers: one solution to security and verification problems during financial transactions is the introduction of a third party to collect and approve payments from one client to another. Smart card-based notational systems: these systems use smart card technology to store customer-specific information in an attempt to offer higher levels of protection than software-only notational systems. We have to note here that some systems may involve both stored value and a deposit balance transfer capability, thus integrating the two categories of payment systems. Finally, we have to stress out that this classification schema brings together two different dimensions of electronic payment systems, namely process and technology. Two lines of technology, smart cards and open computer networks, are being used to develop payment systems where the process of payment is based either on token or notational schemes. Table 1 contains the systems we selected for each category to be used in our survey. Classification System Provider DigiCash DigiCash, Inc. Electronic cash Digital Millicent Equipment Token systems Corporation CAFE ESPRIT Electronic purse systems Program MONDEX NatWest, U.K. Carnegie NetBill Mellon University, Pittsburgh Electronic payment orders transferred over the nets Notational systems Credit card billing over the nets Encrypted credit cards Third-party authorisation numbers Smart-card based notational systems NetCheque CyberCash SET FirstVirtual FSTC e-check Table 1 Systems examined in this survey Information Sciences Institute of the University of Southern California CyberCash Inc., Reston, VA, USA VISA, MasterCard First Virtual Holdings, Inc. FSTC Inc.

200 Electronic Payment Systems: A Survey 3 The Evaluation Approach The evaluation of electronic payment systems is quite difficult, because we experience short of clear and well-defined criteria for the appreciation of the functionality and the quality of such systems. In the following paragraphs we present the parameters used in this paper for the evaluation of the systems. Some of these parameters are common to both token-based and notational systems and some others are applicable only to one of these categories. In the last case, we specify the category to which the parameter is applicable. Transaction cost: Conducting a transaction should not be expensive. One should note that the economy of a transaction is a relative property. For example, if a transaction worth [units]1000 cost the parties concerned [unit]1 to administer, that might be economic; however, if a transaction of [units]5 still cost [unit]1 to administer, then that would not be economic. This parameter also specifies the ability of a system to be used for micropayments. Micropayments refer to low-value electronic financial transactions, ranging from a fraction of a cent to a few dollars. Security: Since Internet services are provided today on networks that are relatively open, the infrastructure supporting electronic commerce must be resistant to attacks in an environment where eavesdropping and modification of messages is easy. This means that payment systems require adherence to some fundamental security principles that cryptography greatly enhances. These principles are authentication, payment integrity, double-spending prevention, loss-tolerance and nonrepudiation. Authentication is needed to help make sure that persons in a transaction are who they claim to be. Message Integrity is needed to ensure that information has not been altered since the data was signed. Double-spending prevention is needed to prevent copied coins being spent repeatedly. This parameter is applicable only to token-based systems. Loss-tolerance: if the network fails or the computer crashes during a payment transaction, coins might be lost. In order to solve this problem, a mechanism must be available to recover the value of these lost coins. It s applicable only to token-based systems. Nonrepudiation is needed to prevent a signatory of a document from denying the submission, delivery, or integrity of its contents. This parameter is applicable only to notational systems. Privacy: It is needed to make sure that information is not revealed to unauthorised people. Cryptography can be used to enhance privacy during digital communications. With this technology, information can be enciphered so that unauthorised personnel cannot understand it. Only with the appropriate key can the information be easily deciphered and understood.

T. Pilioura 201 In the privacy aspect of electronic payment systems we can distinguish three principles: Payment confidentiality: payment details including payer, payee, account numbers, amounts, date and time must not become known to electronic observers able to monitor network traffic. Payment anonymity: only a payer s pseudonym is known to the payee. Payer untraceability: payment system cannot trace payments back to the payer. Online verification: Electronic payment systems that need the help of a distant computer throughout the transaction are said to be online systems. On the other hand, offline payments involve no contact with a third party during payment - the transaction involves only the payer and payee. Online systems obviously require more communication, but they are also considered more secure than offline systems as they prevent problems of double spending and dishonest transactions. In the offline payment systems, these problems could be solved by secure hardware components such as smart cards. One problem is that there is no true offline cash that can be traded ad infinitum without a third party acting as a referee. Paper money or gold coins can be traded for years without being deposited in a bank, but this is because they cannot be counterfeited. Digital notes are easy to copy. The cryptographic algorithms can catch counterfeiters, but only when the money is processed through a bank. This means that even offline cash is still, in a sense, online. It just means that the interaction with the third party, the bank, can take place at a more leisurely pace. So the distinction between online and offline is unclear. It s really a distinction between now and later. Software-only vs. tamperproof hardware: Some systems are based on special purpose software only and others are using a combination of software and hardware. Divisibility: it must be possible to interchange multiple low denominations and single high denominations. It only makes sense to ask whether a system supports divisibility if it is a token-based system. Change-return capability: in some systems the merchant can give change to the buyer. This parameter is applicable only to token-based systems. Transferability: the recipient of a token can spend that token without having to contact the issuer. This improves anonymity and reduces the amount of network traffic, but complicates the security issues. It only makes sense to ask whether a system supports transferability if it is a token-based system. Purse-to-purse transfer: some systems support purse-to-purse transactions to better imitate the functions of conventional money. This parameter is valid only to token-based systems. Status: Some systems are in testing phase and some in commercial use. In the following section, we give an overview of the functionality and the most important features of each of the systems examined in this paper. This overview helps us

202 Electronic Payment Systems: A Survey evaluate each system according to the parameters presented in the above paragraphs. A summary of this evaluation is presented in section 5. 4 Description of the systems 4.1 DigiCash Based in the Netherlands and the U.S.A., the technology provider DigiCash [4] co-operates with the American Mark Twain Bank in a pilot of ecash, a system based on a software wallet and electronic coins that can be loaded onto one s PC hard disk. 4.1.1 The ecash model The actors within the system are clients, merchants and ecash banks, as shown in Figure 2. Clients and merchants have accounts at an ecash bank. The ecash wallet software is called cyberwallet. It stores and manages a client s coins, keeps records of all transactions and makes the protocol appear as transparent as possible to the client. Withdraw/ Deposit coins New coins, statement Ecash Bank Validate /deposit coins Signs coins User accounts Database Valid indication Client Wallet Stores coins Makes payments Accepts payments Pay coins Goods, Receipt Merchant Software Sells items Makes payments Accepts payments Figure 2 Entities and their functions within the ecash system The flow of interactions in the DigiCash model consists of four parts: Withdrawing Money 1. The customer's cyberwallet software generates random serial numbers for the ecash coins. The serial numbers are then blinded. The blinded coins are sent to the ecash bank. 2. The bank checks the signature and debits the signature owner's account. 3. The bank validates the coins and returns them to the customer. 4. The customer unblinds the coins. Note here that many coins of different denominations, specified by the customer, can be obtained in a single withdrawal request. Spending Money 1. The customer sends a buying request to the merchant.

T. Pilioura 203 2. The merchant sends a request back to the cyberwallet software to send the money. 3. The customer confirms the transaction and the software transfers the exact number of coins. Redeeming Money 1. The merchant has to check the validity of the coins. He sends them to the bank that issued the coins to ensure that they have not already been spent. 2. The bank checks the serial number for double spending. If the coins are valid, the bank destroys the coins, adds the number to the database of spent coins and transfers the amount to the merchant s account. Finishing the Transaction After the coins have been validated, the merchants send the purchased goods or/and a receipt to the customer and the financial transaction is finished. A merchant can also make payments to a client using the same procedure. This is useful for making refunds or providing payout services, where a client might receive back a payment as part of the service. 4.1.2 Ecash coins The electronic coins used within the ecash system are unique in that they are minted by the client before being signed by the bank. Each coin has a serial number that is generated by the client s cyberwallet software. The serial numbers are chosen randomly and are large enough so there is very little chance that anyone else will ever generate the same serial numbers. The serial number is blinded and sent to the bank to be signed. This is done using the blind signature protocol. The bank is unable to see the serial number on the coin it is signing. The method can be considered similar to putting the coin and a piece of carbon paper into an envelope. The envelope is sent to the bank where it is signed and returned to the client. The client opens the envelope and takes out the coin (unblinds it). The coin has now been signed. The carbon paper ensured that the bank s signature went through the envelope. The signature on the unblinded coin appears the same as any other normal digital signature. There is no way to tell from it that the coin was signed using the blind signature protocol. However, there is a problem with this method. Since the bank cannot see what it is signing, how can a value be assigned to the coin? The value cannot be included with the serial number in the fields of the coin because the bank cannot see this. The client might assign a very high value and tell the bank that it is only a low-valued coin. The problem can be solved by the bank using a different signature key for each coin denomination. The client informs the bank of the value he wants the blinded coin to be worth. Then the bank signs the coin with the signature key representing this denomination and deducts that amount from the client s account.

204 Electronic Payment Systems: A Survey 4.1.3 DigiCash features Transaction cost The low costs of transaction allow using ecash for micropayments. Authentication Everyone gets RSA public-key pairs for creating digital signatures for his transactions. Double-spending prevention DigiCash supports double-spending prevention. To ensure that a serial number is not spent twice, the minting bank must record every coin that is deposited back to that bank. A very large database of all spent serial numbers soon develops. When a valid coin is accepted, it then becomes spent and its serial number is entered into the database. By using expiry days with coins, the serial numbers can be removed after the expiry date. In this way we reduce the serial numbers that must be kept in the database. The wallet software can automatically ensure that coins are returned to the bank before they expire. Loss-tolerance If the network fails or the computer crashes during a payment transaction, coins might be lost. There is, however, a mechanism to recover the value of these lost coins. Payment confidentiality and message integrity All communication in the DigiCash system is digitally signed and encrypted through extensive use of both symmetric and asymmetric cryptography. Payer anonymity The current DigiCash system includes blinded digital signatures for protecting the anonymity of the buyers. Like the CAFE system, coins can be signed to detect the buyer who double spends. This partial anonymity is cited as a deterrent to the criminal use of the system. Payer untraceability In the DigiCash system the sender is able to prove he sent money, however the recipient (or someone later interrogating the system) cannot see who sent the money. Divisibility The client informs the bank of the value he wants the blinded coin to be worth. The bank then signs the coin with the signature key representing this denomination. For example, the bank can have a one-cent signature, a five-cent signature, a ten-cent signature and so on. Change-return capability The system has no change-return capability. As consequence, the customer must always provide the exact number of coins required for the purchase. This is done because accepting change could compromise the user s anonymity (the merchant could record the serial numbers of the change and collude with the bank to reveal the user s identity). The cyberwallet will automatically assemble the correct amount and can withdraw new coins from the bank if more denominations are required. Purse-to-purse transfer Purse-to-purse transfer of ecash is possible, although the amount transferred still has to be forwarded to the bank for verification. The coins are forwarded through the payee to the bank where they are deposited. New coins worth the same amount are then returned to the payee.

T. Pilioura 205 This is all done transparently by the software so that it appears that the new coins were received directly from the payer. Currently, as with merchant payments, both users must have accounts at the same ecash bank in order to perform a purse-to-purse transfer. Status There is already an existing software system for the use of ecash and several banks issuing ecash in their national currencies, such as the Mark Twain Bank (USA), Eunet (Finland), Deutsche Bank (Germany) and St. George Bank (Australia). 4.2 Millicent Millicent [5][6] is aimed at the micropayment portion of Internet commerce, where transactions could involve fractions of a cent and are made very quickly. Given these constraints, micropayment techniques must be both inexpensive and fast. Achieving both requires certain compromises, such as relatively lightweight security. 4.2.1 Scrips The Millicent system uses scrips, a form of tokens that are only valid with a particular vendor for a limited period of time, and brokers, who act as intermediaries between vendors and customers. In order to avoid customers having to maintain separate accounts with individual vendors, with whom they may only have a very short relationship, brokers act as intermediaries. The long-term relationships are between the brokers and the customers, and the brokers and the vendors, rather than directly between the customer and the vendor. A scrip can be considered as an account between the customer and the merchant which is set up, used and closed. The scrip contains a value and when a customer makes a purchase with it, the amount of the sale is deducted from the scrip s value and the scrip is sent back to the customer as change. A scrip cannot be spent more than once, can only be spent by its initial owner and at a specific merchant, has an expiration time (the date on which the scrip becomes invalid, used to limit the scrips IDs that must be remembered by a vendor to prevent double spending) and can be regenerated upon expiration. 4.2.2 The Millicent model The basic sequence of interactions in the Millicent model is as follows (Figure 3): 1. The customer buys a quantity of broker scrips using one of the macropayment schemes. 2. When a customer first encounters a new vendor, he must buy vendor scrip from the broker to spend at the vendor s site. Therefore, he places a request for vendor scrip to the broker. 3. The broker obtains the required vendor scrip from the vendor. 4. The broker sells the vendor scrip to the customer. For example, the customer can buy 20 cents of vendor scrip using the $5 of broker scrip purchased earlier (step 1). Both the new vendor scrip and the change in broker scrip are returned to the customer. 5. The vendor scrip is sent to the merchant with a purchase request.

206 Electronic Payment Systems: A Survey 6. The vendor gives change in vendor scrip along with the purchased content. Steps 1 and 3 need not happen at every transaction the customer would purchase sufficient scrip from his broker to meet his needs for a period of time; similarly the broker would have enough vendor scrip to service a number of customer requests, or would have a licence from the vendor to mint the specific vendor scrip directly. Although there would seem to be a lot of traffic in this protocol, there is no bottleneck connection to a single currency issuer for each transaction; especially once steps 1 and 3 are factored out. Customers buy vendor scrip from Broker Broker Brokers buy/produce large chunks of vendor scrip for licensed vendor Customer Customers buy information with vendor scrip Vendor Already spent scrip refused Figure 3 The Millicent model 4.2.3 Millicent features Security and privacy Millicent protocols offers various levels of security and privacy (Table 2). Namely, scrip in the clear offers no security and no privacy. Here the scrip is transferred back and forth between customer and vendor without any encryption or protection. This would allow someone eavesdropping the connection to take a copy of the scrip returned as change and spend it himself. The private and secure protocol uses a shared secret key between the two parties to establish a secure communication channel (encrypt both the scrip and the purchase request). And the secure without encryption protocol does the same without the privacy aspect in order to achieve better performance. Double-spending prevention In all the Millicent protocols double spending will be detected locally by the vendor at the time of purchase. Payer anonymity Although the Millicent protocol does include a field in the scrip to carry customer information, this field is not always used. The Millicent group suggests that a good use of this field would be to carry age and residence information for taxation purposes and any information needed for discounts, such as student status. However, some limited anonymity could be maintained by buying broker scrip using an anonymous macropayment system. Payer untraceability A scrip has visible serial numbers that could be recorded and traced.

T. Pilioura 207 Online verification The Millicent system is offline to the extent that no connection to a central server is required. The fact that any particular type of scrip is only valid at a particular vendor means that the vendor does not need to connect to a separate issuer to validate the token, thereby reducing network traffic and eliminating attendant cost of such a validation. Divisibility Scrip can represent any denomination of currency. Expected values range from one-tenth of a cent up to about $5, although there is no defined upper or lower bound limits. 4.3 CAFE Millicent Protocol Efficiency Secure Private Ranking Scrip in the clear 1 No No Private and secure 3 Yes Yes Secure without Encryption 2 Yes No Table 2 Characteristics of the three Millicent protocols CAFE [7] is a cash scheme with guarantees of anonymity for the users. It involves an electronic wallet to be used as a pan-european mechanism for consumer payments, access to information services and if required identification. There are two kinds of tamper resistant secure electronic devices used in the CAFE system: smart cards and wallets. These devices are used to store electronic money, perform cryptographic operations and to make payments to merchants. Smart card: this is the simplest of the devices used in the protocol. It is similar to a credit card and has an embedded microprocessor powered by an external source. All information is stored on the chip, which also performs the cryptographic computations. Wallet: a wallet consists of two parts that work in conjunction with each other. One part is known as an observer and protects the bank s interests and the other is known as the purse and protects the user s interests. CAFE also supports contactless transactions via infrared wallets. 4.3.1 The CAFE model Withdrawal: a payer usually only needs to communicate with the bank through a withdrawal session, which results in a number of blank electronic payment slips being loaded into his smart card. The bank keeps track of the balance in the card by means of a counter in the observer part of the smart card. The balance is updated during a withdrawal request and the corresponding amount is deducted from the user s bank account. A withdrawal session consists of the following steps: 1. The user s smart card sends the identity of his bank and information about his bank s public key certificate to the terminal. This allows the terminal to connect to the correct bank and verify/update the bank s public key certificate stored in the smart card.

208 Electronic Payment Systems: A Survey 2. The card and the bank then mutually authenticate each other through the terminal. 3. The user generates a payment slip and forwards the hash of it to the bank. The bank creates a digital signature on the forwarded hash and sends the result to the user s card. The user needs to only store the bank s signature on the card as all the other values that a payment slip must consist of (such as one-time public keys) can be regenerated by the user s card at the step 2 of the payment stage. Payment: the payment transaction consists of the user filling in an amount in a blank payment slip together with the name of the payee, signed with the user s secret key. The steps involved in a payment transaction are as follows (Figure 4): 1. A customer inserts his card into a merchant s payment terminal. The terminal tells the card the identity of the payee, the date and the amount to be deducted from the counter in the observer part of the smart card. 2. The card regenerates the next payment slip to be used. This consists of generating the cryptographic keys. 3. The card sends the blank payment slip to the merchant, consisting of the bank s signature and the public keys needed to use the slip. The payment slip is marked as being spent by the card even though the payment has not been completed yet. 4. The terminal verifies the signature of the bank on the payment slip. 5. The information given by the terminal in the first step is encoded by the card into the payment slip (M). 6. When the payment has been finalised, the terminal sends an acknowledgement to the card, which then updates its counters. Customer [1] Insert card [2] Regenerate Payslip [3] Send Blank Payslip [5] Signed Payslip (M) [6] Verify & ACK [4] Verify Bank s Signature Merchant Figure 4 The CAFE flow of interactions for the payment phase Deposit: on accepting a payment slip, the payee forwards it to the acquirer (at a later date) who in turn clears it through the existing financial clearing system. The acquirer: 1. Verifies the contents of the payment slip and validates the bank s signature. 2. Verifies that the payment slip has not been deposited previously. 3. Looks in its database to verify that the corresponding part of the payment slip has not been spent previously. If the first two conditions are fulfilled, the payee is entitled to be credited for the amount of the payment. A payee is responsible for checking all received payment slips against his local

T. Pilioura 209 copies of the blacklist (database containing the IDs of the spent payment slips) during the payment phase. If a blacklisted slip is detected, the payee aborts the transaction. If a payee fails to check received payment slips against the blacklist, then he will have to accept responsibility for them as the clearing centre will reject them. When the clearing centre detects double spending, the payment slip will immediately be added to the blacklist. 4.3.2 CAFE features Authentication CAFE wallets can be configured to be used with a PIN. In this case the buyer is assumed to always be the legitimate user of the device. During the withdrawal phase, the card and the bank mutually authenticate each other through the terminal. Similar authentication procedures take place between the payer and the payee as well as between the payee and the bank during the payment and the deposit phases respectively. Message integrity The observer part of the smart card ensures the correctness of all transactions performed by the user. A user will not be able to successfully complete a payment transaction without the co-operation of the observer. Double-spending prevention Protection against double spending is only guaranteed as long as the tamper resistance is not compromised. As far as this is true CAFE offers two levels of double spending detection. First, a payee is responsible for checking all received payment slips for double spending. If he fails to do it, then CAFE has a cryptographic fallback mechanism that allows the financial institutions to detect double spending of electronic currency (after it has been spent) and blacklist the corresponding payment slips. The banks distribute these lists to all the merchants in the system. This detection is achieved at a cost of maintaining a database of recently spent payment slips by the financial institutions. Loss-tolerance If a user loses his wallet, the bank can recover the money from a backup and the deposit transcripts. This is done by regular backups during a withdrawal transaction. If a user wants to recover lost money, he reveals the identity of the payment slips stored after the last withdrawal. This enables the bank to track these payment slips. Payment confidentiality The purse will blind/neutralise any communications that may disclose secret information about the user to the outside world. Furthermore, all communications between the wallet and the outside world are done exclusively through the purse, guaranteeing that the observer cannot divulge any secret information to the bank without the user s knowledge. Payer anonymity The wallet endorses each payment by giving it a cryptographic signature. As a fall-back mechanism, the money that the wallet uses is in an encrypted format where the identity of the payer is encoded into the coin s number. This is done in such a way that the payer s identity can only be recovered if the coin is double spent.

210 Electronic Payment Systems: A Survey Payer untraceability Under normal circumstances, payments cannot be linked to a user even if there is collaboration between the merchants and the banks. Online verification The system is capable of performing offline transactions, thus eliminating the need to connect to central servers. Note that the transactions are only offline during purchasing, withdrawals of electronic money into the wallet are, of necessity, online transactions. Also it may be decided that payments over a certain threshold must be confirmed online. Divisibility The signed payslip (step 5 in Figure 4) can represent any denomination of currency according to the information that the merchant s terminal passes to the card (step 1 in the same figure). Change-return capability The merchant s terminal tells the card the amount that it has to pay and then this information is encoded by the card into a payment slip (step 4 in Figure 4). So the payer pays the exact amount required for the purchase, which means that change return capability does not hold for this system. Multiple currencies The CAFE wallets have several pockets for different currencies. Like cash, the users may either exchange currency at the bank (lowering the amount in one pocket and increasing in another) or pay in nonlocal currency if the merchant accepts it. Transferability The device receives its coins by withdrawing them from a bank account via an Automated Teller Machine (ATM). It is thus prepaid and the coins in the machine do not exist as currency anywhere else. When the user spends money the device transmits one or more coins to the seller s device and marks them as spent within the device. The seller now has the value of these coins. However, they must be deposited with an issuer for that value to be realised. Thus, the primary flow in the CAFE system is that of withdraw-pay-deposit and the individual coins do not remain in circulation in the same way that real cash tokens do. Thus, transferability does not hold for this system. Status The CAFE project was completed on February 1996. The first prototypes of the electronic wallets are available and in a trial stage. 4.4 Mondex The concept of the Mondex [8] card was developed at NatWest, a major U.K. banking organisation, in 1990. The technology was developed with a number of manufacturers involved in the production of secure hardware, including Hitachi Corporation. In July 1996, a separate company, Mondex International was formed to promote the technology through a series of trials in many different locations around the world.

T. Pilioura 211 4.4.1 The Mondex model The card is initially loaded by contacting a bank using either a Mondex Automated Teller Machine (ATM) or using a specially adapted telephone. These access devices do not need to know how the chip-to-chip protocol works, but rather they incorporate an Interface Device (IFD) that contains a control processor that mediates in the dialogue between the card and the bank. At the bank, a form of money safe called a Mondex Value Box is installed. This is a hardware device that can hold large numbers of Mondex cards and acts as a store of value for dialogues with the issued card population. Transfers to and from the Value Box are monitored by a software system referred to as the Value Control and Management System, and the movements will then be reflected in the bank accounts of the cardholders. Figure 5 shows this process taking place. A Mondex card is inserted into an ATM (or adapted telephone) whereupon chip-to-chip dialogues take place between the IFD and the card under the control of the ATM device. The Mondex IFD then establishes a dialogue with the bank. Once the cardholder s account number has been established, and the card identity verified, value is transferred from the cards in the bank s Value Box by chip-to-chip protocol to the destination chip residing in the card. The Value Control and Management System will inform the bank s accounting systems to debit the cardholder s bank account for the amount. Bank s Accounting Systems Value Control & Management System Value Box ATM Mondex IFD Figure 5 Loading a Mondex card with value Spending is a similar process, where retailers are equipped with a device called a Value Transfer Terminal. Once again, this contains an IFD device that facilitates the transfer from the customer card to the retailer card. There is no need for an online dialogue with the bank to verify the transfer. At a later stage, the retailer may contact the bank, transfer the value to the bank s Value Box, and simultaneously have the amount credited to his account. The Mondex Internet transaction runs as follows: 1. On completion of his selection of products and confirmation of this to the vendor, the client will be asked to insert his Mondex card into a card reader attached to his computer. 2. On confirmation that another valid device exists at the other end of the link, value is transferred from the client s card to the vendor s card. 3. The customer receives the information (graphic, text, sound clip or video) that he ordered. Physical goods can also be ordered and paid in the same way.

212 Electronic Payment Systems: A Survey 4.4.3 Mondex features Authentication The security scheme relies on a digital signature, which is generated by the chip on the card. This digital signature can only be recognised by other Mondex enabled participants in a transaction. Message integrity Because Mondex employs state of the art hardware technology, which would need to be duplicated in any attempt for forgery, it is assumed that such fraud would be uneconomical. Further, Mondex plans to issue regular and sporadic upgrades to the chip, so that any successful forgery would rapidly be rendered obsolete. In addition, Mondex plans to use transaction sampling to maintain a picture of the flow of value, and use this to identify fraudulent and illegal use of Mondex value at an early stage. Clearly, for this to be possible, the Mondex system cannot be anonymous. Furthermore, Mondex chips have been designed to withstand normal extremes of cold and heat, damp, X-rays or electric interference. Double-spending prevention In each Mondex transaction messages passed between cards include data that are wholly unique for all time and cannot be repeated. This feature prevents a potential fraudster from using any given message to repeat a transaction and send a single $5 to two different people. Loss-tolerance If the card is lost, the value stored in it cannot be recovered. However, Mondex allows cardholders to lock value in their cards, preventing other people from spending the money on the card. This facility enables banks to operate a return and reward system to support the return of cards to their rightful owners (where capable of being identified), something which never can happen with the lost ten pound or hundred francs. Payer anonymity and untraceability The card maintains a purse narrative that remembers the last 10 transactions in which the card took part and the retailer s hardware keeps record of the last 300 transactions. This limits the anonymity and augments the traceability of the system. Software and hardware The system uses special purpose hardware on smart cards to ensure its cryptographic security. This is the case even in the proposed Internet transactions. In those cases there is simply a Mondex compatible card reader interface attached to the computer. When a transaction is required, the computer talks to the card through this interface. Multiple currencies Mondex is a multicurrency purse capable of handling different currencies simultaneously (up to five). Transferability Mondex is the only system that enables offline transferability: the payee can use the amount received to make a new payment himself, without having to go to the bank in between.

T. Pilioura 213 Purse-to-purse transfer Mondex enables purse-to-purse payments. Using a Mondex Wallet, two cardholders can transfer cash between their cards. With a Mondex Telephone, purse-to-purse payments can be made across the world. Status The Mondex project is at a much more developed stage than CAFE including manufacturers making and selling the necessary equipment to engage in Mondex transactions, and a number of successful pilot schemes. 4.5 NetBill NetBill [9][10] implements a check-like debit payment model. It is a payment system which uses a mixture of symmetric key and key pair cryptography. It is aimed at payment for information-based goods such as library services and journal papers. The NetBill system itself charges for transactions, and requires the user to have a pre-funded NetBill account from which all payments will be made. 4.5.1 The NetBill model The participants in the system consist of customers, merchants and a NetBill server that maintains accounts for both customers and merchants. These accounts can be linked to conventional accounts in financial institutions. When a customer purchases goods his NetBill account is debited by the value of the goods and the merchant s account is credited by the same amount. A customer s NetBill account can be replenished by transferring funds from his bank. Similarly, funds in a merchant s NetBill account are deposited into the merchant s bank account. NetBill guarantees that a customer pays for only the goods that he successfully receives. NetBill provides transaction support through libraries integrated with different clientserver pairs. The client library is called the checkbook and the server library is called the till. The checkbook and till libraries in turn communicate with the client and merchant applications, respectively. The basic protocol is outlined as follows (Figure 6): 1. The consumer and merchant authenticate each other and establish a symmetric session key to protect the privacy of subsequent messages. 2. The consumer requests a price offer for the desired item. At this stage a bid for the item can also be included as well as personal information (such as student ID and frequent buyer ID) in order to qualify for special prices. 3. The merchant replies with a price quote. 4. If the customer accepts the price quoted, he instructs the checkbook to send a purchase request to the merchant s till. Alternatively, the customer may configure his checkbook to send a purchase request automatically if the price is below a specified amount.

214 Electronic Payment Systems: A Survey Web Browser Checkbook [1] Authentication phase [2] Request for quotation [3] Quotation [4] Purchase request [5] Encrypted goods [6] Signed EPO [9] Key to unwrap goods Web Server Till Account funding [7] Endorsed EPO NetBill Server [8] Purchase Authorization Consumer s bank Batch payment Merchant s bank Settlement system Figure 6 The NetBill transaction protocol 5. The till, on receiving the purchase request, fetches the goods from the merchant s application. It encrypts them with a one-time key and computes a cryptographic checksum on the result. The till then forwards the result to the customer s checkbook but the decryption key will only be sent after completion of the payment. 6. The checkbook, on receiving the encrypted message, verifies the checksum by applying the secure hash algorithm (SHA) to the goods and checking that it matches that computed by the merchant. This gives the checkbook confidence that it has received the requested goods intact. Note at this point that the customer cannot decrypt the goods; neither has the customer been charged for them. The checkbook returns a signed (with the customer s private key) electronic payment order (EPO) to the merchant s till. The EPO consists of two sections, the first of which contains details about the transaction and is readable by both the merchant and the NetBill server. The second part contains payment instructions (such as the customer account number) and can only be read by the NetBill server. At any time before the signed EPO is submitted, a customer may abort the transaction without danger of the transaction being completed without his will. The submission of a signed EPO marks the «point of no return» for the customer. 7. Upon receiving the EPO, the till verifies all its contents, appends the key for decrypting the goods, endorses the EPO with a digital signature and forwards the endorsed EPO to the NetBill server. The endorsement process involves concatenating the merchant s account number, a memo field and the key used to encrypt the goods and then signing the result with the merchant s private key.

T. Pilioura 215 8. The NetBill server verifies that the price, checksums, and so forth are in order and debits the customer s account for the appropriate amount. It logs the transaction and saves a copy of the one-time key. It returns to the merchant a digitally signed message containing an approval or failure message. The NetBill server includes some account status information with the receipt. If there is not enough money in the consumer s account, the transaction will be rejected and the key never delivered, preventing the consumer from using information that has not paid for. 9. The merchant s application unwraps the receipt, keeps a copy and re-encrypts it using the session key he shares with the customer (established during the authentication phase). Then the merchant forwards the receipt to the customer s checkbook. In the unlikely event that the merchant or client machine goes down after the consumer has been charged but before the key is delivered, the consumer can request a copy of the receipt which contains the key from the NetBill server. 4.5.1 NetBill features Transaction cost The transaction cost can be considered as medium due to the requirement for extensive network traffic during the transaction. Authentication and payment confidentiality In the course of a NetBill transaction, the parties involved identify themselves. The scheme used in NetBill is a modified version of the Kerberos scheme called Public Key Kerberos. In NetBill, before a transaction occurs, the customer contacts directly the merchant (and not a special-purpose server as in Kerberos scheme) and establishes a ticket for the communication between the customer and the merchant as well as an encryption key that will be used to secure the subsequent dialogs with the merchant. Similarly, the merchant server will establish a ticket and an encryption key for the communication between the merchant and the NetBill server and the customer will maintain a ticket and an encryption key for the communication (via the merchant) with the NetBill server. The period of validity of the ticket is configurable, but would potentially span many transactions. Message integrity All network communication between the customer and the merchant is encrypted to protect against adversaries. Nonrepudiation There are many variations within NetBill some of them allow disputes of all kinds to be settled. Anonymity The system also allows for easy use of pseudonyms for anonymity but in any case, the NetBill server knows both parties identity and transaction amounts. Status The system is currently in its Alpha Trial at Carnegie Mellon campus and uses fake money.

216 Electronic Payment Systems: A Survey 4.6 NetCheque NetCheque [11] and NetCash are developed at the Information Sciences Institute at the University of Southern California. NetCheque is a distributed accounting service supporting the credit-debit model and consisting of a hierarchy of NetCheque servers (banks) that are used to clear checks and settle interbank accounts. This hierarchy allows for scalability of the system. It also allows users to select the bank of their choice based upon criteria such as trust, proximity, reliability and so forth. As a distributed accounting service, properly signed and endorsed cheques are exchanged between banks to settle accounts through a hierarchy, as shown in Figure 7. In addition to improving scalability and acceptability, clearing between servers allows organisations to set up accounts in their own in-house accounting servers with accounts corresponding to budget lines. Authorised signers write cheques against these accounts, while the organisation maintains a single account with an outside bank, integrating its own internal accounting system with the external financial system. Bank (N) Bank (A) Bank (B) Merchant <Check> Figure 7 Hierarchy of NetCheque servers Customer 4.6.1 The NetCheque model A NetCheque account is similar to a conventional bank account against which account holders can write electronic checks. An electronic check is like a conventional paper check in that it contains the customer s signature. Unlike a paper check, it has to also be endorsed by the merchant before the check is paid. A NetCheque consists of the following fields: amount of the check, unit of currency, date, account number, payee(s), signature of the customer and the endorsement(s) by the merchant and the bank(s). The last two fields are verifiable by the bank against which the check was drawn. To write a cheque, a user generates the cleartext portion of the check, specifying an account against which the cheque is to be drawn, the payee, the amount, and the currency unit. Defaults for the account and currency unit are read from the user s chequebook file. Then, the user obtains a ticket form a Kerberos server that is used to authenticate him to his bank (B) and allows him to share a session key with the bank. He then generates a checksum on the contents of the cheque and places it in an authenticator. He encrypts the authenticator with the session key that he shares with his bank and appends the ticket and the authenticator to the cheque.

T. Pilioura 217 The deposit cheque function reads the cleartext part of the cheque, obtains a Kerberos ticket to be used with the payer s bank, generates an authenticator endorsing the cheque in the name of the payee for deposit only into the payee s account, and appends the endorsement and the ticket to the cheque. An encrypted connection is opened to the payee s bank (A) and the endorsed cheque is deposited. If the payee and the payer both use the same bank, the response will indicate whether the cheque is cleared. If different banks are used, then the merchant s bank sends an indication to the merchant that the cheque has been for collection. The payee has the option of requesting that the cheque be cleared in real time, though we expect there may be a charge for this service, or batch processed by the banks. If the cheque has to be cleared through multiple banks, each bank attaches its own endorsement to the check, similar to the endorsement attached by the merchant. Once the check has been cleared by the customer s bank, the attached endorsements can be used to trace back the path to the merchant s account and eventually credit his account. In some cases the payee and payer's accounting servers can settle the check directly, bypassing higher levels of the hierarchy. This is possible when the cheque is drawn on an accounting server that is trusted to properly settle accounts. 4.6.2 NetCheque features Transaction cost This is pretty much the same as for a paper cheque except that it is assumed that the system is sufficiently economic to handle micropayments. Authentication In the NetCheque system, the Kerberos scheme is used to build authenticity. This doesn t use public keys for the certificates, but it has the same effect. The central Kerberos server must be online to generate a transaction key that is used between the two parties. This certifies them to each other because Kerberos sends the transaction key to each party encrypted with a different key known only to that party. Nonrepudiation and Payer Traceability Trust in this system emerges from a central server that can track all transactions. Payment confidentiality The first five fields of the check (presented in the section 4.6.1) are in cleartext and are readable by the bearer of the check. Payer anonymity Though NetCheque does not itself provide anonymity it may be used to facilitate the flow of funds between other services that do provide anonymity. Online NetCheque requires a Kerberos system to provide authenticity and this requires a central Kerberos server that generates Kerberos tickets. These Kerberos tickets are valid for a short period of time and this limits the amount of offline behaviour that is possible.

218 Electronic Payment Systems: A Survey 4.7 CyberCash CyberCash Inc., Reston, VA provides consumer software, merchant software and a gateway to support the secure communication of credit card transactions over the Internet. Customers are given CyberCash Wallets. Merchants use the Secure Merchant Payment System (SMPS). The CyberCash Gateway Servers are operated by CyberCash and in the future by banks. The system relies on the use of existing financial networks that are totally independent of the Internet for communicating between the CyberCash Gateway Server and the banks or credit institutions. 4.7.1 The CyberCash model A CyberCash [12] transaction can be described in nine steps (Figure 8): 1. The consumer requests the item desired by selecting it with a Web browser. 2. The merchant s server sends the wallet software a cleartext signed payment-request message that describes the purchase and indicates which credit cards the merchant accepts. 3. The wallet software thereupon displays a window that lets the consumer select which credit card to use, and approve the purchase and the amount. Then a credit card payment message, including a signed and encrypted description of the transaction, along with the consumer s credit card number is sent back to the merchant. 4. The merchant forwards the payment message, along with the merchant s own signed and encrypted description of the transaction, to the CyberCash gateway. 5. There, CyberCash decrypts and compares the two messages and their signatures. If they match, it submits a conventional authorisation request to the merchant s bank. 6. The merchant s bank then forwards the transaction to the customer s bank that sends an approval or denial back to the vendor s bank. 7. That response is then sent back to the CyberCash server. Consumer [1] Purchase request [2] Payment request [3] Credit card payment [9] Credit card response [4] Authorization request CyberCash Inc. Gateway Merchant [8] Charge response [5] Authorization request Consumer s card issuing bank [7] Charge response [6] Settlement Merchant s acquirer bank Figure 8 The CyberCash Transaction Model

T. Pilioura 219 8. CyberCash then sends the approval or denial response back to the vendor. 9. In the case of approval the merchant s software confirms the purchase to the consumer s wallet software (credit card response). Steps 1,2,3 and 9 take place on the Internet and involve a combination of public key and symmetric key cryptography. Steps 4, 5, 7 and 8 take place over dedicated lines. Step 6 takes place on the existing financial networks. CyberCash claim a complete transaction time of 15-20 seconds. 4.7.2 CyberCash features Transaction cost The system is not economic for micropayments because of the use of credit cards as the grounding financial instrument. Authentication and nonrepudiation The system uses 56 bit DES private-key to encrypt all the messages between wallets, merchants and CyberCash Gateway servers. The DES key, which is unique for each transaction, is then encrypted using RSA public key technology. Finally, a digital signature is appended for source authentication and nonrepudiation purposes. Message integrity The credit card information and the details of the purchase are encrypted for message integrity purposes. The greater the number of bits used by the encryption algorithm, the more difficult it is to unscramble or crack the message. Payment confidentiality In the second step of a CyberCash transaction presented in section 4.7.1 the merchant s software sends the wallet software a cleartext signed payment request message with the purchase details. This means that an observer can see the item purchased and the amount of the purchase. For the rest of the transaction, since the information is encrypted under CyberCash s public key, the merchant does not actually see the consumer s credit card number a procedure that in theory cuts the risk that customer credit card numbers will be abused. In practice, so many catalogue companies organise their customer marketing records by credit card numbers that an acquirer usually authorises CyberCash to provide them to merchants on request. Software-only CyberCash uses a special-purpose software, which, like a physical wallet, can be used by the consumer to register several credit cards. 4.8 SET SET [13] [14] was developed by VISA and MasterCard, with participation from leading technology companies, including Microsoft, IBM, Netscape, SAIC, GTE, RSA, Terisa Systems and VeriSign. SET is a standard for safeguarding credit card purchases made over open networks.

220 Electronic Payment Systems: A Survey Consumer [1] Request transaction [2] Acknowledge request [3] Purchase order [4] Purchase order verification [7] Status query [8] Purchase status information [5] Customer payment data Merchant Bank [6] Verify customer data [9] Request payment [10] Verify payment Figure 9 The SET Transaction Model 4.8.1 The SET model The operation of the SET protocol relies on a sequence of messages (Figure 9). In the first two, the consumer and merchant signal their intention to do business and then exchange certificates and establish a transaction ID number. In the third step, the consumer purchase request contains a signed hash of the goods and services order, which is negotiated outside the protocol. This request is accompanied by the consumer s credit card information, encrypted so that only the merchant s acquiring bank can read it. At this point, the merchant can acknowledge the order to the customer, seeking authorisation by the bank later (steps 5 and 6) or perform steps 5 and 6 first and acknowledge the order later. Steps 7 and 8 give the consumer a query capability, while the merchant uses steps 9 and 10 to submit authorisations for capture and settlement. 4.8.2 SET features Transaction cost Each purchase request transaction requires the exchange of a lot of messages between the customer and the trader and between the trader and the payment gateway and clearly this is not going to be economical for micropayments. Authentication By using a combination of RSA public key and DES symmetric key cryptography systems, along with a trust hierarchy of digital certificates SET aims to authenticate the identities of the parties involved in the transaction to each other. Nonrepudiation SET is signature based which provides potential dispute handling. Payment confidentiality In the SET protocol the bank card company gets involved in the middle of the transaction, essentially acting as a middleman. Theoretically, when the customer enters his card number in an online SET transaction, the commerce site might never see the customer s actual credit card number. Instead, that information would go to the financial institution, which would verify the card and the amount and then make the payment to the commerce site.

T. Pilioura 221 Anonymity The seller s knowledge of the buyer is only partial, as the account details are encrypted and are only visible to the payment gateway. Status The first live SET transaction was performed in Denmark on the last day of 1996 in an IBM pilot scheme. SET is still in testing status and the first applications based on SET are expected to appear by the end of 1998. It is expected that this protocol will supplant other schemes, and become a standard for all network transactions involving credit cards in the near future. 4.9 FirstVirtual One of the earliest credit card-based payment systems launched for the Internet was the product of a company called First Virtual Holdings, Inc. based at San Diego. 4.9.1 The FirstVirtual model Consumers and vendors establish an account with FirstVirtual [12] and fax or telephone their credit card numbers to it. Each account is assigned a VirtualPIN, which is then used to identify the consumers and the vendors during transactions. The transaction sequence runs as follows (Figure 10): 1. Initially, the buyer browses the FirstVirtual Web server or another Web server where a FirstVirtual merchant is selling goods. The buyer selects the item he wishes to purchase. The buyer is asked to enter his VirtualPIN, which is forwarded to the merchant. 2. The vendor emails the buyer s VirtualPIN, his own VirtualPIN and a description of the purchase to FirstVirtual. 3. If the VirtualPIN is valid, FirstVirtual informs the merchant that he can continue the transaction. 4. Then the information goods are sent directly to the customers. 5. The merchant forwards information about the transaction to the FirstVirtual Internet Payment System Server. 6. FirstVirtual automatically sends an email to the buyer asking if he is willing to pay for the information. 7. The buyer sends confirmation to FirstVirtual by return mail indicating accept, reject or fraud. Accept, in which case the payment proceeds; FirstVirtual submits the consumer s credit card number through its acquirer, and the consumer s card is charged. After holding the funds for 90 days, the company transfers them to the merchant by means of an automated clearinghouse. Reject, indicating that the goods either were not received or that the buyer is not satisfied to pay for them;

222 Electronic Payment Systems: A Survey Fraud, which means that these goods were not ordered by the buyer. Upon receipt of this message, the FirstVirtual server will immediately blacklist the VirtualPIN, so that the fraudulent use of this VirtualPIN cannot be continued. Web Server (selling goods) [2] Account ID valid? [3] Account OK! [5] Transaction Details FirstVirtual Internet Payment System Server [4] Information goods [6] Satisfied? [1] Account ID Buyer [7] Accept/Reject or Fraud Indication 4.9.1 FirstVirtual features Figure 10 Buying with FirstVirtual Authentication FirstVirtual guarantees to the merchant the validity of the customer s credit card and to the customer that the merchant actually exists since both the merchant and the customer have to be registered with FirstVirtual and are therefore identifiable. But on the other hand, no encryption means no digital certificates, which allows us to say that the authentication control of this system is only partial. For example, a stolen credit card number could be used to set up VirtualPINs associated with e-mail addresses controlled by the attacker, which may allow long periods where bogus transactions can be carried out. Message integrity First Virtual uses no encryption and relies upon the security of electronic mail system to keep transactions correct and accurate. It is quite clear that if a VirtualPIN becomes compromised by attackers eavesdropping on network traffic, bogus purchases can be made from the moment of the compromise until the time the VirtualPIN is blacklisted. Since payment authorisation requests are sent to the buyer by e-mail, this time period could range from a few minutes to perhaps a day or so. Denial of service or masquerade attacks on the e-mail system could prolong this period significantly. Experience with the first years of operation of the system has shown a very low fraud rate. The First Virtual system is based on what they call the Green Commerce model. This means that the risk of non-payments is carried by the vendor, although the risk of nonpayment is minimised. The company delays payment to merchants for 90 days, so that consumers have plenty of time to discover fraudulent charges on their credit card statements, in which case FirstVirtual can reimburse the credit card with the funds it is holding. In summary, we can say that the system is not entirely fraudproof, but in the context of its target market this is not of such great importance.

T. Pilioura 223 Nonrepudiation FirstVirtual aims at stopping repudiation through the social force of closing down the accounts of people who deny too many transactions. This promises to be a complicated process since they also encourage people to deny the charges if they are not satisfied with the material. Payment confidentiality There is no message confidentiality, except that the VirtualPINs may be viewed as pseudonyms. Payer anonymity The anonymity is partial to the extent that the vendor can see the buyer s email address and VirtualPIN and that the transaction is audible through the bank account that the VirtualPIN is tied to. Online First Virtual can operate with a wide range of connectivity. The system uses no cryptography, certificates or digital signatures so a merchant must have an online connection to verify that a particular account number offered by a customer is valid. The rest of the transaction does not need as much connectivity. Status The company s first product was launched in October 1994. It claims more than 180.000 customer accounts and 2.650 merchants in 166 countries. 4.10 Financial Services Technology Consortium (FSTC) FSTC is a large group of organisations (over 90 members) participating in non-competitive collaborative research and development on interbank technical projects. One of the FSTC s projects aims to provide the electronic equivalent of the existing check system provided by the traditional banks [13] [14]. The electronic cheque will use the existing interbank system. 4.10.1 The FSTC model All individuals capable of issuing electronic checks will be in possession of an electronic checkbook device based on some form of secure hardware. The function of this device will be to securely store secret-key and certificate information as well as maintaining register of what checks have been signed or endorsed recently. Figure 11 shows the check being sent to the payee in some kind of secure envelope. The form of this envelope is outside of the architecture and could be sent in a secure e-mail or in an encrypted interactive dialogue between the two parties. Because the electronic cheque is modelled on the existing cheque system there are a number of data flows that it can support. The FSTC lists four specifically: The Deposit and Clear Scenario: the payer receives a bill/invoice from the payee, issues an Electronic Cheque, and sends it to the payee. The payee presents the cheque to his bank, which, in turn, will settle it with the payer s bank. This is the typical cheque flow.

224 Electronic Payment Systems: A Survey The Cash and Transfer Scenario: the payer receives a bill/invoice from the payee, issues an Electronic Cheque, and sends it to the payee. The payee presents the cheque directly to the payer s bank to be paid to the payee s account at his bank. The Lockbox Scenario: the payer receives a bill/invoice from the payee, issues an Electronic Cheque, and sends it to the payee s bank. The payee s bank then sends accounts receivable information to the payee and clears the payment with the payer s bank. The Funds Transfer Scenario: the payer receives a bill/invoice from his bank (assuming electronic bill presentment allows for capture of the payee s bills by the payer s bank), issues an Electronic Check, and sends it to his bank. The payer s bank, in turn, transfers funds to the payee s account at the payee s bank. FSTC consumers use smart cards or secure processors to compose and sign electronic checks. By varying the information included in the check, one can produce a variety of different payment types. For example, changing the currency field could produce a traveller s check, whilst applying a bank s digital signature will yield a certified check. Checkbook (secure H/W) Invoice (secure H/W) Payer Invoice Payee Check Deposit slip E-mail account statement Signature Certificates Secure envelope E-mail account statement Check Signature Certificates Endorsement Payer s Bank Check clearing (ACH, ECP) Payee s Bank Certificates Secure envelope Figure 11 The FSTC Deposit and Clear Scenario Figure 11 shows the FSTC Deposit and Clear Scenario. A check is sent, together with the consumers public key certificates and transaction details to the payee for endorsement. The payee then adds its own signature and certificates and sends the check to its bank for deposit. Once it has reached this point, the FSTC envisage the processing as being identical to that undergone by any paper check. 4.10.2 FSTC features Authentication The FSTC model assumes that public keys and certificates are widely available, with banks vouching for their customers and associations of banks, such as an ACH, vouching for one another. Message integrity Security measures eliminates most of the causes of losses due to bad checks, including forgery, alteration, duplication and fraudulent depositing.

T. Pilioura 225 Payment confidentiality The FSTC protocol does not enforce encryption of the check itself, and merely requires that it be digitally signed. Without encryption any such transaction would be visible to an electronic eavesdropper. Note that it is not entirely clear what information will be visible to an observer: although the checks are digitally signed for authentication purposes, it is not obvious how much of the transaction information in the check is encrypted and how much is left as plain text. The documentation says that electronic checks may be encrypted when sent over public networks, so we assume this to be a negotiable variable in the actual protocol. Status A consortium of banks working through the FSTC Inc. has demonstrated a prototype electronic check system. It seams that this protocol will become the basis of all network transactions involving checks in the not too distant future. 5 Summary of comparison The following tables bring together all the evaluation results for the systems examined in this paper. Table 3 shows the notational systems, whilst Table 4 presents the token-based systems. In these two tables rows in white identify the common parameters of token-based and notational systems and rows in grey the parameters that are applicable to only one of these two categories of systems. NetBill NetCheque CyberCash SET FirstVirtual FSTC Transaction cost Medium Low High High High Low Authentication Full Full Full Full Partial Full Message integrity Nonrepudiation Partial Partial Partial Full Partial Partial Protocol dependent Full Full Full Partial Full Payment confidentiality Full None Partial Full None Partial Payer anonymity Partial None Full Partial Partial None Payer untraceability No No No No No No Online verification Yes Partial Yes Yes Yes Yes Software-only Yes Yes Yes Yes Yes No Status In Trial Commercialiselised Trial -lised Commercia- In Commercia In Trial Table 3 The notational systems

226 Electronic Payment Systems: A Survey DigiCash Millicent CAFE MONDEX Transaction cost Low Low Low Low Authentication Protocol Full dependent Full Full Message Protocol Full integrity dependent Full Full Doublespending Yes Yes Yes Yes prevention Loss-tolerance Yes No Yes Partial Payment Protocol Information not Full Full confidentiality dependent available Payer anonymity Partial Partial Partial None Payer untraceability Yes No Yes No Online verification Yes No No No Software-only Yes Yes No No Divisibility Yes Yes Yes Yes Change-return capability No Yes No No Transferability No No No Yes Purse-to-purse transfer Yes No Yes Yes Status Commercialised In Trial In Trial In Trial Table 4 The token-based systems 6 Conclusion In this paper, we have presented an overview of several payment systems and an evaluation of them according to some parameters. This evaluation is the result of personal interpretations according to the available documentation for each system and it is not based on discussions with the users of the systems. At the time of this writing there are several payment systems competing for a place in an electronic commerce world. It is likely that no single system will dominate the market, as there are competing requirements for different forms of transactions. As for any new technology, it would be impractical to view the status of electronic payments as clearly defined. Ambiguities exist in both the technological and institutional realms. Technological constraints include the insecurity of some types of payment systems, especially in the area of anonymity. Institutional constraints include government regulations and reluctance of existing financial institutions and consumers to adopt new payment technologies.

T. Pilioura 227 In general, the success of electronic payment systems greatly depends upon whether they serve the historic functions of money better than do the existing forms. Electronic payment systems might not completely replace traditional systems, but there is plenty of room to grow. References [1] N.Asokan, Phillipe A. Janson, Michael Steiner and Michael Wainder, The State of the Art in Electronic Payment Systems [2] Special Issue on Electronic Money, IEEE Spectrum, February 1997 [3] Donal O Mahony, Michael Peirce and Hitesh Tewari, Electronic Payment Systems, Artech House, 1997 [4] http://digicash.com [5] http://www.millicent.digital.com [6] S. Glassman, M. Manasse, M.Abadi, P. Gauthier, P. Sobalvaro, The Millicent Protocol for Inexpensive Electronic Commerce, Fourth International World Wide Web Conference, Boston, December 11-14, 1995 [7] J.-P. Boly, A. Bosselaers, R. Cramer, R. Michelsen, S. Mjolsnes, F. Muller, T. Pedersen, B. Pfitzmann, P. de Rooij, B. Schoenmakers, M. Schunter, L. Vallee, M. Waidner, The ESPRIT Project CAFÉ, High Security Digital Payment Systems, Third European Symposium on Research in Computer Security, LNCS 875, Springer-Verlag, Berlin 1994, p. 217-230 [8] http://www.mondex.com [9] http://www.netbill.com [10] B. Cox, J.D. Tygar, M. Sibru, NetBill Security and Transaction Protocol, Proceedings of First Usenix Workshop on Elecronic Commerce, New York, July 11-12, 1995 [11] http://nii.isi.edu/ghost-group/products/netcheque [12] http://www.cybercash.com/cybercash/wp/ [13] http://www.visa.com/cgi-bin/vee/nt/ecomm/set/main.html [14] http://www.mastercard.com/set/set.html