ELECTRONIC PAYMENT SYSTEMS

1. ELECTRONIC PAYMENT SYSTEMS

2. A Brief History of Money Originally, the trade began in form of a barter system wherein people exchanged goods that they possessed with the goods belonging to other people. Things soon became complicated with the availability of goods, belonging to both parties in the later system, not coinciding. As a result, a medium of exchange, in the form of tokens, evolved.

3. The tokens were objects that everyone found valuable, such as precious stones and shells. These tokens, made of precious stones and shells, formed the earliest forms of currency. Later these tokens were replaced by the coins minted in precious metals. An important aspect of minted coin was that the metal itself was valuable.

4. Later came: • Rupee or a dollar • Notational money in the form of Cheques • Credit cards – a credit based system • Electronic Payment System.

5. The various payment mechanisms can be broadly classified into three categories – Cash, Cheques and credit cards. Many virtual shops, on the internet, accept payment through digital cash, electronic cheques or the credit card mechanism. Digital cash is the electronic equivalent of physical cash, with all the inherent properties of cash embedded in it. Digital cash represents, in a sequence of binary numbers, an intrinsic value in a chosen currency. Online Payment Systems

6. During transmission from the buyer to the seller, the binary numbers are susceptible to interception by packet sniffing programs, and hence resultant fraud. Encryption offers solutions to some of the problems. Security remains a paramount concern in an electronic payment system. Digital money is represented in bits and bytes, thus, unlike minted money it is far easier to replicate, at almost zero cost.

7. Basic requirements are: • Acceptability: The payment infrastructure should not only be robust, but also available and accessible to a wide range of consumers and sellers of goods and services. The value stored in the digital cash should be honored and accepted by other banks and financial institutions for reconciliation.

8. Convertibility: The electronic currency should be interoperable and exchangeable with the other forms of electronic cash, paper currencies, and deposits in bank accounts, bank notes or any other financial instruments. • Flexibility: Payment systems should be in a position to accept several forms of payments rather than limiting the users to a single form of currency.

9. Reliability: The payment system should ensure and infuse confidence in users. The users should be completely shielded from systemic or a single point failure. • Efficiency: Efficiency here refers mainly to the cost overheads involved in the operation of digital payments. The cost of payment per transaction should be ideally close to zero. This assumes added significance in the case of micro payments that are typically in the range of fraction of a currency unit.

10. Security: Digital currency should be stored in a form that is resistant to replication, double-spending, and tampering. At the same time, it should offer protection from the intruders trying to tap it and put it to unauthorized use, when transmitted over the internet. • Usability: The user of the payment mechanism should be able to use it as easily as real currency. This requires that the payment system should be well integrated with the existing applications and processes that acquire the role of transacting parties in electronic commerce.

11. Scalability: The payment system should offer scalable solutions, i.e., it should be able to offer the same performance and cost per transactions overheads with a growing number of customers and transactions.

12. Based on the size of payment, all payment transactions can be classified in the following three categories: • Micro payments: These transactions usually involve ones that have very low payment value. At times, the value of a transaction may be a fraction of a currency unit. Typically, transactions that are of five or lesser currency units, in case of dollars, and fifty in case of the rupee, are treated as micro payments. Since, the transactions are of such a low value; even a small overhead may become unbearable. Thus, systems for micro payments have to ensure near zero overhead, in order to make them viable.

13. Consumer payments: These payments typically involve values of five to five hundred currency units, in case of dollars and Euros, and may be 50 – 500 units, in case of the rupee. These are the dominant form of payment transactions, as most of the consumers buying in a single shopping trip fall under this category.

14. Business Payments: Usually transactions that are of higher amounts – five hundreds and above in case of dollars or five thousands and above in case of rupee – are treated as business payments. Businesses payments usually have an invoice associated with them. Business – to – business payment transactions are in the higher range, and fall in this category.

15. Pre – Paid electronic payment Systems eCashTM eCashTMia a purely software based, anonymous, untraceable, online token payment system, available on Unix, Windows, as well as Macintosh platforms. Customers as well as merchants require graphical wallet software that can also be accessed via a command line interface. eCashTM allows for bi-directional payments. There is no distinction between customers and merchants with regards to payments. Both sides can give and receive payments.

