Adrian Thesis

33 downloads 253256 Views 7MB Size Report
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