Chapter 9: Electronic Payment Systems


In this chapter, we overview and briefly discuss some electronic payment systems that can be used in e-commerce to transfer monetary value from one entity to another. After a short introduction in Section 9.1, we elaborate on electronic cash systems, electronic checks, electronic credit-card payments, and micropayment systems in Sections 9.2 to 9.5. Finally, we draw some conclusions in Section 9.6.

Note that electronic payment systems are subject to frequent changes and that it is not clear at the moment where the market is heading to and what electronic payment systems we will see in the future. Against this background, the chapter is kept short on purpose and provides many references to material that can be used for further study. More information is also available, for example, in three complementary books published in Artech House s computer security series. More specifically , [1] provides a comprehensive overview about the electronic payment systems that dominate the marketplace today, whereas [2] and [3] delve into the technical details of the Java Card and the smart cards that conform to the specifications developed by Europay, MasterCard, and Visa International (i.e., EMV cards). The books are recommended reading for anybody working in the field.

9.1    Introduction

The exchange of goods conducted face-to-face between two or more entities dates back to before the beginning of recorded history. Eventually, as trade became more complicated and inconvenient, human beings invented some increasingly abstract forms of representation for value. Consequently, we (or rather our predecessors) have experienced a progression of value transfer systems, starting from barter arrangements, through commodity money, coins and bank notes, payment orders, checks, and credit cards. This development is likely to continue in the future.

More recently, the progression of value transfer systems has culminated in electronic payment systems. In fact, the growing importance of electronic commerce (e-commerce) and corresponding applications has resulted in the introduction of a variety of different and partly competing electronic payment systems (again, you may refer to [1] for a comprehensive overview and discussion). Within currently available electronic payment systems, payments are done electronically , but the mapping between the electronic payments and the transfer of real value is still guaranteed by banks through financial clearing systems. These clearing systems are built on the closed networks of financial institutions (i.e., banks) that are considered comparatively more secure than open networks, such as the Internet.

It is important to note that all abstract forms of representation for value and corresponding value transfer systems suffer from well-known (and probably also some unknown) security problems. For example, money can be counterfeited, signatures on checks can be forged, and checks can be bounced. Electronic payment systems retain the same or similar security problems and may eventually pose additional risks. For example, unlike paper, digital data (representing monetary value) can be copied perfectly and arbitrarily often, digital signatures can be counterfeited perfectly by anybody who has access to the private key, and a customer s name can be associated with every payment, effectively eliminating the anonymity of conventional cash. Thus, without new security mechanisms and techniques being developed, implemented, and deployed, widespread use of electronic payment systems and corresponding e-commerce applications is not likely to take off.

All currently available electronic payment systems differ in details, but have the same basic purpose of facilitating the transfer of monetary value between multiple parties. In general, electronic payments involve a buyer (the party that wants to use the money to buy goods or services) and a merchant (the party that wants to sell goods or services and accepts money accordingly ). In the terminology of (electronic) payment systems, a buyer is often called a payer , and a merchant is often called a payee. The two pairs of terms are used synonymously and interchangeably in this book.

The intent of an electronic payment system is to safely and securely transfer monetary value from the payer to the payee. The transfer is accomplished by one (or several) electronic payment protocol(s). These protocols are general in nature and must not depend on the actual transport media in use. As a matter of fact, a payment protocol may be implemented as part of a Web application using HTTP, as part of an e-mail application using SMTP, or as part of any other application protocol. In either case, it must be ensured that the data involved in an electronic payment protocol execution is safe and secure, even if the medium is not. In the case that the medium is attacked , nothing more than a useless data stream must be obtained by the attacker. To provide this kind of safety and security, most electronic payment systems make use of some more or less sophisticated cryptographic techniques.

Note, however, that there is no obligation to use cryptographic techniques. For example, it has been possible for a long time to make credit-card payments without requiring the customer and merchant to be colocated . Credit-card companies have allowed orders to be taken either by post or telephone. These orders are collectively referred to as mail order/ telephone order (MOTO) transactions, and special rules have been imposed by the credit-card companies on how these transactions are to be processed . In fact, cardholders are asked to provide some additional information, such as their names and addresses, that are used to verify their identity. Also, if goods that require physical delivery are being ordered, they must be sent to the address associated with the cardholder. Although there are many possibilities for fraud and misuse associated with MOTO transactions, they are still very popular today (for certain applications the benefits simply outweigh the risks).

