Honours Project Report
PaymentPortal a Cost-‐Efficient Mobile Cashless
Payments Platform using Visual Identification
Adrian Maritz
Category Min Max Chosen
1 Software Engineering/System Analysis 0 15 10
2 Theoretical Analysis 0 25 0
3 Experiment Design and Execution 0 20 10 4 System Development and Implementation 0 15 10 5 Results, Findings and Conclusion 10 20 15 6 Aim Formulation and Background Work 10 20 15 7 Quality of Report Writing and Presentation 10 10 8 Adherence to Project Proposal and Quality of
Deliverables 10 10
9 Overall General Project Evaluation 0 10 0
Total marks 80 80
Supervisor: Gary Marsden
Department of Computer Science
University of Cape Town
2011
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.
Contents
1
Introduction Chapter ... 7
2
Background Chapter ... 9
Overview of Research ... 9
2.1
Current Mobile Cash Providers ... 9
2.2
M-‐PESA (Kenya) ... 9
2.2.1
FNB eWallet ... 10
2.2.2
Methods of conducting mobile payments ... 10
2.3
USSD ... 10
2.3.1
RFID ... 11
2.3.2
Bluetooth ... 11
2.3.3
NSDT ... 12
2.3.4
WAP ... 12
2.3.5
Overview of current methods ... 12
2.3.6
Types of Mobile Payments ... 14
2.4
Mobile at Point of Sale ... 14
2.4.1
Mobile as Point of Sale ... 14
2.4.2
Direct Carrier Billing ... 15
2.4.3
Android Smart Phones ... 15
2.5
Storing data visually with use of 2D barcodes ... 15
2.6
QR Codes ... 17
2.6.1
Data Matrix ... 18
2.6.2
Choosing an optimal 2D Barcode ... 18
2.6.3
3
Design Chapter ... 19
Aim of proposed system ... 19
3.1
Scenarios ... 20
3.2
Registering new merchant ... 20
3.2.1
Adding new card ... 20
3.2.2
Make Payment ... 21
3.2.3
Recharge card ... 22
3.2.4
P2P payments ... 22
3.2.5
Reset PIN ... 23
3.2.6
Problems faced with implementing a Mobile Payments system ... 24
3.3
Communication between mobile phones and central processing server ... 24
3.4
Overview of System ... 25
3.5
PaymentPortal Card ... 25
3.5.1
PaymentPortal Web Service ... 26
3.5.2
MyPay Mobile Phone Client ... 26
3.5.3
Design Requirements ... 27
3.6
Cost Efficient ... 27
3.6.1
Secure Communication ... 27
3.6.2
Security ... 27
3.6.3
Authentication ... 27
3.6.4
Notifications ... 28
3.6.5
Open-‐Platform ... 28
3.6.6
Response Times ... 28
3.6.7
Ease of Use ... 28
3.6.8
4
Implementation Chapter ... 29
Layout of project ... 29
The PaymentPortal Card ... 29
4.2
Choosing 2D Barcodes ... 29
4.2.1
Generating Unique Identifiers (QrID) ... 30
4.2.2
Generating QR Codes ... 31
4.2.3
PaymentPortal Server ... 31
4.3
Communication Protocol Used ... 31
4.3.1
Java Servlets ... 31
4.3.2
Registering New PaymentPortal Card ... 33
4.3.3
Processing Payment ... 34
4.3.4
Server Security ... 34
4.3.5
Notification System ... 37
4.3.6
Moving PaymentPortal Server to Amazon EC2 ... 39
4.3.7
Paymentportal.co.za domain registration ... 40
4.3.8
Database design ... 40
4.4
MyPay Android Client ... 41
4.5
Notifications ... 41
4.5.1
QR Scanning ... 42
4.5.2
User Interface Design ... 43
4.5.3
Send Money (P2P) Interface ... 44
4.5.4
Merchant User Interface ... 46
4.5.5
Servlet Calls ... 49
4.5.6
PaymentPortal Features ... 49
4.6
5
Evaluation and Testing Chapter ... 50
Latency ... 50
5.1
Data used ... 54
5.2
Stress Test System ... 55
5.3
Expert Feedback ... 57
5.4
Homechoice ... 57
5.4.1
The Foschini Group (TFG) ... 57
5.4.2
S1 Corporation ... 58
5.4.3
Overview of evaluation ... 58
5.5
6
Conclusion ... 59
7
Future Work ... 60
8
Reference ... 61
9
Appendix ... 63
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
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
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.
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?
2
Background Chapter
Overview of Research
2.1
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.
Current Mobile Cash Providers
2.2
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.
M-‐PESA (Kenya)
2.2.1
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.
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.
FNB eWallet
2.2.2
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.
Methods of conducting mobile payments
2.3
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.
USSD
2.3.1
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
with each transaction costing at least 20cents. The aim is to get the communication cost of a transaction to around 1cents a transaction.
RFID
2.3.2
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.
Bluetooth
2.3.3
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.
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.
NSDT
2.3.4
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.
WAP
2.3.5
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.
Overview of current methods
2.3.6
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.
Table 2 Comparison of different technologies used for mobile payments
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
mobile phone 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
Cost is billed per 20s at an average price of R0.21/20sec 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
Authentication USSD can accept PIN codes as a form of authentication 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
3rd Party Payment Server
USSD is to a service provider’s server. 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
Types of Mobile Payments
2.4
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.
Mobile at Point of Sale
2.4.1
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)
Mobile as Point of Sale
2.4.2
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.
Direct Carrier Billing
2.4.3
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.
Android Smart Phones
2.5
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].
Storing data visually with use of 2D barcodes
2.6
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.
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.
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
magnetic media
Depends on the noise and angle
1/1,000,000
Technical Advantage Portable and data is
rewritable
Quick and batch processing
Quick and accurate
Print Cost Intermediate Very high Very low
Table 2 Comparison between 2D barcode and other automatic identification techniques
(Source: http://bit.ly/nJi5IP)
QR Codes
2.6.1
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.
Figure 5 Examples of QR Code and Data Matrix
Data Matrix
2.6.2
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.
Choosing an optimal 2D Barcode
2.6.3
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.
3
Design Chapter
Aim of proposed system
3.1
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