16. However, since the system is coin based, it requires clearing of coins by it issuing bank. The implementations of various transactions with eCashTM are as follows: Withdrawal: There are participants in the withdrawal transaction, the bank and the customer. A customer connects to an eCashTM issuer and purchases electronic coins of the required value. These coins are generated, involving the blind signature scheme to make the tokens anonymous. The customer generates the token ids, blinds them, determines their denominations, transmits them unbinds them and stores them on his PC, in a wallet.

17. Purchase: Once a customer has eCashTMon his hard drive, he can buy things from the merchant’s shop. If the customer shows the intent to purchase a product, he receives a payment request from the merchant, which he has to confirm. His eCashTM software chooses coins and sends them over the network, to the merchant’s shop. When it receives the coins, the merchant’s software automatically sends them on to the bank and waits for acceptance before sending the goods to the customer, along with a receipt.

18. Customer-to-Customer: When a Customer receives a payment, the process would be the same. But some people may prefer that when they receive money, it be made available on their hard disk immediately, ready for sending. The only difference between this payment from a customer to another customer and the earlier one is what happens after the bank accepts the cash. Once the second consumer has configured his software, he requests the bank to withdraw the eCashTM just deposited, and send it back to his PC as soon as the coins are accepted.

19. Privacy Protection (Blind Signature): In the simple withdrawal described earlier, the bank creates unique blank digital coins, validates them with its special digital stamp, and supplies them to the customer. This would normally allow the bank (at least in principle) to recognize the particular coins when they are later accepted in a payment, and also it exactly which payments were made by the customer.

21. By using ‘blind signature’, the bank is able to validate coins without tracing them to a particular account. Instead of the bank creating a blank coin, the customer’s computer creates the coin itself at random. Then it hides the coin in a special digital envelope and sends it off to the bank. The bank withdraws one dollar from the customer’s account and makes its special ‘worth-one-dollar’ digital validation, like an embossed stamp, on the envelope before returning it to the customer’s computer.

22. Like an emboss, the blind signature mechanism lets the validating signature be applied through the envelope. When the customer’s computer removes the envelope, it has obtained a coin of its own choice, validated by the bank’s stamp. When he sends the coin, the bank must honor it and accept it as a valid payment because of the stamp. But because the bank is unable to recognize the coin, since it was hidden in the envelope when it was stamped, the bank cannot tell who made the payment. The bank that signed can verify that it made the signature, but it cannot link it back to a particular owner.

23. Mondex The mondex purse is a smart card alternative to cash. The Mondex purse, a self-standing value store, requires no remote approval of individual transactions. Rather, the mondex value equivalent to cash is stored in the card’s microchip. The purse also stores secure programs for manipulating that value and for interfacing with other Mondex cards or terminals.

24. After withdrawal from an ATM, the value (money) can be transferred from one card to another via a special, password protected, electronic wallet. The first implementation of Mondex supports upto five different currencies, each separately accounted for by the card. The Mondex system uses the following hardware:

25. Mondex smart and • Mondex retailer terminal; to transfer funds from the customer card to the merchant terminal. • Mondex wallet: a pocket sized unit for storing larger sums of digital money than the card. • Mondex balance reader: a small device to reveal the balance remaining on the Mondex Card.

26. Mondex hotline: to access the bank account, to transfer money to the card, to check the balance, and to transfer money to other cardholders. • Mondex ATM (Automated Teller Machines): to recharge cards or to transfer money back into the account.

27. Transaction: the sequence of steps in a particular is: • Customer loads value (money) onto the card, either from an ATM machine or from a phone. • On purchase of an item, the customer provides his card to the merchant’s point of sale device and authorizes the transfer of a certain value. • The amount is electronically deducted from the chip inside the customer’s card and added to the amount on the retailer’s chip.

28. All this is accomplished without accessing the customer’s bank balance or checking his or her credit worthiness.

29. Net Bill NetBillhas been conceived to address the problem of buying information goods over the internet. As opposed to the physical goods purchased on the internet, and shipped later by the merchant, the information goods are themselves transferred over the internet, to the customer. Preferably, this transfer should take place immediately after purchase. Hence, the issue to be addressed in such a transaction are very different from these on transactions involving physical goods.

30. Transaction: The transaction flow is depicted in the fig. and the sequence of transactions using NetBill is described as follows: • The customer buys information goods from the merchant. • The Merchant sends goods, in encrypted form, to the customer.

31. The customer’s software verifies that the goods were received from customer, the account information of this to the merchant software. • The merchant submits the verification message received from customer, the account information provided by the customer, and the decryption key to the NetBill server.