Using credit cards to make payments across computer networks (e.g., the Internet) has similar associated risks as are experienced with MOTO transactions. Attackers eavesdropping on network traffic may intercept data and capture credit-card and associated verification information. What makes the risks considerably higher than MOTO transactions is the open nature of computer networks and the speed in which transactions can be conducted in these networks. [1]

Against this background, there are only a few electronic payment systems for the Internet that don t make use of cryptographic techniques. For example, one of the earliest credit-card-based payment system was marketed by a company called First Virtual Holdings (FV). [2] In October 1994, the company commenced operation of a noncryptographic payment system called the VirtualPIN. The goal of the VirtualPIN system was to allow the selling of low-value information goods across the Internet without the need for special-purpose client hardware or software to be put in place.

In the VirtualPIN system, both the customers and merchants had to register with FV before any transactions could take place.

  • A customer registering with FV had to forward credit-card information and an e-mail address to the FV server and in exchange received a pass phrase, called a VirtualPIN. This initial part of the exchange could take place across the Internet, with the user filling out a form and inventing the first part of a pass phrase. The FV server acknowledged this and added a suffix to the pass phrase to actually form the VirtualPIN. The customer then made a telephone call to FV to tender credit-card information. This allowed FV to establish a link between the VirtualPIN and the pass phrase on the one hand and the customer s credit-card information on the other hand without ever using this information on the Internet.

  • Merchants had to go through a similar registration procedure in which they gave bank account information to FV and then were given a merchant VirtualPIN.

After a customer had properly registered with FV, he or she could browse any Web site on which a FV merchant was selling goods. The customer selected the item(s) he or she wished to purchase and was asked to enter the VirtualPIN (representing his or her FV account identifier). The VirtualPIN was then forwarded to the merchant, and the merchant checked that it was valid by querying a corresponding FV server. If the customer s VirtualPIN was not blacklisted, the merchant delivered the information to the customer and forwarded information about the transaction, including the customer s VirtualPIN, to the FV server. No payment was made at this point, since the system was based on a try-before-you-buy philosophy. Consequently, the next step was for the FV server to send an e-mail message to the customer asking whether he or she accepted or rejected the goods. In addition, the customer could also indicate that a fraud was going on (as a third option). Upon receipt of this message, the FV server would immediately blacklist the customer s VirtualPIN. At the end of every 90 days, the customer s credit-card account was debited for the charges that had accumulated during the time period, and the corresponding merchant s checking account was credited with payments for the items sold. FV performed the accounting for both the customer and merchant, taking a percentage of each transaction as a commission fee.

It is obvious that if a VirtualPIN was compromised by an attacker eavesdropping on network data traffic, bogus purchases could be made from then until the VirtualPIN was blacklisted. Since payment authorization requests were sent to the customer by e-mail, this time period could range from a few minutes to perhaps a couple of days. Furthermore, degradation-of-service and denial-of-service attacks on the e-mail system could be used to prolong this period substantially. Consequently, the actual security of the FV payment system was not based on the VirtualPIN and the pass phrase, but rather on the customer s ability to revoke each payment within a certain period of time. In other words, there was no definite authorization during payment. Until the end of the clearing period (typically 90 days as mentioned above), the merchant had to take the entire risk.

A similar credit-card-based system has been developed and is being marketed successfully by PayPal [3] . The system is, for example, used to settle purchases made on Internet auction sites, such as eBay. [4] Contrary to FV and PayPal, however, most contemporary electronic payment systems are more complex and use more sophisticated cryptographic techniques. Most of these systems require at least one financial institution, such as a bank, that links the data exchanged in the payment protocol to corresponding transfers of monetary value. Typically, banks participate in electronic payment protocols in two roles:

  • As an issuer (interacting with the customer or payer);

  • As an acquirer (interacting with the merchant or payee).

