The system is broken up into three parts; a visual barcode, MyPay Android ......
Figure 17 Credit Card Example (Source: http://www.credit-‐cards.co.za/credit-‐.
Honours Project Report PaymentPortal a Cost-‐Efficient Mobile Cashless Payments Platform using Visual Identification Adrian Maritz 1 2 3 4 5 6 7 8 9
Category Min Max Software Engineering/System Analysis 0 15 Theoretical Analysis 0 25 Experiment Design and Execution 0 20 System Development and Implementation 0 15 Results, Findings and Conclusion 10 20 Aim Formulation and Background Work 10 20 Quality of Report Writing and Presentation 10 Adherence to Project Proposal and Quality of 10 Deliverables Overall General Project Evaluation 0 10 Total marks 80
Supervisor: Gary Marsden Department of Computer Science University of Cape Town 2011
Chosen 10 0 10 10 15 15 10 10 0 80
Abstract This report explores a solution to create a cashless mobile payments system. The aim is to provide a most cost efficient and secure alternative to current systems. Current systems use SMS and USSD to process payments. These are not cost effective methods of communication. There is also no current method of processing credit card payments on a mobile phone without the need for a specialized piece of hardware. The system is broken up into three parts; a visual barcode, MyPay Android application and a payment server. The identification of cardholder is encoded in a QR Code allowing the built-‐in camera on a mobile phone to scan a card. This was improved on by using a HTTPS connection between mobile phone and server. HTTPS provides an encrypted communication channel. This report shows that a mobile phone is capable of processing card payments on a mobile phone. The QR Code was used to identify the card and process the cardholder’s details. The system provided sufficient encryption and authentication. The cost per payment was reduced to 0.6 cents a transaction. The time taken to process a payment was within an acceptable limit. The system met payment regulations and received good feedback from expert evaluators.
Acknowledgements I would like to thank my supervisor, Gary Marsden for all his help and feedback during the course of this project. I would also like to thank Amanda Nightingale, head of mobile payments at S1 Corporation, for all her input during the design process and valuable feedback on the final system. Finally I would like to thank HomeChoice and Foschini Group Financial services for all their valuable feedback and evaluation of the project.
2
Contents 1 Introduction Chapter .............................................................................................. 7 2 Background Chapter ............................................................................................... 9 2.1 Overview of Research ................................................................................................................................... 9 2.2 Current Mobile Cash Providers ................................................................................................................ 9 2.2.1 M-‐PESA (Kenya) .......................................................................................................................................... 9 2.2.2 FNB eWallet ................................................................................................................................................ 10 2.3 Methods of conducting mobile payments ......................................................................................... 10 2.3.1 USSD ............................................................................................................................................................... 10 2.3.2 RFID ................................................................................................................................................................ 11 2.3.3 Bluetooth ...................................................................................................................................................... 11 2.3.4 NSDT ............................................................................................................................................................... 12 2.3.5 WAP ................................................................................................................................................................ 12 2.3.6 Overview of current methods .............................................................................................................. 12 2.4 Types of Mobile Payments ....................................................................................................................... 14 2.4.1 Mobile at Point of Sale ............................................................................................................................ 14 2.4.2 Mobile as Point of Sale ............................................................................................................................ 14 2.4.3 Direct Carrier Billing ............................................................................................................................... 15 2.5 Android Smart Phones .............................................................................................................................. 15 2.6 Storing data visually with use of 2D barcodes ................................................................................ 15 2.6.1 QR Codes ....................................................................................................................................................... 17 2.6.2 Data Matrix ................................................................................................................................................. 18 2.6.3 Choosing an optimal 2D Barcode ...................................................................................................... 18 3 Design Chapter ..................................................................................................... 19 3.1 Aim of proposed system ........................................................................................................................... 19 3.2 Scenarios ......................................................................................................................................................... 20 3.2.1 Registering new merchant ................................................................................................................... 20 3.2.2 Adding new card ....................................................................................................................................... 20 3.2.3 Make Payment ........................................................................................................................................... 21 3.2.4 Recharge card ............................................................................................................................................ 22 3.2.5 P2P payments ............................................................................................................................................. 22 3.2.6 Reset PIN ...................................................................................................................................................... 23 3.3 Problems faced with implementing a Mobile Payments system ............................................ 24 3.4 Communication between mobile phones and central processing server ........................... 24 3.5 Overview of System .................................................................................................................................... 25 3.5.1 PaymentPortal Card ................................................................................................................................ 25 3.5.2 PaymentPortal Web Service ................................................................................................................ 26 3.5.3 MyPay Mobile Phone Client .................................................................................................................. 26 3.6 Design Requirements ................................................................................................................................. 27 3.6.1 Cost Efficient ............................................................................................................................................... 27 3.6.2 Secure Communication .......................................................................................................................... 27 3.6.3 Security ......................................................................................................................................................... 27 3.6.4 Authentication ........................................................................................................................................... 27 3.6.5 Notifications ................................................................................................................................................ 28 3.6.6 Open-‐Platform ............................................................................................................................................ 28 3.6.7 Response Times .......................................................................................................................................... 28 3.6.8 Ease of Use ................................................................................................................................................... 28 4 Implementation Chapter ...................................................................................... 29 4.1 Layout of project .......................................................................................................................................... 29
3
4.2 The PaymentPortal Card .......................................................................................................................... 29 4.2.1 Choosing 2D Barcodes ............................................................................................................................ 29 4.2.2 Generating Unique Identifiers (QrID) .............................................................................................. 30 4.2.3 Generating QR Codes ............................................................................................................................... 31 4.3 PaymentPortal Server ............................................................................................................................... 31 4.3.1 Communication Protocol Used ........................................................................................................... 31 4.3.2 Java Servlets ................................................................................................................................................ 31 4.3.3 Registering New PaymentPortal Card ............................................................................................ 33 4.3.4 Processing Payment ................................................................................................................................. 34 4.3.5 Server Security ........................................................................................................................................... 34 4.3.6 Notification System .................................................................................................................................. 37 4.3.7 Moving PaymentPortal Server to Amazon EC2 ........................................................................... 39 4.3.8 Paymentportal.co.za domain registration .................................................................................... 40 4.4 Database design ........................................................................................................................................... 40 4.5 MyPay Android Client ................................................................................................................................ 41 4.5.1 Notifications ................................................................................................................................................ 41 4.5.2 QR Scanning ................................................................................................................................................ 42 4.5.3 User Interface Design .............................................................................................................................. 43 4.5.4 Send Money (P2P) Interface ................................................................................................................ 44 4.5.5 Merchant User Interface ........................................................................................................................ 46 4.5.6 Servlet Calls ................................................................................................................................................. 49 4.6 PaymentPortal Features ........................................................................................................................... 49
5 Evaluation and Testing Chapter ............................................................................ 50 5.1 Latency ............................................................................................................................................................. 50 5.2 Data used ......................................................................................................................................................... 54 5.3 Stress Test System ...................................................................................................................................... 55 5.4 Expert Feedback .......................................................................................................................................... 57 5.4.1 Homechoice ................................................................................................................................................. 57 5.4.2 The Foschini Group (TFG) ..................................................................................................................... 57 5.4.3 S1 Corporation ........................................................................................................................................... 58 5.5 Overview of evaluation ............................................................................................................................. 58 6 Conclusion ............................................................................................................ 59 7 Future Work ......................................................................................................... 60 8 Reference ............................................................................................................. 61 9 Appendix .............................................................................................................. 63
4
List of Figures Figure 1 MasterCard PayPass Terminal (Source: http://bit.ly/nzSVCs)………………………14 Figure 2 Square Dongle (Source: http://bit.ly/f2280F) …………………………………….............14 Figure 3 The history of barcodes Source: [17] ……………………………………................................15 Figure 4 2D Barcodes (Source: http://bit.ly/s0Auie) ……………………………………..................17 Figure 5 Examples of QR Code and Data Matrix……………………………………..............................18 Figure 6 Register New Merchant Use-‐Case……………………………………...…………………………20 Figure 7 Add New Card Use-‐Case……………………………………...……………………………………....21 Figure 8 Make Purchase Use-‐Case……………………………………....……………………………………..21 Figure 9 Recharge Card Use-‐Case……………………………………...……………………………………....22 Figure 10 P2P Payment Use-‐Case……………………………………...……………………………………....23 Figure 11 Reset PIN Use-‐Case……………………………………...……………………………………...........23 Figure 12 Overview of PaymentPortal System…………………………………………………………...25 Figure 13 QR Codes with varying complexity with amount of data encoded………………..25 Figure 14 Example of Printed MyPay Card……………………………………...…………………………30 Figure 15 Calculating duplicate UUID probability……………………………………...……………….30 Figure 16 Google Graph API Example………………………………………………………………………..31 Figure 17 Credit Card Example (Source: http://www.credit-‐cards.co.za/credit-‐ cards/)……………………………………...……………………………………...………………………………33 Figure 18 Luhn Algorithm Example……………………………………...…………………………………...33 Figure 19 Public-‐Key Encryption used in HTTPS communication (Source: http://bit.ly/u0DFS6)……………………………………………………………………………………….35 Figure 20 HTTPS Details for ABSA Online Banking…………………………………………………....36 Figure 21 Clickatell URL Exmaple……………………………………………………………………………...37 Figure 22 Bit.ly HTTP API Example…………………………………………………………………………...38 Figure 23 SMS New Card Notification……………………………………...………………………………...38 Figure 24 SQL EER Diagram……………………………………...……………………………………...............41 Figure 25 Displaying a Toast Message……………………………………………………………………….41 Figure 26 Adding new card Toast response……………………………………...………………………..42 Figure 27 Label vs. Hint for Textbox……………………………………...…………………………………..43 Figure 28 Start Screen Options……………………………………...…………………………………….........44 Figure 29 Quick Pay (P2P) Screen Flow……………………………………...……………………………..45 Figure 30 Overview of Merchant interface layout……………………………………...……………….47 Figure 31 Onscreen Keyboard Layouts……………………………………...………………………………48 Figure 32 HTTP vs. HTTPS Comparison on EDGE……………………………………..........................51 Figure 33 HTTP vs. HTTPS Response Comparison on 3G/HSDPA……………………………….52 Figure 34 Comparison between 128bit and 256bit encryption…………………………………..53 Figure 35 Iftop screenshot of while processing MyPay Login……………………………………...54 Figure 36 JMeter results with 200 Login Request in 1sec……………………………………..........56 Figure 37 JMeter results with 300 Login Requests in 1sec………………………………………......56
5
List of tables Table 1 Comparison of different technologies used for mobile payments…………………...13 Table 2 Comparison between 2D barcode and other automatic identification techniques (Source: http://bit.ly/nJi5IP)………...…………………………………………………………………..17 Table 3 Barcode scanning results…………………………………………………………………...…………29 Table 4 Latency Results of mobile phones…………………………………………………………………50 Table 5 Max and Min Latency Results………………………………………………………………………..51 Table 6 Latency of HTTP vs. HTTPS connections………………………………………………………..52 Table 7 Median Latency for 128 vs. 256bit encryption……………………………………………….53 Table 8 Median Latency for MyPay Requests……………………………………………………………..53 Table 9 Cost Per Request………………………………………………………………………………………….55
6
1 Introduction Chapter The aim of this project is to establish the feasibility of a mobile cashless payments system in developing nations like South Africa. The reason for a new system is due to current systems not being developed with security and communication costs involved. At the moment in some rural parts of South Africa people are using prepaid airtime as an alternative currency [7]. With an estimated 5.3 billion mobile phone [1] users worldwide the demand for further uses of mobile phones, other than communication, is needed. A mobile phone is no longer just used to communicate with people. It is also being used to do mathematical calculations, play music and take pictures and videos. For example, a smartphone can send and receive emails, surf the Internet and take notes. Therefore, it is now possible to run a small business from a mobile phone, thus removing the need for a computer. With the capabilities of mobile phones increasing, new forms of doing business have been created. One of these new uses for mobile phones are mobile transactions, sending money from one mobile phone to another. In 2009, Gartner identified that money transfer would be the number one consumer mobile application for 2012. The reasons for this are due to its lower costs, faster speeds and improved confidence when compared to traditional money transfer techniques [2]. Mobile payments form part of this mobile money transfer trend because a payment is just a transfer of money from one person to another. Potentially the greatest problem with mobile payments is the regulatory requirements of the different markets that it has been tested in. For this reason the market is very fragmented with many different methods being used. Mobile phones have made it possible for people without bank accounts to do financial transactions on their phones using a form of credit system or prepaid airtime. There has become more demand for mobile applications that supply pro-‐poor services [3] with a focus on providing them with access to financial services. In many developing countries these mobile payments services are the first financial service for the previously ‘unbanked’ people. More than a billion people worldwide lack access to traditional financial services yet many of them have mobile phones and access to wireless telecommunication networks [6]. They offer a compromise between formal bank accounts and temporary money transfers. Experts predict that by 2010, 364 million people will rely on mobile money [6]. Japan is one of the pioneers in this market. In December 2010, 9.8 million Japanese mobile users made purchases using their mobile wallets on their mobile phones. This is nearly 10% of all mobile subscribers in Japan. The majority of these purchases were in retail or convenience stores. Informal enterprises represent a major source of income for many people in developing countries (Frempong, 2009). Most of these enterprises are run primarily as a source of sustenance and therefore tend to remain small (Donner & Escobari, 2010). Spaza shops are one type of informal enterprise found in most informal settlements. The problem with these informal enterprises is the lack of financial infrastructure. Microenterprises generally only accept cash, which makes them attractive targets for criminals (Bear, 2005). The risk of being mugged makes carrying cash extremely dangerous. Yet thirteen million economically active people in South Africa do not have bank accounts and limited access to financial services (How We Made It In Africa, 2010). This can be accounted to the lack of access to financial services and high banking charges. High crime rates are a significant concern in informal settlements; therefore, there is a need for alternative cashless payment options to be developed that are both easily available and cost effective.
7
Currently the most popular form of cashless transactions is with the use of debit or credit cards. The problem with these is that they require the customer to have a bank account and the merchant to have a credit card terminal, which is specialized piece of hardware that can scan the magnetic strip of a bankcard. The merchant can then enter the transaction amount and as a form of security the customer can be required to enter a pin number to authenticate the card. The transaction is then communicated with the banking authority over a telephone line or in the case of mobile units the use of cellular or satellite networks. Currently these machines are extremely costly and can be difficult to operate. A single machine can cost between US$350 – US700 and the cost per transaction is also expensive this normally a percentage of the total transaction amount. It varies between 2-‐3%. Therefore they are not a suitable option for informal enterprises because it is not a financially feasible solution. The majority of the people in informal settlements don’t need the majority of the features a bank account offers. They only require a safer replacement for carrying cash. With South African laws it is not easy to open a bank account. FICA (Financial intelligence Centre Act) requires that any person wishing to open a bank account needs a valid South African Identity book and a proof of residence [39]. With many people living in informal dwellings, proving their residence is difficult. A bank account can only be opened at a bank’s branch, which due the lack of banks in informal settlements can require long travelling times. Currently there are alternative mobile payments systems that have been developed to over come these issues they will be discussed in the follow chapter. To overcome this regulation the system will act as a gift card and not a bank account. It will therefore not need to meet the FICA regulations. In this paper the feasibility of a new mobile cashless payments system will be evaluated and compared against current systems. The new system will utilize a different communication technique and designed with cost of communication and ease of use in mind. The system will be broken up into 2 parts the PaymentPortal server and the MyPay smart phone application. The aim is to create an easy to use low cost and secure mobile payments system that can be used in the townships of South Africa. The emphasis will be on transmission costs and cross platform expandability. The system will allow two forms of transactions Peer-‐2-‐Peer and payment of good or services at a merchant. The system will need to be as robust as current offerings and be able to handle large volumes all while staying secure. All sensitive data will need to be encrypted at all times to protect the customer. It will need to be established if a mobile phone is powerful enough to process a card based payment system with sufficient encryption? Is a mobile networks provide a fast enough communication channel to process payments within an acceptable length of time?
8
2 Background Chapter 2.1 Overview of Research The main objective of this chapter is to review current techniques and available systems and establish the requirements of a new system. This section will also explain the context of people that the project is aimed at and their need for such a system. Section 2.2 will focus on problems faced with current cash-‐based transactions to help establish why there is a need for a new system. Current mobile cashless payments systems will be reviewed and evaluated to establish where they fall short and where they can be improved. With all mobile payments systems, a method of communication is required. In the majority of these cases the communication needs to take place between the phone and the central banking authority. These different communication techniques will be reviewed and evaluated based on their cost and reliability. A mobile payments system needs to identify and authenticate a customer to the banking authority. This is either done using the customers’ mobile number or unique username and in some cases a PIN code. Based on the research conducted below on current systems and techniques a new mobile payments system will be designed. The new system will need to improve on current systems to offer a safer and more cost effect alternative.
2.2 Current Mobile Cash Providers At the 2008 Mobile Money Summit it was revealed that there were 120 Mobile Payment Services operating worldwide this was double the number in 2007. [15] One of the most successful mobile payment systems is M-‐PESA run in Kenya by Safaricom, which is Kenya’s largest mobile network provider. [16] The following are examples of mobile payment platforms that offer P2P cashless transactions with their focus being on developing countries and low-‐income users. 2.2.1 M-‐PESA (Kenya) M-‐PESA is based on SIM Application Toolkit and uses mainly SMS communication as the service bearer [15]. M-‐PESA allows the user to use his/her mobile phone to move money quickly, securely and over great distances, directly to another user’s mobile phone. There is no need for the user to have a bank account; they only need to be registered with the cellphone provider (in this case Safaricom). Within one year of rolling out the service in Kenya, nearly 2 million users had registered. M-‐PESA works by a user depositing money into their M-‐PESA account at any Sarfaricom Airtime dealer. The user then sends an SMS to an M-‐PESA dedicated number with the receipt’s details and the amount. In short, M-‐PESA has made it possible for many small shops all over Kenya to order supplies and make payments using their cellphone. [15] Some shortcomings of M-‐PESA are the cost per transaction of R2.45 plus the cost of an SMS. SMS technology is not an optimal method of making transactions due to there being no encryption of the message and therefore all transactions are saved on the mobile phone in the sent items. This can be seen, as a security flaw. Furthermore, there is no form of authentication. The only form of authentication M-‐PESA uses is the user’s mobile phone number. Therefore, if the user’s phone is stolen, then the thief can transfer all the money out the user’s account without the need of any personal information about the user. Another problem with SMS based transactions is that an SMS can take up to several days to be delivered and there is no instant notification that the transaction was successful. A cellular provider does also not guaranty that an SMS will be delivered within a certain time frame. An SMS also requires the user to know the text commands needed to complete a transaction.
9
The M-‐PESA system was one of the first mobile payments systems designed for a lower income market. And therefore it has worked well in most parts of Africa but has had limited success in South Africa. One of the reasons for this limited success in South Africa can be due to the high transaction cost. This is due to the communication channel being used. An SMS is very expensive and therefore any new system will need to find a more cost effective alternative. 2.2.2 FNB eWallet FNB (First National Bank) eWallet allows an FNB customer to send money to anyone with a valid South African mobile number. The service is currently only available in South Africa. The recipient does not need a bank account to receive cash. Once a recipient receives cash they can either send the money to another person or withdraw the money from an FNB ATM without the need of a bankcard. Furthermore, using an ATM, they can check their eWallet balance or buy airtime. The cost to send money is R8 to send up to R1000. The receipt then gets a free withdrawal. Currently an eWallet has a maximum balance of R1000.00. There are three methods of sending money either using Online Banking or at an FNB ATM or with the use of USSD (which is not available on all mobile networks in South Africa). As of October 2011, R1bn had been sent to eWallets since its launch two years prior. FNB has created 700 000 eWallet’s accounts since its launch. Currently R3m is sent to eWallets daily in South Africa. One of the problems with FNB’s eWallet is the lack of using your money in your eWallet. Currently no retailers accept eWallets as a form of payment. It therefore requires the recipient to locate an FNB ATM in order to withdraw the money. An eWallet suffers from the same problem as M-‐PESA with the use of SMS; they improved on M-‐PESA by offering alternative communication options. One of the features that worked with the FNB eWallet is the fact that the recipient does not need an eWallet to receive money. If the customer is new then a new eWallet will be registered for them. This feature will be carried over to the new proposed system. But the limitation that you can only use your eWallet in two ways is a major limitation to this system. Therefore any new system will need to have multiple methods that a customer can use their mobile wallet to make transactions. This can only be done if multiple retailers and merchants adopt the new system.
2.3 Methods of conducting mobile payments In the following section current mobile payment techniques will be reviewed. The techniques discussed below provide examples of how users can be identified and then how a transaction can be communicated to a banking authority for processing. One of these techniques is SMS, which has already been discussed in Section 2.3. 2.3.1 USSD USSD (Unstructured Supplementary Service Data) is a method of communicating between a mobile phone and service provider. Unlike SMS a USSD message creates a real time connection between the phone and service. Thus giving instant notification on the progress of a transaction. USSD uses the mobile number to identify the user and can take a PIN code as a parameter to authenticate the session. USSD provided a two-‐way text based exchange of data. The problem with USSD is that not all mobile phone providers make it accessible to external services. The most common use for USSD that most users will be familiar with is when a pre-‐paid users checks their balance by dialing *121*1#. Due to the fact that not all mobile networks make the USSD channel available this is not a suitable solution to the communication problem. It is also not a cost effective solution
10
with each transaction costing at least 20cents. The aim is to get the communication cost of a transaction to around 1cents a transaction. 2.3.2 RFID One method of processing a transaction on mobile a device is with the use of Near-‐Field Communication (NFC), which is based on Radio-‐Frequency IDentification (RFID)[4]. An RFID chip would need to be included in the mobile device. One of the biggest advantages of RFID is that because the two devices communicate with each other to do a transaction there is no need for a 3rd party back-‐end payment server to complete the transaction. Therefore, it makes it possible to make payments in areas with limited infrastructure available [5]. The two devices are able to identify and authenticate each other. The personal details and current electronic cash balance of the users are stored on his/hers mobile device. The mobile phone serves as a wallet and only when the RFID comes into contact with another RFID or RFID reader will the transaction be made. Because the payment can only be done in person, it provides a level of authentication because the users are able to see whom they are paying. An RFID chip only works when the distance between two RFID enabled phones is less than 30cm. RFID chips have high power consumption and therefore result in reduced battery life they also add an addition cost to the mobile phone. It’s a combination of these factors that have prevented RFID chips been included in all mobile phones. RFID enabled mobile phones are more expensive than non-‐enabled mobile phones. The cheapest RFID enabled mobile phone is made by Gentag and sells for US$119[20]. The high cost of the hardware and lack of wide spread adoption of this technology. RFID does not provide a suitable solution to the communication problem. 2.3.3 Bluetooth Bluetooth offers a cost-‐neutral form of communicating between mobile devices. It has sufficient bandwidth and is supported by a large number of mobile phones [4]. It therefore seems the perfect choice to implement wireless cashless payments on mobile device. It was first introduced in 1990 and since then has been through many phases to increase bandwidth and security. One of the downsides of Bluetooth is it has several security risks associated with it. The connection between devices can be eavesdropped and changed. It also does not include a unique method of authenticating communication partners in the Bluetooth transmission protocol. For this reason their needs to be a form of encryption and the two devices need to make use of a share symmetric key. When version 2.1 was introduced it included Enhances Data Rate (EDR) [8], which provided a more sure form of authentication and secure pairing of devices. The latest Bluetooth version is version 4, which includes built-‐in symmetric encryption using 128bit AES [9]. Unlike the RFID method, this method still makes use of a 3rd party financial institution and therefore needs to have a data connection in order to process payments. The client’s details are obtained from his/hers mobile device and encrypted before being sent to the merchant. The merchant then adds the value of the purchase and encrypts it with its symmetric key that is shared with the financial institution. The transaction is then sent to the financial institutions servers and the merchant never knows any person details about the client. They only get a response saying if the payment was successful or not.
11
Bluetooth hardware has been wide adopted and is common in smart phones. The process does not solve the communication problem. It can only be used to identify the customer. The transaction will still need to be communicated with a central payment server. 2.3.4 NSDT Near Sound Data Transfer (NSDT™) uses audio to transfer an electronic signature, one time password and cryptographic key to secure an electronic payment. [11] It works similar to RFID is the sense that it relies on both parties being in close proximity to each other. One of the main advantages of NSDT is that there is no need for any software downloads or hardware modifications unlike RFID. It requires the merchant to dial a number and enter the value of the transaction the client then dials a similar number and the two mobile phones are placed next to each other. An audio signal is then sent between the two devices to complete the payment process. Because it only used audio, it can be done using any cellphone and on any mobile network. Each transaction uses a unique audio message to authenticate both parties. NSDT provides a high level of security and protects the users privacy and therefore perfectly suited for retail. MobiCash is currently using this system in South Africa to conduct mobile payments [11,12]. NSDT requires both parties to make a phone call and therefore this can be very costly solution. 2.3.5 WAP WAP (Wireless Application Protocol) is a method of accessing information over a mobile wireless network. Most commonly used for web browsing on mobile devices. WAP provides mobile phone to access mobile web pages. Some banks offer a mobile version of their online banking website and thus allow customers to make payments using their mobile phone. The problem with WAP is that each page viewed needs to be downloaded onto the mobile phone. This can be time consuming and costly due to the high cost of mobile data. This form of communication offers the value for money. The process will need to be improved on to reduce the amount of data being sent and received. Because by keeping the amount of data transferred the cost of transaction can be kept to a minimum. 2.3.6 Overview of current methods In Table 1 below the five techniques above are compared based on cost and authentication. While RFID requires no communication cost, it requires specialized hardware. The cheapest technique is USSD but with its limited availability it restricts its customer base. NSDT is very secure but the cost of a phone call is expensive and the ambient noise of the location and interfere with the process. WAP offers both a secure and cost effective solution but the data needed to conduct a transaction being large this increase the price. Therefore an alternative data communication technique would seem the most cost effective solution.
12
USSD
RFID
NSDT
Bluetooth WAP
Hardware
No extra hardware is required
RFID chip, RFID reader
No extra hardware is needed other than mobile phone.
Bluetooth module
WAP enabled mobile phone
Hardware Costs Nothing just a
Gentag Mobile phone costs US$119 [20]
Nothing just a mobile phone
You can get a mobile phone with Bluetooth for under US$60.
Most modern mobile phones are WAP enabled
Communication Cost is billed per 20s at an Cost
There is no cost involved in connecting the two devices.
The process of making a payment requires a phone call that can be expensive.
There is no cost involved in connecting the two devices. There will be a data cost to communicate with server.
The communication is calculated per Mb received. Average cost of R2.00/Mb
Proximity therefore both sender and receiver need to be within 1m.
The server hands the authentication by sending audio signals between two devices.
Encryption is only used in version 4, which is not widely used.
The customer can login with username and password much like a website
Can make payment without contacting 3rd party payment server.
Needs to phone server to make payment.
A server is needed to process the payment between the two parties
The WAP connection is with the 3rd Party server
mobile phone
average price of R0.21/20sec
Authentication
USSD can accept PIN codes as a form of authentication
3rd Party USSD is to a Payment Server service provider’s server.
Table 2 Comparison of different technologies used for mobile payments
13
2.4 Types of Mobile Payments There are three forms of mobile payments currently in use. They allow for a customer to pay for goods or services using their mobile phone. The reason a mobile phone has become an enticing method of payment is its connectivity and availability. A mobile phone is always online and there can communicate with a central banking authority. The different forms of mobile payments will be discussed below. 2.4.1 Mobile at Point of Sale This is where the customer initiates the transaction, such as in MasterCard PayPass. PayPass is a form of NFC payments that utilises an RFID enabled bankcard. A PayPass enabled card can be swiped against a PayPass RFID receiver and the amount is deducted from their account. It is mainly used to pay for items where time taken is valuable; examples include bus stops and stadiums. In this type of payment, the mobile phone acts as a mobile wallet and the person’s money is connected to the mobile phone number. Other examples of this system are Google Wallet, ISIS, VISA and MasterCard.
Figure 1 MasterCard PayPass Terminal (Source: http://bit.ly/nzSVCs)
2.4.2 Mobile as Point of Sale Here, the mobile phone is used as a Point of Sale device to process credit card payments. In this form of payment, the merchant controls the transaction. Examples of this are Square and Verifone. Verifone is one of the biggest credit card terminal manufacturers in the world and have recently developed a mobile application to process credit card transactions by manually entering the credit card details into the phone. Square makes use of a small card reader that plugs into the headphone jack of a smartphone that can be used to scan the magnetic strip of credit cards therefore turning a smartphone into a fully fledged credit card terminal. Square is a very innovative form of accepting mobile payments the only problem is the need for a specialized dongle.
Figure 2 Square Dongle (Source: http://bit.ly/f2280F)
14
2.4.3 Direct Carrier Billing This is when the user puts a purchase on the user’s mobile phone contract. Therefore, the payment is added to your bill. This is mainly used to purchase ringtones and games on mobile devices. It is also sometimes called “In App Purchases” – currently this is the most widely used form of mobile payments. It is also one of the oldest forms of mobile payments. One of its flaws is that the user is unaware of a purchase until they receive their bill at the end of the month. Many of these purchases run on a subscription basis and can be a nasty surprise when the user receives their bill at the end of the month. Companies offering this service are PaymentOne, Zong that is run by PayPal and Mopay. This sort of solution would not work in South Africa where majority of mobile phone users are not on contract. They use pre-‐paid airtime and therefore don’t receive monthly invoices.
2.5 Android Smart Phones The Android operating system was developed by the Open Handset Alliance led by Google. The aim is to offer an open source mobile phone operating system. Android was unveiled to the public on November 5, 2007 by Google. With the operating system being open source each handset manufacturer can optimize and customize the operating system for their handset. Android is written in Java and has an SDK allowing developers to create applications specially designed for mobile phones. There are currently over 300,000 apps available for Android in the Android Marketplace [21]. The Android platform is currently the best selling smartphone platform in the world and the fastest growing smartphone platform in the developing world [22,23]. In 2010 Huawei launched the Ideos, a $70 Android smart phone in Kenya. It sold over 350 000 units in the first six months. The reason for its success is that for $70 the specification provides a 2.8” touchscreen display, 3.2-‐megapixel camera, GPS and 3G/HSDPA connectivity [24]. Even at this low price the device still has 256MB of RAM and therefore capable of running the majority of the applications in the Android Marketplace. The people of Kenya cannot afford a computer, but for $70 they can get a smartphone that can do all the same tasks as a computer, while being portable and online. This device makes the perfect platform to develop a mobile payments system on. It meets all the requirements, low cost, easily available, high-‐speed connectivity and a camera. One single smart phone can therefore replace a $300 dollar credit card machine while also being able to conduct other business on the device. The Huawei Ideos runs on a 528MHz ARM processor and runs Android version 2.2 also know as Froyo [25]. For this reason whatever application is developed for the phone it will need to not be resource demanding. Therefore the encryption technique will need to be design efficiently. Each version of the Android OS released has new features and deprecates old features. Therefore when developing for an Android phone you need to develop for a specific version. In this case the application is being developed for version 2.2. Version 2.2 is currently the most popular version in use with over 45% of Android phones running it [26].
2.6 Storing data visually with use of 2D barcodes Few of the systems described are suited for shop owner in an informal settlement, as many of them need specialized hardware or require both customer and merchant to have a mobile phone. The method utilized in this project does not require the client to have a mobile phone. In order to process transactions without the need for special hardware an alternative method of storing and capturing the payment card data is needed.
15
We need to develop a method whereby data can be stored in plain sight and read with camera on any modern mobile phone, while still not revealing any information about the cardholder. Traditional 1D barcodes can only be scanned linearly, therefore they need to be scanned from left to right. 2D barcodes can be scanned in any orientation and thus make them faster to capture. There are also multiple types of 1D barcodes and therefore the application needs to process what type is being scanned.
Figure 3 The history of barcodes Source: [17]
For this reason the best solution for this application is the use of 2D barcodes. A 2D barcode is a two-‐dimensional way of storing information with the use of rectangles, dots and hexagons instead of the traditional parallel lines. There are many different forms of 2D barcodes yet the two most popular are QR (Quick Response) Codes and Data Matrix. In Figure 4, the progression and improvement in barcode design over the last 40 years. The amount of data stored in a barcode and complexity of the barcode has increased to a point where barcodes are being used for tasks never originally thought of. 2D barcodes utilize built in Error Detection And Correction (EDAC), therefore it does not matter if the whole code cannot be read or not the code can still be decoded. This error correction means that up to 25% of the barcode can be damaged and the barcode will still produce an accurate reading [27]. Another advantage of a 2D barcode is that if the barcode is damaged beyond the point where EDAC can be used then a fail response will be returned. A 2D barcode will never return a false response. The level of damage that a 2D barcode can handle can be seen in Figure 5.
16
Figure 4 2D Barcodes (Source: http://bit.ly/s0Auie)
In Table 2 three different types of storing information are compared. Magnetic strips are used to store information on current bankcards. RFID technology was discussed in section 2.5.1 as a form of making payments. With the third, 2D barcodes being proposed for this system. As can be seen from the table the identification time is on par with current systems and even faster than magnetic strips. The error rate is also a lot less than current systems. But the most important difference is the price to print. The RFID is the most expensive followed by the magnetic strip this is because both require special hardware. A 2D barcode is just printed onto a surface and therefore the only cost is that of the ink used. Information media Magnetic Strip RFID 2D barcodes Identification Speed 0.3-‐2sec 0.3-‐0.5sec 0.3-‐1sec Bit error rate Depends on life of Depends on the 1/1,000,000 magnetic media noise and angle Technical Advantage Portable and data is Quick and batch Quick and accurate rewritable processing Print Cost Intermediate Very high Very low Table 2 Comparison between 2D barcode and other automatic identification techniques (Source: http://bit.ly/nJi5IP)
2.6.1 QR Codes A QR Code is a two-‐dimensional symbol that can store 100 times more data than a linear barcode, as shown in Figure 5 below. Denso invented QR Codes in 1994; which were initially designed for use in the automotive industry to control the production of parts [17]. They are superior to linear bar codes because they add a second dimension and therefore hold more data. Denso released the patent into public domain and therefore QR Codes can be freely used by anyone and for any purpose. QR Codes can store a maximum of 4,296 alphanumeric characters; they have also been designed with high-‐speed reading in mind, meaning that they can be decoded extremely quickly. The size and complexity of a QR code depends on the amount of data being encoded. Yet the more data encoded the more complex the code becomes and therefore slower it takes to decode.
17
Figure 5 Examples of QR Code and Data Matrix
2.6.2 Data Matrix A Data Matrix barcode is made up of black and white cells arranged in a square or rectangular pattern. They look similar to QR Codes and function in a similar way they also contain error correction codes and can therefore be read even if partially damaged. A Data Matrix code can only store 2,325 alphanumeric characters and varies from 8x8 to 144x144 pixels. A Data Matrix is scalable and can be printed as tiny as 300 micrometers. They are therefore most commonly found laser etched onto electronic components. They are used to store the components serial number that can be automatically scanned and monitored during the production process. The patent for Data Matrix codes has expired and thus making the use of them free to anyone. 2.6.3 Choosing an optimal 2D Barcode Testing will need to be conducted on the two different barcode formats discussed in section 2.7.1 and 2.7.2 to establish which of the barcodes is best suited for a mobile payments system. Different size barcodes with varying data encoded will be generated. They will then be scanned with a mobile phone and the time taken to decode will be compared. Also the easy of capture will need to be taken into account. These tests will be used to establish which of the two codes is best suited and the optimal size and amount of data encoded can be established.
18
3 Design Chapter 3.1 Aim of proposed system The aim of the project is to evaluate the feasibility of a cashless mobile payment system developed on an Android Smartphone. A cashless transaction is a method of paying for a service or produce without the use of physical cash. Yet the system needs to be safer and more efficient that traditional cash based payment systems. Therefore transactions will need to be completed faster, or in the same amount of time, compared to a traditional system. The new system will be safer, not least of all by removing the need for users to carry physical cash. But by introducing connectivity to the process will introduce new security flaws. Therefore, just like any other financial system, all sensitive data will need to be encrypted and the communication channel will need to be protected to prevent the transaction details being revealed or subject to fraud. The security of the system will need to be compared again similar systems and payment methods. The aim is also to make the process of paying for items cost-‐effective. Therefore, the actual cost to conduct a payment will need to be kept to a minimum. In short, whatever communication channel is used it will need to be cheaper and safer than current systems discussed in chapter 2. The project will incorporate three of the payment types discussed in section 2.5. The system will allow: • a merchant to initiate a payment • a client to send money to a merchant • a client to send money to another user. The reason for designing a system to cater for all types of transactions is so that it can appeal to a greater customer base. It therefore allows more people to make use of the system even if they don’t have a mobile phone. There are currently many mobile payments systems available worldwide but not many have been designed for low-‐income rural users. M-‐PESA and eWallet have tried with some success to implement a mobile payments system in Africa yet one of its shortcomings can be seen as the cost of a transaction. M-‐PESA requires the user to send an SMS to conduct a transaction. This form of communication can become costly if doing multiple transactions a day. Therefore this option would not viable for a Spaza shop owners. A customer is not going to want to spend R2.50 for a transaction if paying for their shopping which could be as little as R10.00. On the other hand FNB’s eWallet does not allow for the recipient of the money to use his/her eWallet at a merchant to pay for goods. They can only withdraw the cash at an FNB ATM or sent to another eWallet. These factors identify the need for a new mobile payments system that uses an encrypted data connection to process a transaction. The cost of an SMS is between 45c-‐65c while it cost less than 1c to send the same amount of data using a data connection. Most modern mobile phones can connect to the Internet over either EDGE or 3G, as can our target handset, the IDEOS. Even with mobile phone usage in the developing world growing, there are still some people who don’t have smart phones. Therefore a mobile payments system also needs to cater for people without smart phones by allowing a merchant to receive payments from a customer
19
by scanning the merchants’ unique barcode. In the case of a customer not having a mobile phone they can purchase a printed card with a unique barcode from a merchant. They can then load money onto the card similar to the way gift cards work. There is no need for the customer to have a bank account. When they register for a card a unique account number will be generated. A new user can be added to the system in one of two ways. Either they purchase a printed card with a unique barcode from a merchant. Or have a download link to their new card sent to their mobile phone via SMS.
3.2 Scenarios Below are scenarios that the PaymentPortal service will need to be able to handle. These scenarios can be seen as features that will need to be implemented in order to make a successful mobile payments system. 3.2.1 Registering new merchant When a new merchant opens the mobile application for the first time they will need to register an account. They will need to complete the registration form and enter their current bank account number/ PAN. Once a merchant has registered they will have a username and password that will allow them to process payments.
Figure 6 Register New Merchant Use-‐Case
3.2.2 Adding new card A new user can register a new card at a merchant by either scanning the barcode of a printed card or having a card sent to them via SMS. The user will need to provide their name, surname and mobile number in order to register a new card. There is an option to enter a current credit card number when registering a new card. This will then link your PaymentPortal card to your current bank account. The credit card number will be stored securely in the database to protect the user from fraud. Once a card is registered the new 4-‐ digit PIN code will be sent to the new customers mobile phone.
20
Figure 7 Add New Card Use-‐Case
3.2.3 Make Payment This is when a customer makes a payment for a purchase at a merchant. This transaction will be merchant initiated and be conducted using the merchants mobile phone. The merchant will scan the customer’s card and then enter the purchase amount. The customer will then need to enter their 4-‐digit PIN and the payment details will be sent to the server for processing. The server will respond with if the transaction was successful or not. The customer will then receive an SMS to notify them of the transaction.
Figure 8 Make Purchase Use-‐Case
21
3.2.4 Recharge card Due the legal regulations of South Africa the cards will act a gift cards, therefore allowing customers to load money onto the card. The money loaded can then be used at any registered merchant. For a customer to load more money onto their PaymentPortal card they will need to go to a merchant to recharge the card. The merchant will act like a deposit terminal they will take the cash and then money will be transferred from the merchants’ bank account to the customer’s card. The merchant will scan the customer’s card and then enter the recharge amount. Once the recharge has been complete the customer will receive an SMS notifying them of the transaction.
Figure 9 Recharge Card Use-‐Case
3.2.5 P2P payments This is when a user wants to make a person-‐to-‐person transfer. The sender will scan their PaymentPortal card and enter their pin. They will then scan the card of the receiver and the amount to be sent. The recipient then enters their pin code, it still needs to be established if the recipient should need to enter their PIN as they are just receiving money. There will also be an option so that if the recipient does not have a card then one can be created and the card details sent to their mobile phone.
22
Figure 10 P2P Payment Use-‐Case
3.2.6 Reset PIN Should a customer forget their PIN code they can go to any registered merchant to have it reset. The merchant will scan their PaymentPortal card and a new PIN code will be generated and sent to the customers’ mobile phone via SMS.
Figure 11 Reset PIN Use-‐Case
23
3.3 Problems faced with implementing a Mobile Payments system There are many factors that are restricting the implementation of mobile payments systems in developing nations. One of the problems is each nation has its own financial regulations and these need to be adhered to. These regulations are in place to restrict money laundering and combating financial terrorism [10]. Virtual Wallets does not have the same status as cash, which is authorized and guaranteed by the government [19]. They only thing that a mobile payment provider can offer is the issuer’s promise to acknowledge the value. Therefore the designed system will be used as a either a gift card or allow a user to create a visual card connected to their current credit card. When registering a new card, the user will have the option to enter their credit card number or have an account number generated. If the account number is generated then the card will function as a gift card and therefore not liable to South Africa’s financial regulation.
3.4 Communication between mobile phones and central processing server Once a customer’s card has been scanned, the transaction will need to be sent to the PaymentPortal server for processing. In examples discussed above, the use of SMS is one of the most common methods of communication. While this works well, the cost of an SMS carries a very high premium and the time taken to deliver can vary depending on network traffic. Therefore an alternative method would be needed in order to make this a cost efficient and reliable mobile payments system. An SMS consists of 160 characters that equates to 140 bytes (1120 bits) of data. This is due to the fact that SMS only uses 7 bit characters and therefore 160 * 7 = 1120 bits. Currently an SMS costs between 25-‐60c depending if sent during peak hours or not. There are 1024 * 1024 (104 8576) bytes in a Mb (Megabyte). This makes the cost per Mb if sent using an SMS equate to R337 042.00 at an average cost of SMS of 45c. This compared to the cost of sending data on a mobile phone, which varies between R1.00 – R2.45 per Mb depending on the mobile phone provider. Therefore, the use of a data connection instead of SMS is the most cost effective method of communication the amount of data needed for a transaction will need to be kept to a minimum. An optimal solution would be to keep the data cost of a transaction to under 1c. The only way to do this is with the use of a data connection instead of SMS. During the implementation process the amount of data being sent and received will need to be kept to a minimum.
24
3.5 Overview of System The PaymentPortal system can be broken up into three parts the PaymentPortal Card, the PaymentPortal Server and the MyPay smart phone application. Each part will be discussed in detail in the following sections.
Figure 12 Overview of PaymentPortal System
3.5.1 PaymentPortal Card Currently bankcards use magnetic strips to store the client’s details such as PAN (Personal Account Number) and card type. They therefore require a magnetic card reader to capture their data. If a mobile phone was to be used to process card payments then an alternative method of capturing the clients details will be needed. A more visual method of capture is needed something that can utilize the phones built in camera. A 2D barcode is the most practical option as all that is need to capture the information is a camera and decoding software. The advantage of 2D barcodes is that they don’t give away any cards holders’ details without the software. The users details are not in plain text; instead they are encoded into an image. As established in Chapter 2 there are currently two popular forms of 2D barcodes, QR Codes and Data Matrix codes. During the implementation chapter testing will be conducted on the response time and amount of data encoded to establish which is better suited for this application. As more data is stored in a 2D barcode they become more complex and therefore become harder to scan.
Figure 13 QR Codes with varying complexity with amount of data encoded
25
A user will be able to purchase a printed PaymentPortal Card with a unique 2D barcode. The card will be free with whatever the user paying for the card being loaded onto the card at registration. When a card is activated its unique ID will be linked to a PAN (Personal Account Number) and assigned a unique 4 digit PIN that will be sent to the user via SMS. A second method of getting a PaymentPortal Card is to have the barcode sent to your mobile phone as a URL link that can be used to download an image of your code. Your code can then be saved to your mobile phone and displayed when making a purchase. Thus making your mobile phone your credit card that can display your unique PaymentPortal card when making purchases using the MyPay client. 3.5.2 PaymentPortal Web Service As discussed in section 3.3, in order to make the new system more cost effective than current systems, a data connection will need to be used. The mobile client will communicate with the server over either a socket connection or via HTTPS calls. The service will be written as an API allowing easy expansion over multiple mobile phone platforms. The server will contain a database of all the cards currently registered as well as the details of all registered merchants. The server will link a unique barcode to a PAN. The PAN is what all banks use as identifiers of accounts it makes sense to keep this method so that it can easily be implemented with a current bank system. The PaymentPortal system was originally designed to connect to an actual banking system. The banking software was going to be provided by S1 Corporation. S1 provides financial software to 13 of the top 15 banks in Sub-‐Saharan Africa and as well as customers based in rest of the world. They are the second biggest financial software company in the world with over 3000 clients worldwide. During a meeting with the development team at S1 it was established that it takes roughly six weeks for their technicians to write a new driver to communicate with their software. It therefore become out of scope of this project to write a driver with no training in how their system works. So instead of a service provider, S1 were used as a consultant on how banking software works and what security measures need to be in place for a secure payments system. Instead of connecting to the S1 banking software a dummy bank database was set up to handle the banking aspect of the system. It would therefore store all the current balances of open accounts while still using common banking practices like PAN’s as primary keys. Thus allowing the integration into a banking system to be done without any changes needed the PaymentPortal design. A banking system needs a PAN and transaction amount to process transactions and this information is stored in current system in correct format. 3.5.3 MyPay Mobile Phone Client The last part of the PaymentPortal system is the MyPay smart phone application. The application will be used to interact with the PaymentPortal service. The aim is for the application to be run on an inexpensive mobile phone that has a colour screen, camera and an Internet connection. The application will have two interfaces; one for the merchant to login and process payments and registering new cards. The other option will allow one person to send money to another (Peer-‐to-‐Peer). When a customer wants to send money they scan their own card. They can then scan the recipients’ card or create a new account if the recipient does not already have on. If a new card is generated the cards details will be sent to the receiver via SMS with a link to where the user can download their new card. They can then use their new card to make purchases or send the money to another person similar to the eWallet system discussed in section 2.3.2.
26
3.6 Design Requirements There are multiple factors to consider when designing a mobile payments platform. These requirements will need to meet in order for the system to be seen as a success. Each will need to measured and compared against current systems to base the success of the new system. 3.6.1 Cost Efficient With the use of a data connection to process payments the cost per transaction can be reduced. But the amount of data needed to conduct a transactions needs to be kept to a minimum. The aim is that each transaction costs less than 1c which would be needed to make it a feasible option for a merchant to use on a daily basis. For example, if a merchant process 100 transactions a day it would only cost 50c per day or R15 a month. The amount of bytes of data per a transaction will need to be measured in order to establish the cost per transaction. 3.6.2 Secure Communication All data transferred between the mobile application and the PaymentPortal server needs to be encrypted to prevent any malicious attacks or eavesdropping. Currently SMS transmissions are not encrypted and therefore open to attack. This need for a layer of security will determine the communication protocol chosen due to the overhead of encrypting the data before transmission. The encryption will make use of public and privates keys and the level of encryption varies. The cost in performance versus the level of security will need to be tested to find a suitable solution. A solution that does not increase the processing time yet remains safe against attack. 3.6.3 Security The system will need to have the same, if not more security, for the customer and merchant than that provided by current systems. By using a 2D barcode to store client details instead of printing them on the card, the new visual card system will provide greater security than current bankcards. All client data and card numbers will be encoded in a barcode. Currently all that is needed to process a payment on a credit card is the card’s 16-‐digit PAN and the CVS security number on the back. With a PaymentPortal card, the account number becomes a lot bigger and is not stored in plain text requiring the barcode to be scanned in order to decode. 3.6.4 Authentication Just like any other card-‐based payment system, an authentication method is needed to increase the security of the system. Due to these security concerns each card will have a 4-‐ digit PIN code associated with it. This code will be generated when the card is activated and sent to the users mobile phone via SMS. A second layer of authentication can be set up for purchases over a certain amount can require a second OTP (one time pin) to be sent to the user similar to the way used with Internet banking. This will provide the same level of security as current card based systems and an improvement over current mobile systems like M-‐PESA.
27
3.6.5 Notifications The PaymentPortal server will be required to send notifications to users. The best channel for this would be SMS so a method of sending SMS’s will need to be found. A user will receive a notification for the following actions. • Created new card o Notifying the user with a link to where their new PaymentPortal card can be downloaded and the cards corresponding PIN code and current balance. • Resetting of PIN o When the user requests a new PIN, a 4-‐digit PIN will be generated and sent to the users mobile phone. • Deposit Notification o When a users receives money into their account they will receive an SMS notification with the amount deposited and current balance. • Payment Notification o When the user makes a payment at a merchant they will receive an SMS notification with the payment amount and current balance. 3.6.6 Open-‐Platform The current smart phone market is very fragmented. There are currently many different platforms available each running their own operating system and own set of applications. For this project just an Android client will be developed, but the aim is to make the system easily extendable to other platforms. Each platform has their own SDK and programming language and therefore the method of communicating with the servers will need to take this into account. 3.6.7 Response Times The time taken to complete transactions needs to be sufficiently responsive to prevent a customer become irritated by the amount of time it takes for a payment to get approved. The time taken should be comparable to a customer using any other form of payment. In a cash based transaction the money needs to be counted and then the correct change needs to be calculated and returned to the customer. This will take a few seconds to conduct and therefore the new system should be on par with this sort of processing time. The mobile phone connectivity will affect the processing time with an EDGE connection taking longer than a 3G/HSDPA connection; how much longer will need to be established. 3.6.8 Ease of Use The mobile phone application will need to be easy to use with it being aimed at users with very little computer literacy. The aim is therefore to keep it as simple and minimalistic as possible. The amount of options on each screen needs to be carefully designed to not overly complicate a transaction process. The number of screens needed to complete a transaction will be kept to a minimum.
28
4 Implementation Chapter 4.1 Layout of project As discussed in the design chapter the project is broken up into three parts. Each part was developed individually. First the PaymentPortal card was designed and the type of barcode and data encoded was finalized. Once the card layout had been decided upon the PaymentPortal server was developed. And finally the Android MyPay client was created to demonstrate the system.
4.2 The PaymentPortal Card The PaymentPortal Card works much like a normal bankcard. When a customer wishes to make a payment using their card they present it to the merchant who can then scan it using the MyPay application. The exact layout and design process will be discussed in the follow sections. 4.2.1 Choosing 2D Barcodes As discussed in Section 2.7 there are two main types of 2D barcodes. The 2D barcode will be used to store a customer’s PaymentPortal identifier. These barcodes will be printed on cards or downloaded on a customer’s mobile phone. The data encoded will be similar to what is stored on the magnetic strip of bankcards. To decide which barcode is best suited for this task each type was tested at different sizes and with different amounts of data encoded. Online 2D barcode generators were used to create the barcodes for testing. Four different graphs were encoded. All contained strings of varying length 12,45,200 and 425 characters in length. The barcodes were then printed onto paper and scanned using an Android smartphone and the Barcode Scanner application. The barcode test sheet used for the testing can be found in Appendix. The time taken to decode and capture a barcode was recorded across the various barcodes. The results were then compared to find out which barcode was the optimal solution. And what was the max amount of characters that could be encoded without too much delay in decoding. Table 3 contains the results from the barcode scanning tests. QR Code Data Matrix 12 Characters 0.5 seconds 0.7 seconds 45 Characters 0.6 seconds 0.9 seconds 200 Characters 3.0 seconds 4.0 seconds 425 Characters Not able to read Not able to read Table 3 Barcode scanning results
From the testing it was established that the QR Code was the fastest to decode but not much faster than Data Matrix. The only time the QR Code was much fast was when the code being scanned was at an angle. Scanning a Data Matrix at a angle was much slower than if scanned squarely. The other reason QR Codes were chosen over Data Matrix was that the Google Graph API could be used to generate QR Codes. There was not a similar solution to generate Data Matrix. The Android application did take a little longer than desired to recognize the QR Code with the 200 characters. The barcodes were very detailed and therefore hard to decode. The same tests were then conducted with just 100 characters and the time taken was drastically reduced. It was also established that the Scanner worked faster when the barcode was not the full screen and rather a little smaller. Therefore the barcode size
29
printed on the card could be made smaller. The optimal size was 140x140 pixels. Which can quite easily fit on a credit card as seen in Figure 14 below.
Figure 14 Example of Printed MyPay Card
4.2.2 Generating Unique Identifiers (QrID) Now that the barcode type had been selected and it had been established that up to 100 characters can be encoded a unique identifier known as the QrID needed to be created. This code should not reveal any details about the cardholder but can be used by the database to identify the card being scanned. It was first thought to use the hash of a random number but this would not be unique enough and duplicates could be generated. The server would need to generate a QrID automatically when a new card was created having to check if the QrID already exists would be time consuming and not practical. Therefore a random unique identifier is needed the best way to generate a completely random value in Java is with the use of UUID (Universally Unique Identifier). A UUID is made up of a 128-‐bit number comprised of 32 hexadecimal digits split into 5 groups; e.g. “465e8400-‐e29b-‐41d4-‐a816-‐ 446645440000”. A UUID can be generated in Java by using the java.util.UUID class [28]. A UUID is not completely unique but the possibility of duplicate UUIDs being created is extremely low – if you generated 1 billion UUIDs every second for the next century there would only be a 50% chance of a single duplicate. Figure 15 is the probability equation for duplicate UUID being generated. The QrID is generated using the UUID Java class to create a random unique identifier.
Figure 15 Calculating duplicate UUID probabilities
30
4.2.3 Generating QR Codes Now that the format of the QrID has been established the next step is to encode the QrID in QR Codes. This would need to be done on in real-‐time and the QR Code will need to sent to a user via SMS. The Google Graph API is the best way to generate QR Codes and the link can just be sent to the user’s phone and they can download the code using their mobile phone browser. The Graph API is a URL call that takes three parameters size, data and type of graph. And example of a Google Graph API call can be seen in Figure 16. http://chart.apis.google.com/chart?chs=140x140&c ht=qr&chl=465e8400-e29b-41d4-a816-446645440000 Figure 16 Google Graph API Example
4.3 PaymentPortal Server Each mobile phone application would need to communicate with a central PaymentPortal server to process payments. The different parts of the PaymentPortal Server will be discussed below. 4.3.1 Communication Protocol Used With this being a mobile payments system it would be required to support almost all modern smart phones. Many of the different smartphones run different operating systems and are written in different programming languages. For this prototype Android was chosen due to its good SDK and low cost of phone. Because of the multiple platforms a common communication method is needed that would not require a client side being written for each platform. For this reason it was decided to use HTTP calls instead of using a socket connection. All smart phones that have an SDK have HTTP libraries and can therefore easy implement the communication with the PaymentPortal server. The problem with HTTP is that the data sent and received is not encrypted and therefore vulnerable to attack. For this reason HTTP Secure, also known as HTTPS, would need to be used instead because it encrypts all data before sending. HTTPS combines HTTP with the SSL/TLS protocol. TLS (Transport Layer Security) and its precursor SSL (Secure Socket Layer) are both cryptographic protocols that provide security for data sent over the Internet. They encrypt the data above the Transport Layer using asymmetric encryption. This will be discussed in more detail in section 4.3.5. 4.3.2 Java Servlets There are multiple different ways of communication with a web server. The two most common are Java servlets and CGI (Common Gateway Interface). CGI played an important part in the development of the Internet. A Servlet is a Java class used to extend the abilities of web-‐based applications. Servlets run solely inside a Java Runtime Environment [29]. They are accessed via a request-‐response programming model with the client sending a request to the server with parameters and the server responding. The parameters can either be sent via URL parameters or as an HTML form. The URL parameters are not encrypted by HTTPS and therefore the only option is to use an HTML form and HTTPS post requests to send the given parameters. Servlets excel in five areas when compared to CGI. The five areas are [30]: 1. Cross Platform: Servlets are written in Java and run in the JRE (Java Runtime Environment) thus meaning they can be written on one platform and run in a different without needed to change the code.
31
2. Performance: Java programs have been known to be slow due to the interpreted nature of Java. This is due to the initialization time taken when running a program for the first time. Java servlets take care of this by initializing the first time the servlet is called. It then remains in memory until the server times out or is shutdown. For each request a servlet receives, the servlet creates a new thread. This is much faster than CGI that creates a new process for each new request. 3. Extensibility: Java is a very robust object orientated programming language that can be extended into new objects. Servlets are written in Java and therefore inherit all these aspects thus making them extendable from existing classes and can be tailored to any situation. 4. Safety: Java has built-‐in memory management and exception handling and Java servlets inherit these features and provide a very robust and powerful web service. 5. Secure: Java servlets utilize server side computing and therefore benefit from the security provided by the web server. They also utilize the Java Security Manager. From the five aspects above it was decided that Java servlets would be best suited for the PaymentPortal web application. In order to run a servlet on a web server, a servlet container is needed. This will manage the mapping of URL calls to the corresponding servlet and manage the lifecycle of a servlet. The Servlet Container used for PaymentPortal was Apache Tomcat V6.0. Tomcat is a cross platform Java HTTP web server environment used to run Java code it was developed by the Apache Software Foundation. Their needs to be a servlet for each type of request sent from the mobile application. It was also decided to write the servlets as an API therefore allowing 3rd parties to write mobile clients. Therefore a servlet was written to handle each of the scenarios mentioned in Section 3.2. The input parameters for each servlet have been outlined in the appendix. Normally a servlet’s response is in the form of HTML. Yet for this application the amount of data being sent and received needed to be kept to a minimum in order to keep the cost of transmission to a minimum. Therefore an alternative response format was needed. It was decided to use JSON (JavaScript Object Notation) it is a lightweight text-‐based data interchange. It has the benefit of being human readable and not wasted data on wrapping the message like XML. JSON messages maintain the structure of data and are an alternative to XML. Reading JSON Objects on the client side is much faster due to its serialized structure. JSON supports many data types including String, Boolean, Array and even Objects. A Servlet for each scenario was written before the mobile application was complete and therefore a method to test them was needed. As a servlet was created, a corresponding HTML page was also created that contained a form that took in all the parameters needed for the corresponding servlet. This allowed the servlet’s functions to be tested from a Web Browser even without the mobile client application. This decreased the development time because the time taken to test and implement changes was less than if done from the mobile phone application. The Tomcat server was originally run from a Lab PC at UCT and could be tested using “localhost” or via its IP address. This caused many problems due to the lab PC being behind the UCT firewall. The firewall blocked all income connections and therefore a request needed to be lodged to have port 8080 and 8443 opened. This allowed the Servlets to be access from a mobile phone.
32
4.3.3 Registering New PaymentPortal Card There are two ways to register a new PaymentPortal card. Either by purchasing a card at a merchant or if the recipient of money is receiving for the first time (then a new PaymentPortal card will be sent to the recipient’s mobile phone). If purchasing at a merchant, either a printed card can be scanned or a card can be generated. The user’s details are then sent to the PaymentPortal server and the details are entered into the database. For each new card a PAN (Primary Account Number) needs to be generated this is what a bank uses to identify its customers. It consists of a 16-‐digit number with the last number being a checksum value to verify the account number. This is the number seen on the front of credit cards as seen in figure 17.
Figure 17 Credit Card Example (Source: http://www.credit-‐cards.co.za/credit-‐cards/)
It was decided to use valid PANs thus allowing the system to one day be implemented with proper banking software. The 16-‐digit PAN is made up of a six-‐digit Issuer Identification Number – this is a unique number for the given bank and with the first value defining what type of card it is [31]. The numbers 4 and 5 are used for financial and banking cards. The following nine-‐digits are the individual account identifier with the final digit being a check digit calculated using the Luhn algorithm [32]. The Luhn algorithm is also know as the “modulus 10” algorithm as it checks to see if a sequence of numbers is mod 10. The algorithm is as follows: 1. Starting at the right most digit and moving left double every second digit. 2. Sum all the digits of the products meaning if doubled digit is 14 then 1+4=5. 3. Add the undoubled digits with the sums above. 4. If the total mod 10 is equal to 0 then the number is valid. 5. If not then what ever number is needed to make the sum mod 10 is the check sum value. PAN 4 9 9 2 7 3 9 8 7 1 x Double 4 18 9 4 7 6 9 16 7 2 x every 2nd digit Sum 64 + x values together Figure 18 Luhn Algorithm Example
33
As seen in the example above, the checksum value “x is 6” giving a total of 70 which is modulo 10. This algorithm had to be used when generating the PAN in order to generate valid PANs. The next number that needed to be generated was the 4-‐digit PIN code. Generating four digits between 0-‐9 and then placing them in a sequence did this. The PIN code was then hashed with a unique value and stored in the database. The PAN was then added to the fake bank database with the opening balance that had either been loaded by a merchant or sent from another PaymentPortal card. Once the card details have been added to the system a notification SMS is sent to the new cardholder with their unique PIN code and the current balance. If the QrID was generated then a link to where the new card can be downloaded is included in the SMS. 4.3.4 Processing Payment There are two types of payments, making a payment at a merchant using the merchant’s terminal or by sending money from one card to another. The first type takes the merchant’s id and the payer’s QrID, PIN code and the amount. The entered PIN is checked to see if it only contains 4-‐digits. If not then the payment is declined. A hash of the entered PIN code is then checked against the hash of the PIN associated with the given QrID. If they match then the PAN for the card can be retrieved and a balance request is done to see if the payer has sufficient fund to make the purchase. If there are sufficient funds then the money is removed from the payer and deposit into the merchants account. When conducting a P2P payment the QrID and PIN sender, the QrID of the receiver and the amount are sent to the server. First it is checked if the sender has sufficient funds. If so, then the sender’s PIN code is checked if it passes, then it is checked to see if the receivers QrID were received or if a new card needs to be generated. There is no need for the recipient to have its PIN code checked as they are just receiving money. It was thought to be a security risk to need the recipient to enter their PIN every time they receive money. Once a transfer is made an SMS is sent to the recipient to say that money has been deposit into their account. The amount deposit and the current balance are included in the SMS. When a payment is successful a JSON Object response is sent to the mobile client application. The payment process starts with deducting the money from the sender first if there is an error depositing the money into the recipient then the transaction needs to be reversed. The money is therefore deposit back into the senders account and a failed transaction response is sent to the mobile client application. 4.3.5 Server Security As with any financial system there needs to be security in place to protect the customers from fraud and attack. The security can be broken up into two categories the transmission of data and the storage of data. Both need to be encrypted in the sections below the method of encrypting this data will be discussed. 4.3.5.1 Encrypted communication (HTTPS) As discussed in Section 4.3.1 the communication protocol used is HTTPS. HTTPS uses SSL certificates to authenticate the server to the user. A SSL can be purchased from a trusted Certificate Authority (CA) that signs the certificate to say that the server is authenticated. Most modern web browsers have a list of trusted CAs, the browser then verifies the web sites certificate against the list of trusted CAs. HTTPS uses public-‐key encryption, which is
34
where a public and private key pair is generated. The public key is then shared with the public anyone can then encrypt a message using the public key and only the private key can be used to decrypt the cypher text. An SSL certificate also contains a public key that is used to set up the encrypted connection between the server and client [33]. The server can then decrypt the message using its private key. The encryption process can be seen in Figure 19.
Figure 19 Public-‐Key Encryption used in HTTPS communication (Source: http://bit.ly/u0DFS6)
A basic SSL certificate can cost anywhere from $49.99/year to $1499.99/year [34]. For the scope of this project where the SSL connection was only being used for testing the security and proof of design this cost could not be justified. Due to the high cost of SSL certificates it was decided to just use Java’s KeyGen Tool to create a public private key pair. When the certificate is added to the Tomcat’s properties would provide a self-‐signed SSL certificate. The only downside of this is that the browser gives a warning saying the certificate is not trusted this is not problem in the browser because you can select to trust it anyway. HTTPS uses many different levels of encryption the most commonly used for online banking is South Africa is RC4_128, with MD5 for message authentication and RSA as the key exchange mechanism. The encryption a website uses can be gathered in the Google Chrome browser by clicking on the green “HTTPS” the connection details will then be listed as seen in Figure 20. The reason for this being the most widely used method is due to the speed of encryption and decryption. There are many other encryption methods and these will be tested during the evaluation process to establish if the performance decrease is worth the extra security.
35
Figure 20 HTTPS Details for ABSA Online Banking
4.3.5.2 Encrypting sensitive data stored in database The communication is not the only place where encryption is needed. A set of guidelines has been set out by the PCI PA DSS (Payment Card Industry Payment Application Data Security Standards) to enhance the security of payment card data. Any payments platform needs to comply with the PCI PA DSS standards in order to be accepted by banks and other financial institutions [40]. One of their requirements is that all credit card information about a user be encrypted in the database and not stored in plain sight. MySQL offers a built in asynchronous encryption (AES) library that can be used to encrypt and decrypt data before being stored in a database. For this system only the PAN (Personal Account Number) will be encrypted in order to comply with PCI DSS. One of the requirements is that the key be stored on a separate server this would not be feasible for this project so the key was stored on the same server. MySQL only offers 128bit encryption so therefore this was the max that could be applied to the PAN. 4.3.5.3 Storing PIN Code and Login Passwords PaymentPortal has two methods of authenticating a user. A username and password is needed for a merchant to log in. The other method is when authenticating a customer’s PaymentPortal card they are required to enter a 4 digit PIN code that is associated with that card. A server should never store the actual password in its database; instead only a hash of the password should be stored. This prevents someone from finding out the user’s password, a problem then arises if two identical passwords are stored they will have the same hash and the password can then be know. A random value is therefore added to the password before hashing. This random value is called the salt. The salt is also stored in the database so that when checking a user’s login details, the salt can be added to password entered before being hashed and compared to the stored password. By adding a salt value
36
to a password its hash is completely unique and not even an Admin can guess the password. The password is also hashed 1000 times to increase the uniqueness of the hash. Because the actual password or PIN is never stored in the database if a user forgets their password they need to reset the password instead of retrieve their current one. A new password and SALT will then be generated and sent to the user via a notification. 4.3.5.4 Login and Checking Pin Servlets When checking a user’s login the input needs to be checked to see if it only contains alphanumeric characters. The reason this is done is to prevent malicious attacks on the database. By checking that the input is only alphanumeric the service can protect itself from SQLInjection attacks that would release details about the database. The input is also checked to make sure that valid input has been entered. If no password or username is entered then the login returns false. All SQLExceptions are caught and no details about the database or errors are revealed. When checking a pin code the input is checked to make sure its only contains 4-‐digits if anything else is input then check PIN will return false. 4.3.6 Notification System Many of the scenarios discussed in Section 3.2 require for the user to receive notifications via SMS. There are many ways of sending and SMS from an application. A company called Clickatell offers multiple API’s for sending and receiving an SMS. Clickatell was the first service to offer global SMS delivery service from a simple web interface [35]. Their API can be accessed via HTTP/S, SMTP, FTP, XML or SOAP connections. In order to interact with the Clickatell API you first need a username and API key. Registration is free on their website and once registered you can purchase SMS bundles with the smallest denomination being 400 SMS’s for R136.00. This works out to 34c a SMS; this cost gets less as bigger bundles are purchased. The API connection chosen to send the notifications was the HTTP connection as this was the simplest to implement in the JAVA Servlets. The HTTP URL can be seen in Figure 21. The URL takes 5 parameters: http://api.clickatell.com/http/sendmsg?user=xxxxx&password=xxxxx&api_id=xxxxx &to=448311234567 &text=Meet+me+at+home Figure 21 Clickatell URL Exmaple 1. Your Clickatell username 2. Your Clickatell password 3. Your API ID 4. The mobile number of the recipient 5. The message to be sent The mobile number can be in either international format, meaning it starts with the country code (South Africa is +27), or your Clickatell account can be set up to automatically convert to a specific country. The message being sent needs to be UTF-‐8 formatted to be sent via an HTTP request, meaning the string does not contain any spaces or punctuation marks. The URLConnection Java class is used to make the HTTP request. The response from the Clickatell server will be a specific id for that given request. The system is very responsive and most SMSs are received within seconds. One of the problems with sending SMS notifications is that a SMS is limited to 160 characters. Most of the notifications being sent are shorter than 160 characters but when sending the user a link to where the QrID barcode can be downloaded, the link is longer and will therefore need to be shortened.
37
There are many online websites that can shorten a URL but not many offer an API for an application to do this. Bit.ly is one of these websites and offers this feature for free. All that is need is to register on the site and get a username and API key. Then same as with the Clickatell API a simple URLConnection is used to send the HTTP request. Bit.ly will return a shortened URL. Here is an example of a shortened URL bit.ly/qyUZnu, which redirects you to www.paymentportal.co.za. The bit.ly URL can be seen in Figure 22 and it takes 4 parameters: http://api.bitly.com/v3/shorten?login=xxxxxxx&apiKey=xxxxxxxxx x&longUrl=xxxxx&format=txt Figure 22 Bit.ly HTTP API Example
1. 2. 3. 4.
Your bit.ly username Your bit.ly API key The long URL you wish to shorten And the format of the response.
Figure 23 SMS New Card Notification
Now that the download URL has been shortened, all notifications are less than 160 characters and can be sent over SMS. In Figure 23 an example of an SMS notification can be seen. This notification is for a new card: it contains a link to where the barcode can be downloaded, the current balance and the card’s unique 4-‐digit PIN. One of the problems with using external web services is that the server is running off a lab PC and therefore behind the UCT firewall that caused problems trying to access external websites. For this reason and alternative hosting platform was needed.
38
4.3.7 Moving PaymentPortal Server to Amazon EC2 It was decided that alternative web hosting would be needed due to the problem faced with having the server behind a firewall. The problem is that most web hosting plans don’t let you run a web application on them and therefore a virtual dedicated server would be needed. These are not cheap with the price starting at $30 a month. They then allow you to run your own software on the server. Amazon Web Services (AWS) offers a web service called EC2 (Elastic Compute Cloud) this allows you to run your own server in the cloud. AWS is a cost-‐effective, flexible and easy to use cloud-‐computing platform. What makes EC2 ideal for this project is that you can customize every aspect of instance and virtual server environment, to suit your needs. You can choose what Operating System you wish to run and install all the software that is needed for your web application. It offers all the same functions as a physical server but at a fraction of the cost. You can even select the hardware that you require for your instance. AWS can give you a static IP that can be used to access your EC2 instances. What makes it even better is that you can have a single IP for a web application, even if the application is running on multiple instances. AWS will manage the redirecting of requests to the difference instances depending on the resources available. A main feature of EC2 is its elasticity, meaning that as your web application grows in popularity more instances can be launched to handle the extra demand [36]. The capacity of your EC2 can be increased or decreased in minutes. It can even scale itself up and down depending on its needs. Administrators also have complete control of what is being run on each server. There are currently five EC2 locations where instances can be run. There are two in the US, on the east and west coast, one in Europe and two in Asia Pacific. For this project it was decided that the Europe region would be the best suited. This is because it’s the closest to South Africa and will therefore keep the latency cost to a minimum. The exact cost in latency will be evaluated during the evaluation process. AWS offers one year free access to their service allowing the user to run 1 instance with a max size of 10GB and 15GB of data transfer. This project will not require more than this. Even if the user goes over these limits the costs are very reasonable and only pay per unit used. The cost per hour of CPU time varies between $0.0.2-‐$2.10 pre hour depending on the resources being used. Data costs are also low with all incoming data being free and outgoing data costing between $0.05-‐$0.120 depending on the amount being used. Therefore as an example if your application requires 100 instances and consumes 1TB of data the total cost for the month will be less than $100 a month this same service would cost over $3000 if physical servers where hired and even more if they were purchased. This low starting cost makes EC2 the perfect solution for any Internet startup because of the low starting costs and the flexibility to increase capacity as the demand increases. The first step was to get an AMI (Amazon Machine Instance), which is a prebuilt virtual machine. For this project an Ubuntu 10.04 instance was chosen as this is what the application was being run on previously. The selected AMI can then be booted up and the necessary software installed. The software requirements to run a PaymentPortal server can be found in the appendix. Once the instance is setup and running the next step is to deploy the PaymentPortal application. Web applications can be packaged in a WAR (Web application ARchive) file that Tomcat can deploy and setup automatically. But before the
39
WAR can be deployed the MySQL script needs to run to create all the tables needed to run a PaymentPortal Server. 4.3.8 Paymentportal.co.za domain registration The default ports for Tomcat are 8080 and 8443 – these are not the default for a web server which are normally port 80 for HTTP and 443 for HTTPS. Changing Tomcat to use port 80 and 443 was causing problems with needing sudo permissions when starting the server. The solution to get around this was to edit the IPTables to redirect the port 80 incoming request to port 8080. The same was done with the HTTPS ports. This allowed the web application to be accessed from a web browser without entering the port. The domain paymentportal.co.za was purchased to make it easier to remember instead of the server’s IP address. Completing the form on “co.za” was all that was needed to complete the domain registration. The domain registration cost was R50 for one year. The PaymentPortal web application can be accessed via www.paymentportal.co.za.
4.4 Database design For storing all the PaymentPortal data a MySQL database was used. The database was changed many times as the system was designed, various fields changed and the variable types changed. The biggest change was with the security requirement that required certain information be encrypted. MySQL has a function that handles the encryption so the only change that needed to made was the PAN field type had to be changed to a “VarBinary”. The SQL script used to generate the database can be found in the appendix. The database consists of four tables seen in Figure 24. The credentials table stores the login details for the merchants’ login details. It has three fields: username, password and salt. The second table is the users’ table that contains all the details for each merchant. Each merchant is assigned a “client_id” that is an auto incremented value. The client_id does not need to be set: this is handled by the MySQL database when a new item is added. The third table is the cards table: this stores all the information for the PaymentPortal cards issued. Its primary key is the QrID; it also stores the hashed PIN code and salt associated with each card. The PAN associated with the QrID is also stored but is encrypted using the built in MySQL AES_ENCRYPT function to meet the PCI-‐DSS requirements. The last table is a fake bank database that stores PAN’s and the current balance for each account. The banking software used in a real world application of the PaymentPortal system would handle this database. There is a relationship between the users and bank table and the cards and bank table with both foreign keys being PAN. It can’t be displayed in figure 8 because in the users and cards table the PAN is encrypted.
40
Figure 24 SQL EER Diagram
4.5 MyPay Android Client To demonstrate the PaymentPortal system, a mobile phone application was developed. As discussed in Section 3.5.3 the chosen mobile platform for the prototype was Android version 2.2, due to its openness and availability of low cost phones. The user interface for the MyPay system would need to be simple so that people with relatively low computer literacy can use it. Therefore the user interface was designed to have as few buttons or options on each view as possible. The application was designed for the small screens of low cost mobile phones. The design of the mobile application went through many implementations as more features were added and adjusted. 4.5.1 Notifications Whenever a user sends a request to the PaymentPortal service a response is returned. Android has a feature called Toast that was used to display these server responses. A toast is a view containing a small string notification. The view when created floats over the application. It does not receive focus it is aimed to be unobtrusive. The time a toast appears is set when the toast is created. A single line is all that is needed to create a toast an example can be seen below. Toast.makeText(getApplicationContext(), Toast.LENGTH_SHORT).show();
"Toast
Message”,
Figure 25 Displaying a Toast message
41
Figure 26 Adding new card Toast response
The above function call takes three parameters the context, the message to be displayed and the duration the message needs to be displayed for. An example of a Toast message can be seen in Figure 26. 4.5.2 QR Scanning The application used to scan the barcodes in section 4.2.1 was Barcode Scanner, available as a free download in the Android Market Place [http://bit.ly/n3RDj7]. Android Intents allows one application to invoke another application from within MyPay. By parsing a set of parameters to let the Barcode Scanner know what type of barcode is being scanned, the application is then launched straight into the scanning view. When the QR Code has been captured, the response is sent back to the MyPay application. The user is not aware that a second application has been launched to conduct the scanning of the QR Code. The response is received and the results data extracted revealing the decoded contents of the QR Code. This feature made it extreme easy to incorporate the QR decoding into the MyPay application with little knowledge of how the Barcode Scanner application works. With one of the aims of the project to be cost effective the size of the MyPay application install file or APK was kept to a minimum.
42
4.5.3 User Interface Design This project is not an HCI (Human-‐Computer Interaction) project. The mobile application was only developed to prototype the idea. Even though this is not a HCI project the interface still needed to be user friendly for the evaluation process. The number of screens needed for the application was kept to a minimum. The layouts can be seen in figure 23. With the aim to keep the screens as simple as possible the launch screen has only 3 buttons Send Money, Login and Register. Login and Register are for merchants to gain access to the PaymentPortal system and Send Money is used to conduct a P2P money transfer. Keeping the minimalist design, only when the user selects to login are the Username and Password input boxes displayed. After running the application on the device for the first time was it revealed that due to the small screen, a label next to a textbox did not fit optimally. So an alternative method of describing a textbox was established. Android allows for a hint to be inserted into a textbox that, once selected, disappears. This feature was carried on throughout the whole MyPay application. Figure 27 demonstrates the two types of labels.
Figure 27 Label vs. Hint for Textbox
If the merchant does not have an account already they can register for an account by selecting the Register button on the start screen. They will then need to enter a username, password and other merchant details. One of the fields is a valid credit card number. They then hit submit if the username is available the account will be created. And the response will be displayed to the user via a toast notification. If the registration was successful the user will be automatically logged in and the home screen will be displayed. This process can be seen in Figure 28.
43
Figure 28 Start Screen Options
4.5.4 Send Money (P2P) Interface If the user selects the Send Money button on the start screen, the Barcode application will be launched and the person sending the money needs to scan their QrID. They will then be asked to enter their PIN code that corresponds with the QrID just scanned. It was decided to not check the PIN code until sending the actual send money request. This was done to speed up the process and keep the data used to a minimum – the aim was to make a cost effective mobile payments system and therefore there is no need for unnecessary server requests. The user will then have the option to send money or check balance. The screen flow can be seen in Figure 29.
44
Figure 29 Quick Pay (P2P) Screen Flow
4.5.4.1 Send Money Screen When the user selects to send money to another PaymentPortal card the user will then be presented with the send money screen. The user then enters the amount to be sent. The option is then to scan the recipient’s card or to create a card for the recipient if the user is new to the PaymentPortal system. If creating a card, the user can enter the details of the recipient. The card details are then sent to the recipient’s mobile phone via an SMS. The SMS will contain a download link to where the new PaymentPortal card can be downloaded and the card’s corresponding PIN code. There is no need for the recipient to enter their PIN code as they are just receiving money. The sender then selects to Send Money button once again the Barcode Scanner application will be launched this time to scan the recipients QrID if not creating a new card. Only now will a request be sent to the PaymentPortal server. The server will then process the transaction and return a response. The recipient will then receive an SMS to notify them that they have been sent money.
45
4.5.4.2 Check Balance Screen This feature was only added after the first round of expert feedback. One of the companies presented to requested that there be a method for a customer to check their current balance without going to a merchant. The check balance simply sends a request to the server with the sender’s QrID and PIN code that has already been captured. The response is displayed in the same format and screen layout as the merchant interface. It displays the cardholder’s name and current balance. 4.5.5 Merchant User Interface Once logged in, the user is presented with the home screen. All the features can be accessed via the main menu and the buttons automatically adjust to accommodate different screen sizes. The overview of the screen flow can be seen in Figure 25. When changing any screen in the MyPay application, Android Intents were used thus allowing the built in back button on the mobile device will work and return the user to the previous screen. The home screen consists of 5 buttons: • Add New Card • Query Balance • Buy Top-‐up • Make Purchase • Reset Pin All the buttons start with a verb based on the Microsoft Interface Guidelines [37]. It states that the labels on buttons “start with an imperative verb and clearly describe the action that the button performs”. A label should also never use ending punctuation. The buttons should be kept as short as possible but use enough text to describe the action sufficiently. It is also suggested that a direct object, i.e. a noun, be used directly after the verb. This is all done so that the user does not need to read anything else or do any unnecessary decision making when selecting the button. Therefore by following these guidelines it helps aid the users’ comprehension of the label.
46
Figure 30 Overview of Merchant interface layout
4.5.5.1 Add New Card Screen If the user selects the “Add New Card” button then a screen is displayed with textboxes for all the details required to process a new card. The first textbox is automatically selected to increase the speed of data capture and because the user may not know how to select a textbox. An onscreen keyboard is then displayed to the user. The keyboard layout changes depending on what type of input is required – a full keyboard if a string is required and just a number pad for when a mobile number textbox is selected. Figure 31 shows the different keyboard layouts used. This helps reduce the chance of incorrect data entry and improve usability. The soft keyboard contains a “next” button that changes the users focus onto the next textbox once again to help improve the users experience.
47
Figure 31 Onscreen Keyboard Layouts
The final two toggle switches are if the new customer already has a PAN or if one needs to be generated when the card is created. If the toggle switch is toggled, then a new textbox appears where the PAN can be entered. It was decided to hide this textbox unless needed to reduce the screen space occupied and also to keep all the textboxes visible on a single screen without the need for scrolling. The second toggle switch is if a QrID needs to be generated or if a printed PaymentPortal card is going to be scanned. If so, then when the merchant submits the new card application the Barcode Scanner application will be launched and the QrID can be scanned. If not, then a QrID will be generated server side and sent via SMS to the new user’s mobile phone. A response is sent back and displayed to the merchant to notify him/her if the process was successful. 4.5.5.2 Query Balance Screen When the merchant selects the Query Balance button from the home screen. The Barcode Scanner application is initiated and the user’s QrID can be scanned. The user is then presented with a screen where the card’s PIN code needs to be entered. If the correct PIN is entered then the current balance for the card and client’s details are displayed. If the PIN is incorrect then the screen will return to the home screen. If the client has forgotten their PIN code they can select the reset PIN option. 4.5.5.3 Buy Top-‐up Screen The PaymentPortal card acts as a debit card, therefore money needs to be loaded onto the card in order to make purchases. Money can be loaded onto the card in one of two ways: either someone sends money to the card via a P2P transfer, or money is loaded onto the card at a merchant. The Buy Top-‐up is this second option for when a customer goes to a merchant and gives the merchant cash that is then loaded onto the customer’s PaymentPortal card. The amount loaded is then deducted from the merchant’s registered bank account and loaded onto the customer’s card. When the merchant selects the Buy Top-‐ up menu item the Barcode Scanner application is launch and the customers QrID is scanned. The merchant then enters the amount to be added. Once again the customer does not need to enter their PIN as money is being put into the account and not withdrawn it therefore poses no security concern. The merchants then selects submit and the request is sent to the PaymentPortal server. A response is then sent back to the MyPay application to notify the merchant if the top-‐up was successful. The application returns to the home screen and the response received is displayed. The customer will then also receive an SMS to notify them with the top-‐up amount and current balance in their account.
48
4.5.5.4 Make Purchase Screen When a merchant wishes to process a purchase then they can select the Make Purchase button on the home screen. This will launch the Barcode Scanner application and the customer’s QrID can be scanned. The merchant then enters the purchase amount and the client enters their PIN code. The PIN code is hidden as to not allow the merchant to see the customer’s PIN. The merchant then presses the purchase button and the payment request is sent to the PaymentPortal server. The application then returns to the home screen and the response is displayed to the merchant. 4.5.5.5 Reset PIN Screen There is no need for the Reset PIN process to have a screen, as it takes no input from the user. When selected the Barcode Scanner is launched and the customers QrID is scanned. Once scanned the request is sent to the server. If the card is registered then a new PIN is generated and hashed replacing the previous one in the database. The new PIN is sent via SMS to the customers’ mobile phone. 4.5.6 Servlet Calls The Connection class handles all servlet requests sent by the MyPay application. The connection class takes one parameter, the URL of the PaymentPortal server, and then creates an HTTPSUrlConnection to the server. But when setting up Java HTTPSURLConnectin, a child of parent class UrlConnection, the Android implementation gave problems and would not create the connection because the certificate could not be trusted. The reason it could not be trusted was because a self signed SSL certificate was being used. In previous versions of HTTPSURLConnection, a parameter could be set to accept all certificates but in the latest release this parameter was removed. This problem was overcome by creating an extension of the certificate manager class in Java and calling a “trust all” method. This subclass then handles the certificates and accepts all certificates handled. The solution was found at [http://abhinavasblog.blogspot.com/2011/07/allow-‐ untrusted-‐certificate-‐for-‐https.html]. The Connection class has a method for each type of request that takes in the required parameters. It then packages the parameters into a HTML form and posts the request to the corresponding servlet. The response from the server is a JSON_Object containing the response from the server. The PaymentPortal API documentation for each servlet can be found in the Appendix.
4.6 PaymentPortal Features The aim of this system is to replace traditional cash based transactions. Therefore everything that a person can do with cash, they need to be able to do using the PaymentPortal service. The system will also need to be compared against credit card based solutions currently being used. And therefore it was designed to be able to offer the same functionality at a credit card. The system needed to be able to as robust as current systems. Designing the system to use Apache Tomcat made this very easy. Majority of current web based systems run off Apache Tomcat. The robustness of the system will be evaluated in chapter 5 where stress testing will be conducted on the server to simulate everyday use. The security features of the system meet current regulations discussed in section 4.3.5.2. All communication is encrypted with the same level of encryption used for online banking. And all personal information is encrypted in the database.
49
5 Evaluation and Testing Chapter This chapter is broken up into two parts statistical quantitative results and industry expert evaluation. The Quantitative results where calculated based on the systems performance. All results where conducted using a Huawei Ideos Android phone. The phone has Edge and 3G/HSDPA connectivity and therefore both connection types were tested. The PaymentPortal server was run off an Ubuntu 10.04 instance running in the amazon EC2 environment in Ireland. Not much is know about the actual hardware that the instance is run on. The only specifications that are known is that the instance has been allocated 613 MB memory and 2 EC2 Computing Units. One EC2 Computing Unit is equivalent to a single core 1.2GHz Opteron or Xeon processor [38]. The goal of this chapter is to establish the success of the project. The aim was to design a system that was as responsive as current methods and more cost effective than current mobile banking techniques. The quantitative testing is broken up into three parts the latency or processing time for a set of requests, the amount of data consumed to conduct payments and the robustness of the system. Can the system handle multiple servlet requests at once?
5.1 Latency When testing a web based mobile phone application the connectivity time is affected by the strength of the signal. There are two main types of data connections available. They are EDGE and 3G. Currently over 80% of South Africa has 3G coverage. But this is only when using the mobile phone outdoors. When the phone is taken inside and behind walls the signal is weakened. When testing the response time of communication with the server, testing had to be done on both EDGE and 3G connections. The first test that was conducted was to establish a baseline for a connection to the server. Therefore an application was used on the mobile phone to test the ping (measure of the round-‐trip time for a packet) from the mobile phone to the server. This same measure was used to calculate the cost of moving the server from a university PC to the Amazon EC2 in Ireland. For each scenario listed below 200 measurements were taken to establish a median and average value. 1. EDGE mobile to Lab PC 2. EDGE mobile to EC2 3. 3G mobile to LAB PC 4. 3G mobile to EC2 EDGE (Median) EDGE (Average) 3G/HSDPA (Median) 3G/HSDPA (Average)
Lab PC (South Africa) 403ms 501ms 483ms 624ms
EC2 Server (Ireland) 509ms 782ms 532ms 571ms
Table 4 Latency Results of mobile phones
The results from the ping tests revealed surprising results. The 3G/HSDPA results were not as optimal as originally thought after looking at the actual results it was established that the results had many spikes. These spikes occurred when the network changed from 3G to HSDPA the cost of this change was about 2000ms. It was interesting to see that the extra latency of moving the server to Ireland was not as high as originally thought. In some cases the EC2 results were better this was due to the load on the UCT network. From Table 4 the 3G network does not seem to offer an improvement in latency compared to EDGE. The minimum latency out of the result set revealed clearer results. The 3G/HSDPA was faster as
50
seen in Table 5 and the cost of moving the server to Ireland can be seen clearly. This is an interesting result because the PaymentPortal system does once off calls to the server and not a continuous connection and therefore this type of result shows the best and worse case results. It can also now clearly be seen that the cost of moving the server to Ireland is about 100ms extra in latency. Yet by looking at the max latency on the different connections it clearly shows that the EC2 server connection is more stable. This is because there is no other traffic being process on the network unlike the campus network. Min Max
EDGE to Lab PC 241ms 9648ms
EDGE to EC2 401ms 5041ms
3G/HSDPA to Lab PC 136ms 1135ms
3G/HSDPA to EC2 310ms 818ms
Table 5 Max and Min Latency Results
The follow results conducted on the PaymentPortal system was to establish the cost of using a HTTP vs. HTTPS connection. These results will show the true cost of encrypting the communication channel. For these the time was measured from the time a request was sent, from the MyPay application to the server, and a response was received back from the server. For this case of the testing the default HTTPS encryption settings were used as mentioned in section 4.3.5.1. The default encryption used is 128bit RC4 encryption with MD5 message authentication. EDGE with HTTPS to EC2 and 128bit
Edge HTTP Results EC2
8000 7000 6000 5000 Response Time 4000 3000 2000 1000 0 0
20
40
60
80
100
120
140
160
Number of tests Figure 32 HTTP vs. HTTPS Comparison on EDGE
51
3G/HSDPA on HTTP to EC2
3G-‐HSDPA HTTPS to EC2
6000 5000 4000 Response time 3000 2000 1000 0 0
10
20
30
40
50
60
Number of tests Figure 33 HTTP vs. HTTPS Response Comparison on 3G/HSDPA
HTTP (Average) HTTPS (Average) HTTP (Median) HTTPS (Median)
EDGE to EC2 1677ms 2621ms 1195ms 2556ms
3G/HSDPA to EC2 983ms 1664ms 833ms 1675ms
Table 6 Latency of HTTP vs. HTTPS connections
From these results, in Figure 32 and 33, it was interesting to see that the 3G results were more consistent than the EDGE results on both HTTP and HTTPS. The EDGE results had spikes in response times this could be due to the weaker signal strength. The median value is a better value to use due to the spikes in the results. These spikes skew the average value but a median value is the middle value in an ordered list. Table 6 shows that the cost of adding encryption to the communication channel was between 1000-‐1300ms for EDGE and 700-‐800ms on 3G. This is an increase of +-‐90% over the HTTP. It also shows that the cost of setting up an URLConnection is much more on EDGE than 3G. If you compare the median ping results from Table 4 with the median results from Table 6. It shows an increase of over 100% on EDGE but only 56% increase on 3G. This increase can be accounted to the extra bandwidth needed to set up an URLConnection and the limits of EDGE. The aim of this project was to make a secure mobile payments platform. But the question then became how secure should the communication be? HTTPS allows for a multitude of encryption techniques. The default is 128bit RC4 as used in Table 6. This is the fastest and most widely used. Yet this is not the most secure connection available. Therefore other HTTPS encryption types needed to be tested. The compromise in performance by adding extra security needed to be calculated.
52
RC4_128, with MD5 for message authentication and RSA AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA 6000 5000 4000 Latency (ms) 3000 2000 1000 0 1
11
21
31
41
Number of readings Figure 34 Comparison between 128bit and 256bit encryption
RC4_128 bit Encryption AES_256 bit Encryption
3G/HSDPA to EC2 1675ms 1803ms
Table 7 Median Latency for 128 vs. 256bit encryption
In Table 7 it can be seen that the performance difference versus encryption difference is +-‐ 120ms extra in response time. This is less than a 10% for an exponential increase in security. For this reason it was decided to use the more secure 256bit AES encryption for the communication channel. Since the server location and encryption level have been evaluated the final item to test was the actual response time for given requests. These would be everyday requests that the server would receive. They range from login times, check balance requests, processing a payment and registering a new card. Table 8 contains the results all done while the mobile phone had a 3G connection an EDGE connection added between 3-‐5 seconds more onto the response time. Check Balance Merchant Login Register New Merchant Process Payment Register New Card
Response Time 3460ms 4045ms 4099ms 3600ms 4442ms Table 8 Median Latency for MyPay Requests
It takes on average 3.6 seconds to process a payment. This is faster than the average of 10 seconds it takes a current credit card machine to process a payment. This result can be seen as a acceptable amount of time to process a payment. And is on par or faster than current methods of payment. Cash needs to be counted and change calculated this will take longer
53
than 3.6 seconds. Based on these results it can be established that the response time of the system is satisfactory for a mobile payments system. The response is also guaranteed unlike SMS where it can take up to several hours for the SMS to be delivered. The reason a register new card request is longer than any other request, is due to the process involved in creating a new card. When a new card is created there are two external API calls that need to be made. The first is a bit.ly request to shorten the download URL and the second is the API call to the Clickatell API to send the notification SMS.
5.2 Data used In order to calculate the exact cost of a payment the amount of data used per request was needed. Cellphone data is charged per the amount of bandwidth used. To calculate the amount of data used for each request an application was installed on the PaymentPortal Server. The server is running Ubuntu 10.04 and there is a bandwidth monitoring software called iftop. The reason this application was chosen is because it shows the bandwidth per device connected. Each devices connected to the server has a unique IP address that can be used to identify the device. Figure 35 is a screenshot of the iftop application running on the server with a mobile device connected and making requests.
Figure 35 Iftop screenshot of while processing MyPay Login
The IP address of the mobile phone can be seen circled in red. This is used to track each connection. The total bandwidth sent and received for the session can be seen circled in blue. The top figure is the amount of data sent from the server and the amount below is the amount of data received from the mobile phone. Figure 35 was taken during a login request the amount of data consumed was 3.39Kb. A break down of the amount of data for each request can be seen in Table 9.
54
Login Register New Card Query Balance
Sent 2.13Kb 2.03Kb 2.02Kb
Received 1.26Kb 1.29Kb 1.28Kb
Total 3.39Kb 3.32Kb 3.30Kb
Cost 0.644cents 0.630cents 0.627cents
Buy Topup Make Purchase
1.89Kb 1.31Kb 1.94Kb 1.33Kb
3.20Kb 0.608cents 3.27Kb 0.621cents
Reset PIN Send Money
1.90Kb 1.33Kb 2.07Kb 1.32Kb
3.23Kb 0.614cents 3.39Kb 0.644cents
Table 9 Cost Per Request
Table 9 shows that the amount of data used per request is just over 3Kb. Using the average price of R2/Mb (0.19c/Kb) the cost per a transaction was calculated. The cost per request is approximately 0.6cents a message. This is below the desired one cent a transaction originally required in the design chapter. Factors that contribute to this low data consumption are the use of JSON_Objects and the HTTPS protocol. The amount of data could have maybe been reduced more if compression was applied to the data before sending. But this would have required more processing time. At a price of 0.6cents a transaction a merchant can process roughly fifty transactions per day for less than 35 cents. Therefore a person can do fifty mobile payments for the less than the cost of doing one using SMS. The PaymentPortal system is also cheaper than USSD, which costs 20 cents per 20 seconds connected.
5.3 Stress Test System Any payment system needs to be able to handle large volume of transactions. This is known as stress testing the system. This is done to see how it will handle under pressure. The best application to test a web application is Apache JMeter. To test the system 100 requests were sent to the server in 1 second. Figure 36 shows the graph of responses to 200 Login requests sent in one second. The median response time for 800 requests was 1114ms. The max a request took was 7638ms and the average was 2739ms. All the tests were conducted using a standard 4Mb ADSL line and therefore the ping to the server was 250ms. So remove this from the median value and the server processing time per request is less than one second.
55
Figure 36 JMeter results with 200 Login Request in 1sec
Figure 37 shows the results when 300 login requests were sent to the server in one second. This shows a median response time of 3623. This is more than double that of Figure 36. The reason for this is that Tomcat can limit the number of HTTPS connections because the server needs to decrypt and encrypt every request. This encryption uses processing power. For these tests the limit was set to 250 connections. But with the system being developed to run on the Amazon EC2 backbone more server instances can be deployed. Amazon EC2 will then redirect the requests to any available server for processing. This therefore showed that the system could easily handle at least 200 requests per second with the current configuration. The throughput of the server is 1959 requests a minute or over 2.8 million requests a day.
Figure 37 JMeter results with 300 Login Requests in 1sec
56
5.4 Expert Feedback The system was evaluated by three different corporates. The PaymentPortal idea and system was presented to them. The MyPay mobile application was demoed by conducting a few transactions and registering a new card. Each expert was then asked to give his or her feedback on the feasibility of the system. The three industry experts were chosen for their experience in the different fields of payments. 5.4.1 HomeChoice HomeChoice is South Africa’s leading direct marketing retailer aimed at the middle-‐income consumer. The reason they were chosen to evaluate the system was that they have direct experience trying to accept payments from middle to low income individuals. They operate solely as a catalog business and therefore have no physical stores. They are therefore always looking at new ways that customers can pay for orders more efficiently. After the idea was pitched to HomeChoice they gave the following feedback. They said the idea had great promise. If implemented correctly it would have wide spread adoption as an alternative method of payment. Their only concern would be that as a merchant they would need an alternative way of accessing the system other than a mobile phone. They said they would need some sort of interface that they could process batches of invoices. It was then explained to them that with the whole system being designed as a web based API this could easily be implemented. All that would need to be done is create the web interface they required. They were then excited about the idea of possibly using QrIDs on products in their print catalogs. This would allow a customer to order and pay using the MyPay mobile application. Once again it was explained to them that this could be done as each product could be given its own unique barcode and account number. Their final concern was the need for them to get a notification when a payment was made so that they can arrange delivery of the order. The system already provides SMS notification when money is transferred into a PaymentPortal card but alternative notification methods could be added. 5.4.2 The Foschini Group (TFG) The project was presented to the director of financial services at TFG. TFG consists of 14 trading brands and over 1700 stores countrywide. They are one of the leading retailers in South Africa. They found the system very innovative, but had a few issues with the method of topping-‐up the card. They found this put the merchant at risk because they are then holding the cash and makes them vulnerable to theft. The cash also then needed to be deposited into a bank account. There solution for this was to not aim the card at only lower income consumers but to all bankcards. They also suggested a way of allowing someone to deposit money into a card from a normal bank account. It would then allow employers to pay their employees salary via online banking directly into a PaymentPortal account. This is similar to how FNB’s eWallet works. Another request they suggested is a method for a client to check their current balance without going into a merchant. The idea was for card to act in the same way as physical cash and therefore people like to know how much money they have at anytime. This feature was therefore added to the MyPay mobile application. They were impressed with the low cost of transactions. Their current system to register new customers uses both SMS and USSD and is costly for both retailer and customer. So an alternative solution is needed. They identified three elements needed for market success in informal settlements.
57
Security The system needs to provide sufficient security for both customer and merchant. All payment systems are vulnerable to fraud. There is a need for a method to lock an account in the case that a mobile phone is stolen. • Must work The system must be accessible to everyone and needs to be accepted by majority of merchants. If a customer cant use their PaymentPortal card everywhere then the system will not gain momentum. Word travels very fast in small communities. If one person has a bad experience with the system the news will travel fast. People is informal settlements cant afford to not be able to access their money. • Provide Benefits People in informal settlements are normally very small and close communities. They therefore they want to help improve their community. It was suggested to provide benefits to the community for using the system. For example if 10 000 customers sign up then either donate something to a local school or clinic. There also needs to be a benefit for a merchant to accept PaymentPortal payments as a form of payment. As a retailer they found the new system had lots of benefits and a new method of accepting payments. It was explained that it would be possible to include a QrID barcode on their invoices sent out to customers. This would allow a customer to pay their account without the need to go into a store. •
5.4.3 S1 Corporation S1 provide financial software to over 3000 banks and retailers worldwide. They are the second largest financial software provider in the world. They are an international company with offices all over the world including Cape Town. They process billions of transactions each year. The system was presented to the head of the mobile department. They were used to evaluate the security and technical aspects of the system. They found the system met all the security requirements for a payments system. The HTTPS communication uses improved encryption over current online banking solutions. All the personal details for a cardholder are encrypted and meet current regulations. The hashing of passwords and PIN codes also met all requirements. The use of valid PAN’s allowed the system to easily be incorporated into any of their current banking software solutions. They said the latency results of between 4 seconds on 3G and 8 seconds on EDGE to process a payment are within the acceptable level of a payment system. The acceptable time for processing a card payment is between 10-‐15 seconds. Therefore the PaymentPortal system is within the acceptable limits for a payment system on both 3G and EDGE connections. S1 are currently looking for mobile payment solutions. They were very interested in the idea and found that it could provide a new payments solution to add to their current software offering.
5.5 Overview of evaluation Based on the results obtained from section 5.1 and 5.2 the system provides an efficient and cost effective alternative to current mobile payment offerings. The system was robust enough to handle almost 3 million requests per day on a single server. It has also been developed with expansion in mind. And adding more instances easily managed using the Amazon EC2 infrastructure. The expert’s feedback all suggested that the system could work in the real world. They expressed a few minor concerns with the how the system would be marketed and introduced to the public but the main idea of the system was well thought out and showed promise.
58
6 Conclusion The project sought to find an alternative mobile payment solution. A solution that would be more suited to a lower income user. The main aim was to create a low cost and efficient payment solution, that was cheaper and more secure than current offerings. The system was designed in three parts the PaymentPortal Card, MyPay mobile application and PaymentPortal API. The aim from the beginning was to create a method of processing card payments without the need for specialized hardware. Using the mobile phones built in camera and 2D barcodes, overcame the need for specialized hardware. The card details were stored in a unique QR Code that was printed onto a customer’s card. A data connection was used instead of the standard SMS or USSD channel. It was also decided to use HTTPS instead of a socket connection normally used in client server application. This was done so that the system could easily be made cross-‐platform. The server was written as an API thus allowing third party application to be developed that could access the service. The server was moved onto the Amazon EC2 infrastructure to provide a more stable platform for testing. It would also allow the system to be expanded if needed. To test the whole system a basic Android mobile phone was created this allowed for results to be obtained for the latency of requests and performance of the system. Based on the results in Section 5.1 and 5.2 the system was responsive enough to be used as a financial payments solution. The time taken to process a payment was under 4seconds. This was made possible by keeping the number of calls to the server to a minimum. The cost per transaction was also drastically reduced compared to current payment methods. The cost per request to the server was 0.6 cents. This is 1% of the cost of an SMS and therefore an improvement over systems like M-‐PESA and eWallet. The system was stress tested and revealed that it could handle large volumes of requests a day. Running on a single server it was possible to process 2.8 million requests a day. But the system has been designed with expansion in mind. The system could easily have a single database server and then multiple servlet servers. The Amazon EC2 infrastructure will manage the routing of traffic. Overall this system can be seen as a success. It was proved possible that a card based mobile payments system could be implemented on a mobile phone without the need for specialized hardware. The communication between the mobile phone and server was encrypted and was therefore more secure compared to current SMS based systems. Based on the expert feedback there seems to be a demand for a system that is more cost effective than current systems and they agree that this system meets these requirements.
59
7 Future Work
•
Conduct Field Testing
•
Implement into S1 Software
•
Convert the system to a gift card management solution
Create a more stable system and then conduct proper user testing in the townships to improve on the usability of the interface. Write a driver allowing the PaymentPortal server to communicate to a proper S1 banking solution. The system can easily be converted into a gift card management solution. Allowing a merchant to issue gift cards (vouchers) to customers and then track all current gift cards using either mobile application or website.
60
8 Reference 1.
2. 3. 4. 5.
6. 7. 8. 9. 10. 11. 12. 13.
14.
15.
16.
17. 18.
19. 20.
21.
22.
23.
Anon, 2011. Global mobile statistics 2011: all quality mobile marketing research, mobile Web stats, subscribers, ad revenue, usage, trends…. Global Mobile Staticts. Available at: http://mobithinking.com/statscorner/global-mobile-statistics-2011-all-quality-mobile-marketing-research-mobile-web-stats-su [Accessed April 25, 2011]. Pettey, C. & Stevens, H., 2009. Gartner Identifies the Top 10 Consumer Mobile Applications for 2012. Gartner, p.1. Available at: http://www.gartner.com/it/page.jsp?id=1230413 [Accessed April 25, 2011]. Gamos, N.S. et al., 2004. The impact of mobile phones in africa. Knowledge Creation Diffusion Utilization, (November). Tuchscheerer, S., Fruth, J. & Dittmann, J., Secure cashless transactions on mobile. Communication. Balan, R.K. et al., 2009. mFerio: the design and evaluation of a peer-to-peer mobile payment system. In Proceedings of the 7th international conference on Mobile systems, applications, and services. ACM, p. 291– 304. Available at: http://portal.acm.org/citation.cfm?id=1555846 [Accessed April 25, 2011]. Merritt, C., 2010. Mobile Money Transfer Services : The Next Phase in the Evolution in Person-to-Person Payments. Structure. Chatain, Hernandez-Coss, Borowik, and Zerzan 2008 ?????? World Bank Bluetooth SIG, Inc., Bluetooth Specification Version 2.1 + EDR, Vol. 1, 2007 Bluetooth SIG, Inc., Bluetooth Specification, Version 4.0, Vol. 0, 2009 Recuero, L., Oecd, V. & Centre, D., 2010. Mobile payments for remittances in Africa : Benchmarking with Latin America 1. Economic Outlook, 95(95), pp.1-16. Anon, MobiCash Technology. Available at: http://mobicash.co.za/index.php?mid=170347/Technology [Accessed May 2, 2011]. Engineering, I., 2009. Implemented by Elliptic curve Cryptography. , pp.286-290. Askoxylakis, I.G. et al., 2007. Integration of a secure mobile payment system in a GSM/UMTS SIM smart card. In Proceedings of the Fourth IASTED International Conference on Communication, Network and Information Security. ACTA Press, p. 40–50. Available at: http://portal.acm.org/citation.cfm?id=1659151 [Accessed April 25, 2011]. Virki, T., 2007. Nokiaʼs cheap phone tops electronics chart. Reuters. Available at: http://uk.reuters.com/article/2007/05/03/us-nokia-history-idUKL0262945620070503 [Accessed April 27, 2011]. Nguyen, L. et al., 2010. The Missing Link: Human Interactive Security Protocols in Mobile Payment. In Proceedings of the 5th International Workshop on Security&\# x201a; IWSEC. Available at: http://scholar.google.com/scholar?hl=en&btnG=Search&q=intitle:The+missing+link+:+Human+Interactive+ Security+Protocols+in+mobile+payment#0 [Accessed April 25, 2011]. Hughes, N. & Lonie, S., 2007. M-PESA: Mobile Money for the “Unbanked” Turning Cellphones into 24Hour Tellers in Kenya. Innovations: Technology, Governance, Globalization, 2(1-2), pp.63-81. Available at: http://www.mitpressjournals.org/doi/abs/10.1162/itgg.2007.2.1-2.63. Soon, T.J., 2010. QR Code. , pp.59-78. Starnberger, G., Froihofer, L. & Goeschka, K.M., 2009. QR-TAN: Secure Mobile Transaction Authentication. 2009 International Conference on Availability, Reliability and Security, pp.578-583. Available at: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5066529 [Accessed October 18, 2010]. Carr, M., 2010. Mobile Payment Systems and Services: An Introduction 3 . Mobile Payment Solutions. Provider, pp.1-12. Clark, S., 2011. Near Field Communications World. Near Field Communications World. Available at: http://www.nearfieldcommunicationsworld.com/2011/02/10/35893/gentag-announces-low-cost-nfcrfidphone/ [Accessed May 2, 2011]. Google Android Marketplace Reaches 500,000 Milestone | Gadget Helpline. 2011.Google Android Marketplace Reaches 500,000 Milestone | Gadget Helpline. [ONLINE] Available at: http://blog.gadgethelpline.com/google-android-marketplace-reaches-500000-milestone/. [Accessed 30 October 2011]. Android Marches on East Africa - Technology Review. 2011. Android Marches on East Africa - Technology Review. [ONLINE] Available at:http://www.technologyreview.com/communications/37877/. [Accessed 30 September 2011]. Android becomes best-selling smartphone OS, says Canalys - Computerworld. 2011. Android becomes bestselling smartphone OS, says Canalys - Computerworld. [ONLINE] Available at:http://www.computerworld.com/s/article/9207218/Android_becomes_best_selling_smartphone_OS_says_ Canalys. [Accessed 10 October 2011].
61
24. $80 Android Phone Sells Like Hotcakes in Kenya, the World Next? | Singularity Hub. 2011. $80 Android Phone Sells Like Hotcakes in Kenya, the World Next? | Singularity Hub. [ONLINE] Available at: http://singularityhub.com/2011/08/16/80-android-phone-sells-like-hotcakes-in-kenya-the-world-next/. [Accessed 16 October 2011]. 25. Huawei U8150 IDEOS - Full phone specifications. 2011. Huawei U8150 IDEOS - Full phone specifications. [ONLINE] Available at:http://www.gsmarena.com/huawei_u8150_ideos-3513.php. [Accessed 03 October 2011]. 26. Platform Versions | Android Developers. 2011. Platform Versions | Android Developers. [ONLINE] Available at:http://developer.android.com/resources/dashboard/platform-versions.html. [Accessed 21 August 2011]. 27. Code Comparison. 2011. Code Comparison. [ONLINE] Available at:http://www.veritecinc.com/index.php?option=com_content&view=article&id=28&Itemid=40. [Accessed 08 October 2011]. 28. UUID (Java Platform SE 6) . 2011. UUID (Java Platform SE 6) . [ONLINE] Available at: http://download.oracle.com/javase/6/docs/api/java/util/UUID.html. [Accessed 01 August 2011]. 29. Advantages of Servlets over CGI - Benefits of Servlet Programs over CGI. 2011.Advantages of Servlets over CGI - Benefits of Servlet Programs over CGI. [ONLINE] Available at: http://www.roseindia.net/servlets/advantages-of-servlets-over-cgi.shtml. [Accessed 30 October 2011]. 30. Advantages of Servlet Programming,Online Servlets Advantages,Free Java Servlet Programming Advantages. 2011. Advantages of Servlet Programming,Online Servlets Advantages,Free Java Servlet Programming Advantages. [ONLINE] Available at: http://www.roseindia.net/servlets/AdvantagesOfServlets.shtml. [Accessed 30 October 2011]. 31. Bank card number - Wikipedia, the free encyclopedia. 2011. Bank card number - Wikipedia, the free encyclopedia. [ONLINE] Available at:http://en.wikipedia.org/wiki/Bank_card_number. [Accessed 30 October 2011]. 32. Luhn algorithm - Wikipedia, the free encyclopedia. 2011. Luhn algorithm - Wikipedia, the free encyclopedia. [ONLINE] Available at:http://en.wikipedia.org/wiki/Luhn_algorithm. [Accessed 30 October 2011]. 33. Secure Sockets Layer (SSL): How It Works - SSL Encryption/https from VeriSign, Inc.. 2011. Secure Sockets Layer (SSL): How It Works - SSL Encryption/https from VeriSign, Inc.. [ONLINE] Available at: http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/. [Accessed 30 October 2011]. 34. SSL Certificate Cost Comparison. 2011. SSL Certificate Cost Comparison. [ONLINE] Available at: http://www.whichssl.com/comparisons/price.html. [Accessed 30 October 2011]. 35. The World's Leading Mobile Messaging Provider | Clickatell ZA. 2011. The World's Leading Mobile Messaging Provider | Clickatell ZA. [ONLINE] Available at:http://clickatell.co.za/. [Accessed 30 October 2011]. 36. Amazon Elastic Compute Cloud (Amazon EC2). 2011. Amazon Elastic Compute Cloud (Amazon EC2). [ONLINE] Available at: http://aws.amazon.com/ec2/. [Accessed 30 October 2011]. 37. Command Buttons. 2011. Command Buttons. [ONLINE] Available at:http://msdn.microsoft.com/enus/library/windows/desktop/aa511453.aspx. [Accessed 30 October 2011]. 38. Amazon EC2 Instance Types. 2011. Amazon EC2 Instance Types. [ONLINE] Available at: http://aws.amazon.com/ec2/instance-types/. [Accessed 30 October 2011]. 39. Suid-afrika, R.V.A.N. Government Gazette Staatskoerant. Prevention 481, 27803 (2005), 1-40. 40. Card, P. and Security, I. Payment Card Industry Security Standards Security Standards Council to protect. Security,
62
9 Appendix
SQL Create Table Statement CREATE TABLE `bank` ( `pan` varchar(16) NOT NULL, `balance` decimal(10,0) NOT NULL, PRIMARY KEY (`pan`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1$$ CREATE TABLE `cards` ( `qrid` varchar(45) NOT NULL, `name` varchar(45) DEFAULT NULL, `surname` varchar(45) DEFAULT NULL, `mobile` varchar(45) DEFAULT NULL, `pan` varbinary(200) NOT NULL, `pin` varchar(45) NOT NULL, `salt` varchar(45) NOT NULL, PRIMARY KEY (`qrid`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1$$ CREATE TABLE `credentials` ( `username` varchar(100) NOT NULL, `password` varchar(32) NOT NULL, `salt` varchar(32) NOT NULL, PRIMARY KEY (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1$$ CREATE TABLE `users` ( `client_id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(100) NOT NULL, `name` varchar(255) NOT NULL, `mobile` varchar(15) NOT NULL, `address` varchar(255) DEFAULT 'Not Set', `PAN` varbinary(200) NOT NULL, PRIMARY KEY (`client_id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1$$
63
2D Barcode Testing Sheet Test Code 1: (12 Characters)
Test Code 2 (45 Characters)
Test Code 3 (200 Characters)
Test Code 4 (425 Characters)
64
PaymentPortal Server Software Requirements • • • •
Ubuntu 10.04 (or above) Java Runtime Environment MySQL Apache Tomcat 6
PaymentPortal Server API Document Each Servlet was written as an API it receives a HTML form Post and returns a JSON Object Response. All API need to be made using HTTPS protocol. Or the servlet will reject the connection. The fields for each form are set out in the follow API calls.
Register The Register Servlet is responsible for registering a new merchant with the PaymentPortal Server. It takes in the merchant’s details and valid credit card number. The credit card number is checked to see if valid before adding to the system. o URL: https://paymentportal.co.za/PaymentPortal/Register o Input String username String password String name String mobile String pan o Response Boolean added Integer client_id
Login The Login API call takes in the username and password. It then checks if the username exists and gets the users salt value. Adds the salt to the password and hashes the password. It then compares the hash and returns auth true or false. If true it returns the users name and client_id and a welcome message. o URL: https://paymentportal.co.za/PaymentPortal/Login o Input String username String password o Response Boolean auth String name Integer client_id String resp
65
NewCard The NewCard API call takes the client details parameters. The qrid and pan parameters are optional. If left blank then the server will generate a qrid and a valid pan for the new cardholder. The amount is the starting balance in the account. The customer will receive an SMS with their current balance and their 4-‐digit pin code. If a qrid was generated then the SMS will contain a link to where the card can be downloaded. o URL: https://paymentportal.co.za/PaymentPortal/NewCard o Input String qrid (optional) String name String surname String mobile Double amount String pan (optional) Integer client_id o Response Boolean added Boolean banked
ProcessPayment The ProcessPayment API is used to process a purchase or top-‐up from a merchants account. The API takes in the cardholders details and if purchase then the cardholders PIN code and the amount for the given transaction. The servlet checks that the entered PIN code is 4-‐ digits long and then hashes as checks again stored hash of PIN. If accepted then available balance is checked agaist purchase amount to see if suffiecenent funds available. If so then the transaction is processed. The payment response is sent in the payResp variable. True for successful and false for failed. o URL: https://paymentportal.co.za/PaymentPortal/ProcessPayment o Input String qrid String pin String amount Integer client_id String type (purchase or topup) o Response Boolean active Boolean payResp
66
SendMoney The SendMoney API is used when sending funds from one PaymentPoral card to another PaymentPortal card or another person. If the recipient does not own a PaymentPortal card then one can be created and sent to the recipient’s mobile phone. If creating a new card then set newCard to True and provide recipients name, surname and mobile number. The senders PIN is then hashed and checked against stored hash. A check is made to see if sender has sufficient funds. If a new card is process then the API calls to register a new card. And once created the funds are transferred and the response is sent back. o URL: https://paymentportal.co.za/PaymentPortal/SendMoney o Input String fromQrid String fromPin String Amount String toQrid (if not new card) Boolean newCard String name (if new card) String surname (if new card) String mobile (if new card) o Response String resp Boolean payResp
getBalance The getBalance API call is used to check the current balance of a PaymentPortal card. The QrID and PIN code are sent. The PIN code is checked to see if it is 4-‐digit number. If so then PIN is hashed and compared against stored hash. If PIN is accepted then the servlet returns the cardholders name and current balance. If card is not found then the found parameter returns false. o URL: https://paymentportal.co.za/PaymentPortal/getBalance o Input String qrid String pin o Response String balance String name String surname String qrid Boolean found
67
ResetPIN The ResetPIN API call is used to reset a cardholders PIN code. The PIN cannot be retrieved, as the actual PIN is not stored in the database. Therefore a new 4-‐digit PIN is generated and hashed in the database. The new PIN is then sent via SMS to the cardholders’ mobile phone. If the PIN was reset then the reset parameter is true. If the sending of the SMS was successful then the smsed parameter is true. o URL: https://paymentportal.co.za/PaymentPortal/ProcessPayment o Input String qrid o Response Boolean smsed Boolean reset
68