32. The NetBill server verifies that the customer has sufficient money in the account to pay for the goods. In case of sufficient funds, it transfers funds, stores the decryption key, and sends the report to the merchant software. • The merchant then sends the customer decryption key, which the software on the customer machine uses to decrypt the goods. In case the merchant server fails to deliver the decryption key, the software on customer server can acquire the key from the NetBill server.

33. The NetBill server keeps accounts for all merchants and customers. The accounts are linked to accounts at a traditional bank. The NetBill server operates transitionally, to ensure that the consumer does not get billed for goods he cannot decrypt, or receive goods without paying for them.

35. Security: NetBill uses a combination of public key cryptography and symmetric key cryptography to make sure that all NetBill communications are secure, and all transactions are authorized. NetBill’s approach is based on the well tested Kerberos protocol, which has been widely used for nearly a decade by most major computer manufacturers.

36. Kerberos is a network authentication system for use on physically insecure networks to prove their identity to each other, while preventing eavesdropping. It is also provides for data stream integrity and secrecy, using cryptography systems such as DES. Kerberos works by providing the principals with tickets that they can use to identify themselves to other principals, and secret cryptographic keys for secure communication with other principals.

37. REQUIREMENTS METRICS OF A PAYMENT SYSTEM The importance of individual characteristics is determined by the actual need of the transacting parties. For example, for one user remaining anonymous during transactions could be the most important thing, while for other the ability to carry out low value transactions, efficiently, may be the important feature. When deciding on a particular digital payment system, the possible characteristics have to be ranked according to the preferences and needs of the decision maker.

38. Schoter and Willmer, in 1997, and Ron Weber, in 1998, described certain requirements for evaluating and cross comparing various electronic payment systems. Here, we discuss these requirements in a payment system, on the basis of which payment systems can be evaluated.

39. Transaction: Transaction, in the context of payment systems, refers to the actual exchange of currency with the goods (documents) being transferred. Every transaction should exhibit the following four characteristics.

40. Atomicity: it refers to the system’s ability to ensure that no partial transaction or exchanges can take place. In other words, if system failure takes place in the middle of a transaction, the effect of the transaction will be fully erased, and the system will be restored to the original state. That is, either a transaction should occur completely or it should not occur at all.

41. Transfer of funds: There should not be any currency loss in the transaction. Either a full transfer - in which the account of the payer is debited and the account of the payee is credited with the corresponding amount-should take place or no change of accounts should occur at all.

42. Complete Transfer: This is applicable in the case of digital goods transfers over the net. A complete exchange of currency with the corresponding digital goods should take place. If a digital goods delivery is linked to its payment, then either both should happen or none at all. This is also referred to as the fair exchange protocol.

43. Consistency: There should be no ambiguity in the transaction. All parties concerned must agree on the relevant facts, i.e., amount and reason of transfer, of the transaction. • Isolation: Transactions must be independent of each other. The result of a set of concurrent transactions must be equivalent to a sequential arrangement of these transactions.

44. Durability: Durability becomes important in case the system crashes during the transfer. Even after a system crashes, the system should recover to a state, where transactions and status information is consistent. If the crash occurred prior to transfer than the system should reflect the prior state, otherwise it should show the durable effect of the transfer.

45. Security Security, in the context of payment systems, refers to the system’s ability to protect all parties from frauds, due to interception of online transmission and storage. The payment system should be secure enough to offer the following:

46. Fraud Protection: Digital payment systems must be tamper resistant and should have built-in mechanism to prevent illegal use of digital cash. At the very least, the digital payment systems must provide the means for detection and punishment of misuse, after the fraud.

47. No Double Spending: Since digital cash is represented by bytes that can be easily copied and respent, the digital payment system should safeguard against reuse of currency. This type of fraud can be initiated not only by customers who might reuse digital money for several purchases, but also by merchants who could attempt to resubmit digital money for redemption.

48. No Counterfeiting: The system should be able to detect fake currency. It should be easy to distinguish between legal money tokens and unauthorized illegal money.

49. No Overspending: The system should have the means to ensure that the user is unable to spend beyond the money represented by token, or held in the purse. Prevention of customer overspending, i.e., exceeding spending limits, is another fraud protection issue, especially in account based system.

50. Non-refutability: The parties involved should be able to verify that the payment transaction has taken place, along with the amount and the purpose of transaction. A record of the transaction should be produced, on demand, in case of dispute, though it may have implications on the control of privacy.