In addition, there may be some form of arbiter to settle disputes. In most electronic payment systems, the presence of an arbiter is not explicit. Even if the necessary pieces of evidence are produced, disputes must be handled outside the actual payment systems. In many cases, dispute handling is not even specified. This is about to change, since contemporary research in electronic payment systems and the provision of nonrepudiation services also addresses dispute handling.

In general, electronic payment systems are classified according to the relationship between the time the payment initiator (i.e., the customer) considers the purchase as finished and the time the corresponding monetary value is actually taken from his or her account. Consequently, one can distinguish between prepaid , pay-now, and pay-after payment systems:

  • In a prepaid payment system , a certain amount of money is taken away from the customer (for example, by debiting his or her bank account) before any purchase is made. This amount of money can afterward be used for payments. Smart card-based electronic purses and wallets, electronic cash, and certain bank checks (i.e., certified checks) fall into this category.

  • In a pay-now payment systems , the customer s account is debited exactly at the time of the purchase. Certain debit cards fall into this category. [5]

  • Finally, in a pay-after payment system , the merchant s bank account is credited the amount of the purchase before the customer s account is debited. Normal credit cards fall into this category.

Note that any prepaid payment system is conceptually similar to physical cash. Consequently, they are sometimes also referred to as cashlike payment systems. Also note that the later two payment systems (i.e., pay-now and pay-after payment systems) are also similar in nature. In either case the payer must have some sort of ˜ ˜account with the bank, and a payment is always done by sending some form, such as a check or credit-card slip, from the customer to the merchant. Consequently, these two categories of payment systems are sometimes collectively referred to as checklike payment systems. Note that a key difference between cashlike and checklike payment systems is also due to the fact that providing anonymity in a cashlike payment system is possible and conceptually simple, whereas anonymity in a checklike payment system is inherently more difficult to provide (this is because the merchant must have some kind of guarantee that he or she will actually receive his or her money anytime in the future).

In the field of electronic payment systems, the notions on-line and off-line refer to a specific property of the corresponding payment protocol. Although the payment protocol is functionally a protocol between two parties (i.e., the customer and the merchant) many payment systems require that the merchant contact a TTP acting as a central authority (e.g., a bank, a credit-card company, or an acquirer) before accepting a payment. If that is the case, the system is called an on-line payment system. In this case, the communication between the merchant and the central authority may be using any communication medium (not necessarily the Internet). If such a contact with a TTP is not required during the payment protocol, the system is called an offline payment system . In an offline payment system, merchants are required to contact their acquirer on a regular basis for clearing all received payments.

In general, on-line payment systems are more appropriate to adequately secure the merchant and the bank against customer fraud, since every payment must be approved. The primary disadvantage of on-line authorization is the associated per-transaction cost, imposed by the requirement for a highly reliable and efficient clearing system at the customer s bank. Consequently, offline payment systems have been designed (and still continue to be designed) to lower the cost of transactions by delaying the clearing to a batch process. Offline systems, however, suffer from the potential of double spending, whereby the electronic currency is duplicated and spent repeatedly. Thus, offline protocols concentrate on preventing or detecting and limiting fraud, and in catching the fraudulent party in the second case. Offline systems that detect and limit fraud are generally suitable only for low-value transactions where accountability after the fact is sufficient to deter abuse.

In the remaining part of this chapter, we overview and briefly discuss the working principles of electronic cash systems, electronic checks, electronic credit-card payments, and micropayment systems. For each category we mention some exemplary systems by name.

[1] The major security problems are still related to the way the credit-card information is handled on the client and server sides.

[2] The First Virtual Holdings, Inc., does not exist anymore.

[3] http://www.paypal.com

[4] http://www.ebay.com

[5] For example, Switch debit cards are very common in the United Kingdom. They are issued by banks and are used like credit cards, although the money is deducted from the customer s bank account immediately. Further information about Switch debit cards can be found at the home page of Switch Card Services Ltd. at http://www.switch.co.uk/switch.htm.




Security Technologies for the World Wide Web
Security Technologies for the World Wide Web, Second Edition
ISBN: 1580533485
EAN: 2147483647
Year: 2003
Pages: 142
Authors: Rolf Oppliger

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net