DEGREE PROJECT IN ELECTRONICS AND COMPUTER ENGINEERING, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2019
Connecting Electronic Wallets to Achieve Cross-Platform P2P Micropayments Daniel Muresu Ahmad Shabeeb
KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Abstract
There are many different ways to conduct a payment in today’s society. The most common ways to transfer money is by using bank transfer, credit and debit cards or e-wallets. Global and instant micropayments are however not possible using different e-wallets as endpoints. In this report, the authors try to find a feasible solution to this by using and combining the functionalities of two e-wallets by connecting them. Research is made on potential endpoint e-wallets and Swish and PayPal are selected to be used in the system. A distributed system model is built and an initial prototype is implemented based on wire transfers. The system is tested using a integration testing strategy and the performance of the prototype is validated by measuring the execution time of the system. The results from the unit and system tests are collected and the system is verified by passing all integration tests. It is concluded that there is a feasible solution for connecting the e-wallets and that even more e-wallets could be integrated into the system. Lastly, the authors discuss the project and future work.
Keywords
Micropayment, e-wallet, Distributed Systems, Blockchain, Wire Transfers
i Abstract
Det finns många olika sätt att betala i dagens samhälle. De vanligaste sätten att överföra pengar är genom banköverföring, kredit- och kontokort eller elektroniska plånböcker. Globala och snabba mikrobetalningar är däremot inte möjliga med olika e-plånböcker som betalningssätt. I denna rapport försöker författarna hitta en möjlig lösning till detta genom att använda och kombinera funktionaliteten hos två e-plånböcker genom att ansluta dem. Undersökningar görs på potentiella e-plånböcker och Swish och PayPal blir valda för att användas i systemet. En distribuerad systemmodell är byggd och en initial prototyp implementeras baserat på trådbundna överföringar. Systemet testas med en enhetsteststrategi och prototypens prestanda valideras genom att mäta tiden av systemets utförande. Resultaten från enhets- och systemtester samlas in och systemet verifieras genom att klara alla enhetstester. Slutsatsen dras att det finns en möjlig lösning för att ansluta de elektroniska plånböckerna och att ännu fler elektroniska plånböcker kan integreras i systemet. Slutligen diskuterar författarna projektet och framtida arbete.
Nyckelord https://www.overleaf.com/project/5c923cd521063b4a908c195a Mikrobetalningar, Elektroniska Plånböcker, Distribuerade System, Blockchain, Trådbunda Överföringar
ii Acknowledgements
Firstly, we would like to thank Henrik Gradin and Centiglobe for allowing us to write our thesis in collaboration with them, and for all the time that Henrik dedicated to helping us complete our project.
We would also like to thank Benoit Baudry for supervising our project and for taking time to consistently meet us and help us with our report and project. We are also grateful for the help he gave us by sharing his network of people whom could assist us with technical aspects of our thesis.
Last but not least, we would like to thank Alf Thomas Sjöland, whom took the role as examiner in our project. His input in our report and explanations of the process of our thesis was greatly appreciated by us.
iii Authors
Daniel Muresu [email protected]
Ahmad Shabeeb [email protected]
Information and Communication Technology
KTH Royal Institute of Technology
Examiner
Alf Thomas Sjöland
Electrum 229
KTH Royal Institute of Technology
Supervisor
Benoit Baudry
Lindstedtvägen 3, Building D
KTH Royal Institute of Technology
Place for Project
Centiglobe https://www.centiglobe.com/
Stockholm, Sweden
Linnégatan 89C, 115 23 Stockholm Contents
1 Introduction 1 1.1 Background ...... 1 1.2 Problem ...... 3 1.3 Purpose ...... 4 1.4 Goals ...... 4 1.5 Benefits, Ethics and Sustainability ...... 4 1.6 Methodology ...... 5 1.7 Delimitations ...... 5 1.8 Outline ...... 6
2 Theoretical Background 7 2.1 Distributed Systems ...... 7 2.2 Wire Transfer ...... 8 2.3 E-wallets ...... 8 2.4 Blockchain ...... 9 2.5 Related Work ...... 10
3 Methodologies and Methods 12 3.1 Research Process ...... 12 3.2 Potential e-wallets ...... 13 3.3 Model ...... 14 3.4 Integrated Technologies ...... 16 3.5 Test Bed ...... 17 3.6 Testing and Data Collection ...... 18 3.7 Data Analysis ...... 22
4 Design and Implementation 23 4.1 API Design ...... 23 4.2 Transaction Handling ...... 25 4.3 Gateway Implementations ...... 27 4.4 System Work Flow ...... 28 4.5 Potential Failures ...... 29
v 5 Results 32 5.1 Integration Test Results ...... 32 5.2 System Test Results ...... 34 5.3 System Validation ...... 34
6 Conclusions and Discussion 39 6.1 Conclusions ...... 39 6.2 Discussion ...... 40 6.3 Future Work ...... 42 6.4 Final Words ...... 43
References 44
vi 1 Introduction
In this section, the reader is introduced to the project and which problems it concerns. Delimitations, purpose, goals, methodology and sustainability of the project are also discussed.
1.1 Background
Technological advances combined with internet have allowed us to move from cash payment systems to online payment systems. Online payment systems are an important part of the world for individuals and organizations to transfer money on the internet. Non-cash transactions are becoming more and more common practice in society today. According to the World Payment Report from 2018, the number of non-cash transactions in the top ten markets increased in each market from 2015 to 2016 with 25.8% in China and 36.5% in Russia.[1]
The popularity of the mobile devices opened up the opportunities for new online- based payment methods such as mobile payments and e-wallets.[2] E-wallets application has provided the ability for users not just to make payment for merchants but also the ability to make peer-to-peer payments. Peer-to-peer payments started to be considered in the new design of the e-wallet since this approach can help build a larger customer base and expand the market beyond the retail world.[2]
Payment systems are used to settle financial transactions throughout the world. Electric payments have become increasingly popular but have yet not been fully optimized. It is possible to conduct a global transaction today using banks or specific services like PayPal or Western Union. However, these services are usually slow and/or expensive. Western Union, for example, offers global money transfer between bank accounts, but a peer-to-peer money transfer to a bank account may take up to 4 days until the receiver can see the money on their account.[3]
1 They also offer the possibility to pay with a debit card, which will make the process faster - about 2 days, but this is not the kind of transactions that we are looking into in this report, moreover, 2 days is also slow compared to instant money transfer services.
In this report we are mainly concerned with micropayments which enable the user to transfer a usually small amount of money to another user without delays and without or with small fees. Micropayments are popular features among e-wallets, where the user usually should have an application installed on their mobile phone to be able to conduct the micropayment. E-wallets support both peer-to-peer and customer-business transactions. The most common instant money transfer application for micropayments in Sweden today is Swish, which is widely used for both consumer-consumer and consumer-business transactions. Swish is however limited to the fact that both sender and recipient need to support the application in order for the transaction to be successful. The Swish application has gained a huge popularity the last couple of years, one can view the growth of Swish in figure 1.1 below.[4]
Figure 1.1: from Swish statistik 2012-2018
Services like Western Union and PayPal come with a transfer fee, even for micropayments. Fees vary in size, depending on if the transfer is between different countries and/or currencies. Instant money transfer services like Swish offers peer-to-peer micropayments without fees. The problem with services like Swish however, is the lack of support for international transfers.
2 Swish users, for example, need to have a Swedish bank linked to their Swish account in order to be able to use the service. In addition, the service only supports transferring Swedish crowns.
There are today no solutions for transferring money internationally, instantly, free of charge or cheap while using different applications as endpoints. In this report we will discuss an implementation for global money transfer with different applications as the two endpoints of transfer. The two applications that we are going to use are e-wallet based applications that support peer-to-peer micropayments, these applications will act as the endpoints. We will explore if there is a feasible solution to connecting two e-wallet applications, in other words, if there is a possibility of a person using one e-wallet to send money to another person’s account with a different e-wallet instantly. We will also explore the limitations, opportunities and further implementations of such an implementation.
1.2 Problem
As mentioned, online payment methods are widely used to facilitate money transactions and international trades, and the most common ones are bank transfer, credit and debit cards and e-wallets. All the mentioned methods have their own advantages, for example when using bank transfer, the user only needs their bank account number and credentials to request a transaction from one account to another. With credit cards the user can easily use the card as a key to their bank accounts which helps in making an online purchase. Lastly, e-wallets are easy to use and provide almost free of charge money transfer services.
However, each payment method has its own limitations. Bank transfers are slow. It can take several days to complete the process and for the money be available in the recipient’s account. Bank transfers may also require several intermediate financial institutes which might require additional fees, making bank transfer expensive and not suitable for micropayments. Cards only allow purchases and does not support peer-to-peer transactions. E-wallets require that both sender and recipient have the same e-wallet application and also most e-wallets need
3 to be backed with bank accounts. With different e-wallets and mobile payment methods in the market it can be tiring for users to acquire several e-wallets and it could lead to a limited user base.
In this report, the following question will be answered:
How can different e-wallets be connected to create a global, instant, peer-to-peer micropayments system?
1.3 Purpose
The purpose of our research in this report is to find a plausible solution to a system which connects different e-wallets in order to provide cross-platform peer-to-peer micropayments. The authors also hope that our research can be used as a basis for researching similar systems and help future work to create solutions in the same area more easily.
1.4 Goals
The main goals of this project is to provide an initial prototype and research on the possibility of integrating the endpoints with each other and to investigate the performance of such a system. If time permits, the security of the implementation will be investigated.
1.5 Benefits, Ethics and Sustainability
If a feasible solution to the problem were to be found, there would be many benefactors from the system. Firstly, the consumers would favor from the system, since it would enable them to send money globally faster than before. Secondly, the e-wallet providers would benefit since their products would be used with a wider purpose, contributing with more consumers. A system that enables people to instantly send money globally between different e-wallets, would promote economical growth, which affects economical sustainability. However, when implementing such a system, one should also consider economical aspects like
4 taxes, which can also affect economical sustainability. Furthermore, the system is intended to be built as a distributed system of gateways representing the e-wallets nodes on top of a blockchain system. The whole system will gain advantages like being decentralized, distributed, immutable, transparent and traceable, which prohibits fraudulent actions in the system. Indirectly contributing to a more socially sustainable society. However, blockchain systems also consume a lot of energy, which jeopardizes sustainable development. This trade-off is something which needs to be considered when using or developing such a system.
1.6 Methodology
The methodology used in this report is connecting existing e-wallets together by building a system based on a peer-to-peer distributed system model. A node in the system will act as an e-wallet gateway and all nodes in the system will be able to communicate with each other. A blockchain will also act as a node in the system where all the nodes will communicate with it to handle money exchange operations between gateways with different currencies. The distributed system will act as an international wire transfer system, meaning there will be no actual money transfer between the gateways rather than changing currency balances between the nodes. In this report the system will only have two nodes beside the blockchain, the nodes used are the Swedish e-wallet Swish, and the american PayPal e-wallet, thus the currencies used are SEK and USD. The blockchain infrastructure is provided by the sponsor Centiglobe.
To verify the system, integration testing will be used under the development of the system, this will help modularize the system, and check the behaviour of each node separately. In addition, the time of the whole transaction/operation will be used to validate the performance of the system.
1.7 Delimitations
In order to maintain a reasonable time frame of the project, some limitations have been chosen. We will only be researching the possibility of connecting the
5 two e-wallets Swish and Paypal, furthermore, we will only test the feasibility of sending money in the direction Swish to Paypal. In theory, one could send money in both ways in the system, and also connect even more e-wallets, achieving N*N directions of transfer. Creating a complete system would however consume more time than the project has. Another delimitation that the project will have is to not handle any real transfers of money. In the validations and evaluations, only test cases and sandbox accounts will be used to examine the system. The reason for this is a lack of financial resources for testing, and merchant licenses are required for real transactions. In the implementation, errors will not be handled. This means that there will not be any handling of cases where for example, the user inputs are incorrect or flawed in their payment request. In a full system, this should be completely implemented, but this is not something that will be included in this report since only the feasibility of connecting the e-wallets by building a prototype without error handling is researched.
Lastly, as a result of only sending money in one direction, an imbalance in the cash flow will be created in a complete system. Features to balance out the cash flow will however not be implemented, and will not be included in this report either. The reason for this is that only the feasibility of connecting the e-wallets is tested and not all the implications of a complete system.
1.8 Outline
The project is divided into sections which describe each area of the work. In order to structure it further, some sections are also broken down into subsections.
In chapter two, the reader is introduced to the different technical aspects of the system and some related work. Chapter three contains the technical methodology, what frameworks were used, how the system was built and how the data was collected are analyzed. In chapter four, the implementation is described and what was done during the project is presented. In chapter 5 the results from the unit, functionality, and time measurement testing are presented. The last chapter contains the conclusions and the findings are discussed. The report is then ended with some final words from the authors.
6 2 Theoretical Background
The reader is here introduced to a background of the technical aspects of the project. Distributed systems, wire transfers, e-wallets and blockchain are the most important technical components to be familiar with in order to fully understand the thesis, which is why they are described below. The section is then ended with a subsection containing some related work.
2.1 Distributed Systems
A distributed system is a system consisting of several nodes that communicate with each others with common protocols. George Coulouris, a professor at Cambridge university defines a distributed system as: “a system in which hardware or software components located at networked computers communicate and coordinate their actions only by message passing”.[5] Nowadays, distributed systems are used in various applications with different purposes. They are usually built on top of a network of computers and they have various types such as clusters, grids and peer-to-peer networks.
There are also several benefits with distributed systems such as scalability, inherit distribution and reliability. Despite all these benefits distributed system also have to deal with some issues depending on the software application implemented, for example, heterogeneity, transparency, concurrency, openness, extensibility and security. Scalability - the ability of the system to perform well at high load of users - can also be one of the challenges of a distributed system.[6]
In this project the distributed system is built to behave as a peer-to-peer network, where all nodes of the system will be able to communicate with each other. Peer-to-peer distributed system are decentralized and mainly used in software applications to facilitate content distribution like file sharing and instant messaging over a public network. For this project however, it is used to let the nodes communicate with each others by defined protocols over a public network, where each node will be a component in the system.
7 2.2 Wire Transfer
Wire transfer is a method which allows users to send and receive money in an easy and fast way. Nowadays, most banks support domestic and international wire transfer. Some companies such as Western Union and MoneyGram, known also as wires, can provide the same service but even faster. A system based on wire transfers is built on top of a network of banks which interact with each other through a specific messaging system called SWIFT (Society for Worldwide Interbank Financial Telecommunication). [7]
The money will never physically be transferred between banks using wire transfer. Instead, the sender’s bank will deduct the money from the sender account and send instructions to the recipient’s bank to add it to the recipient’s account, it is just changing balances according to the operation [7]. Companies like Western Union and MoneyGram also allow cash payments, and the recipient can then collect the money from another office. Usually wire transfer can take up to several days until the money is available in the recipient’s account, but these companies also provide almost instant money transfer but that comes with extra fees [8]. In this project gateways will be implemented to act as deposit offices and they will communicate with a messaging protocol to adjust balances according to the operation/transaction.
2.3 E-wallets
An electronic wallet, or e-wallet, is an application based wallet which is used for electronic payments. Efficiency, safety and utility are some properties that an e-wallet should have.[9] Swish is the most common e-wallet in Sweden which popularity has increased significantly over the last couple of years. [4] An e- wallet works much like how money is stored in ones bank account, by using virtual storage.[9] Technological advances have enabled several features to be used in tandem with digital wallets, for example, paying using a QR-code and peer-to-peer transactions. The simplicity, availability and scalability of the electronic wallets is what has made them increasingly popular and according to Dave Landry Jr. a finance and marketing consultant, E-wallets are the future of payments .[10]
8 2.4 Blockchain
Blockchain is based on the concept of a distributed database, which means that the database has multiple copies of data, distributed on different nodes. [11] A node can be a computer for example. When a transaction is made in the system, it is done with peer-to-peer communication and all transactions needs to be validated by a portion of the nodes in the system. Furthermore, the copies in the system are encrypted by hash-functions and the transactions are appended sequentially in so called blocks at the end of the blockchain that cannot be deleted once validated.
Figure 2.1: Illustration of Blockchain[12]
By doing this, the transactions in the blockchain are traceable and transparent, meaning that the data is nearly impossible to corrupt or alter.[13] These aspects make the blockchain systems reliable, which is one of the reasons why they have become increasingly popular. In this thesis, the blockchain will be used to handle the realtime money exchange between two currencies and register the transaction accordingly.
9 2.5 Related Work
During this research, relevant related work concerning connecting payment applications was not found. This is why the decision was made to research related work within blockchain integration and micropayments.
2.5.1 Blockchain Integration
When it comes to blockchain integration, a lot of related work and research has been done, since it is a very popular, nuanced and growing technology. Perhaps one of the most interesting integrations of blockchain technology is with the Internet of things(IoT). IoT connects everyday devices and items to the internet and enables them to exchange data and improve our quality of life. Issues have however been raised with the IoT since they initially have been using a centralized system, unlike the blockchain which is a decentralized system.[14] This was one of the reasons why integration with blockchain has been viewed as a solution to these issues.
One challenge with the centralized system of IoT is for instance scalability. Since the IoT system is required to handle a significantly increasing amount of devices, scalability is a mandatory aspect of the system. More research needs to be done in order to determine how a blockchain system could potentially make IoT more scalable. In theory however, a blockchain system would help to make the IoT more scalable by decentralizing the system. [14]
Another challenge concerning the currently centralized IoT system is security and privacy. Since the devices contain private information of the users, security is extremely important for the system. Since it is not allowed to store personal data in the blockchain, security is one of the biggest challenges when it comes to the integration of blockchain and Internet of things. In this thesis, it will be required to take the same concerns into consideration when it comes to integrating the distributed system with the blockchain.
10 2.5.2 Micropayments
Throughout the literature study of this report it was hard to find similar studies or work related to achieving international peer-to-peer micropayments. However, micropayments targeted to client-merchant scenario is a hot topic. A study has been made by Jose M. del Barco about creating a micropayments platform (MPP) as an attempt to give a solution to reduce the relatively large charge fees for small services. In the study, Del Barco says ”I observed that the actual efforts to solve the micropayment problematic were either by aggregating a specific amount of transactions into a single one to condense the transaction fees, or creating a virtual currency to work with” [15]. The approach used in MPP is to create virtual accounts and virtual currencies built on top of a common third party payment method (PayPal). The system requires users to have PayPal accounts to charge their virtual MPP accounts. The MPP platform will consist of several PayPal merchant accounts with different currencies. Making transactions between user’s virtual accounts is only changing balances in the MPP virtual accounts rather than making real life transaction, meaning that any micropayment within the MPP system is at zero cost. The only time the user pays a fee, is when they have to charge their accounts or when retrieving money from virtual accounts to PayPal accounts.
Building upon this idea, a similar approach will be used in this project, but with several differences which will better suit peer-to-peer micropayment transactions scenarios and integrating existing technologies. The first main difference between MPP and the system in this project are supporting many third party gateways in the platform rather than just one in MPP (PayPal). The second main difference is that no virtual accounts specific to the platform are needed rather than users can use their accounts from the integrated e-wallets in the system of this thesis. The last difference is that the implemented system will handle currency exchange through a blockchain cryptocurrency trading, while MPP used Forex API to handle currency exhange.
11 3 Methodologies and Methods
This section elaborates on the scientific and engineering related content of the thesis. To carry out the research, the methodology of creating an initial prototype of the system is used. The prototype is based on a model of distributed systems and is verified with integration testing during the development of the system. This helps to modularize the system, but also to check the behaviour of each component separately. Lastly, the time of the whole transaction/operation is measured to validate the performance of the system.
3.1 Research Process
The first thing that is required is to conduct a research on potential e-wallets to be connected to each other. A period of about two weeks is spent on testing e-wallet applications and reading their documentations to see if they could potentially be integrated into a system. A more detailed mapping of the researched e-wallets can be found in subsection Potential e-wallets. Once Swish and PayPal are chosen for this project, a research on related works is conducted in order to better understand the technical background of the project.
When the research on the theoretical background of the project is completed, the process of creating the project’s model begins. The results from the theoretical background research serves as a basis for the model, but also, help from the external supervisor is used in order to complete the model in a way that is satisfactory to Centiglobe as well.
Throughout the coding process of the thesis, integration testing is used. This is done in order to verify the different components of the system, and to verify the full model when implemented. The finished prototype is then validated by measuring the performance of it, and comparing that to the performance of other payment systems. The metric that is chosen for the performance is the execution time of the different components of the system in seconds. The collected data from verification and validation is then analyzed and conclusions are made accordingly.
12 3.2 Potential e-wallets
Four different services are looked into as potential e-wallets in the system. The services are Swish, Venmo, Zelle and PayPal. The preferred aspects of the services are an API that could be used in order to integrate towards the system, and the possibility to do both payments and payouts as a merchant in the service. Moreover, the external supervisor at Centiglobe prefers using Swish as one of the endpoints, since it is widely used in Sweden.
3.2.1 Swish
The Swish API documentation is available to view online. The API supports accepting Swish as payment by using their application, however it does not yet support the possibility to conduct payouts as a merchant. Since Swish is the preferred application of the external supervisor, a decision was made to only conduct transactions in the direction of Swish to another application. [16]
3.2.2 Venmo
Venmo e-wallet is a micropayment method in the U.S, but currently their documentations and API are not available for new users, only for those who already have Venmo integrated into their application.[17] Furthermore, difficulties to create an account are found since the authors are not located in the US. Venmo is therefore discarded as a potential endpoint.
3.2.3 Zelle
Zelle is an American e-wallet which allows users to connect their mobile phone numbers to their bank account to be able to make real time transactions. The service is only for users who are in the U.S and have an American bank account or can link a debit card that is issued by an American bank [18]. Furthermore, Zelle’s current documentation is only available for merchants who are integrating the service for payment purposes, meaning that the service offers methods that
13 enables clients to make payments, but not for merchants to make payouts [19]. Due to these limitations, it is decided that Zelle will not be an endpoint of the system.
3.2.4 PayPal
PayPal offers an API that can accept payments and make payouts as a merchant.[20] However, as previously discussed, PayPal requires fees when sending money between accounts. This was discussed with the external supervisor and the decision was still made to make PayPal the second endpoint of the system.
3.3 Model
The intended prototype of the system contains multiple different components that all must work together. Several components of the system are external components, and the purpose of this project is to find a way to connect them to create a cross platform where two different e-wallets are connected. The external components are the integrated e-wallets servers (Swish and PayPal servers), Centiglobe blockchain, and lastly a client application representing the sender. The challenge is to create two different gateways each representing a different e-wallet which has a merchant test account in order to accept payments from senders or conduct payouts to recipients.
The bigger picture of the project is to provide an API so all these components can easily communicate with each others, with the possibility of the system to support both flexibility and scalability.
14 Figure 3.1: Illustration of system model
Flexibility - the ability to expand or downsize the system by adding or removing more gateways with no effect on the behaviour of system - is one of the reasons why a peer-to-peer distributed system model is chosen in the project. Integrating a new e-wallet can be easily done by making a new gateway which represents that e-wallet, and communicates with the other components of the system using the same API. Thus, adding or removing any gateway from the system will not affect the behaviour of the other gateways. Another reason why this model is chosen is scalability, for larger user capacity.
A client-server architecture could be chosen, but such an architecture does not provide the intended flexibility and it is less scalable compared to a peer-to- peer system. Thus, a peer-to-peer distributed system is chosen. Ideally in a fully developed system, all gateways should support payIn (accept payments from senders) and payout (conduct payouts to recipients) features. Since this paper is only researching the possibility of implementing such a system, there are only two e-wallets implemented.
15 There are both the Swish gateway which only supports payIn functionality and the PayPal gateway which only supports payout functionality, the functionalities of these two gateways are explained in further details in chapter 4.
3.4 Integrated Technologies
The system contains two different gateways, each gateway will act both as a server and as a client in order to connect the other components of the system. The components are the client application, the blockchain and the servers of the integrated e-wallets (Swish server and PayPal server). To build the gateways, the authors choose to use frameworks that will facilitate the work of the development process and provide a more consistent system.
Spring Boot is chosen to represent the server-side of the gateways. Spring Boot is a Java open source framework which was created by the Pivotal Team. It is used to create stand-alone spring server applications which provide REST APIs. The advantages that they advertise is that Spring Boot is easy to learn and use which leads to increased productivity and reduces development time. The server-side is used to provide REST services to the client application. [21] See figure 3.1.
Retrofit is chosen to represent the client-side of the gateway. Retrofit can be used with Java and Android in order to act as a type-safe HTTP client. Retrofit simplifies the process of connecting to a REST web service by translating the API into Java interfaces. The client-side is used to access REST services in the e- wallets servers, Swish and PayPal. [22] This is also illustrated in figure 3.1.
A blockchain API is given by the sponsor to provide an interface for communication with the blockchain. This API allows the gateway to access services in the blockchain. Two main API calls are made, one is used by the Swish gateway to execute a money exchange operation between two currencies with a provided amount. The other call is made by the PayPal gateway to collect the information about the operation called by the sending gateway. One can view this process in figure 3.1.
16 Figure 3.2: Illustration of Frameworks
3.5 Test Bed
To perform the research, all tests are done on the same machine using the same software. Simulations are conducted by running the gateways on the same machine while the blockchain runs on a cloud server. The specifications of the machine used are:
• Operating system: 18.04.2 LTS (Bionic Beaver)
• Linux kernel version: 4.18.0-17-generic
• Processor: Intel® Core™ i5-6200U CPU @ 2.30GHz × 4
• Java version: 11.0.2 2019-01-15 LTS
• IDE and version: IntelliJ 2019.1 (Ultimate Edition)
The programming language that is used to write the code for the gateways in the prototype is Java. Also, the most important java libraries used are: OkHttp3, google.Gson, math.BigDecimal and retrofit2. Finally, Excel is used to generate graphs for the analysis on the results.
17 3.6 Testing and Data Collection
The system is tested in order to verify that it is implemented as intended. Firstly, the communication between the multiple components are tested to ensure that the functionalities of the different modules are implemented in a manner which is reliable and consistent. This is done by integration testing. When this is completed, the whole system is tested with test cases. The two test processes are described in more detail below.
3.6.1 Integration Testing
In order to ensure that the system is implemented correctly, the communication between the components are tested, with an integration testing strategy.
The client application calls services inside the gateways to trigger the different steps of the work flow. These steps are direct communications between the gateway and other components, such as e-wallets servers and the blockchain. All the communications between the client app and the gateways are referenced as main communications, and the communications between the gateways and the e-wallet servers and the blockchain are referenced as sub-communications. The system is considered to be verified if all the main communications are verified. The main communications are verified if all the sub-communications are verified.
The Swish gateway for example receives calls from the client application to perform a payIn operation (a payment coming to the system) using Swish. The Swish gateway is responsible for communicating with the Swish server and the blockchain to complete the operation, and to notify the client application about the status of the operation, where the status of the operation can be success or fail. There are two main communications between the client application and the Swish gateway, there are two sub-communications between the Swish gateway and the Swish server, and lastly, one sub-communication between the Swish gateway and the blockchain, all these communications are discussed in more details in chapter 4. Thus, this part of the system requires five integration tests.
18 Similarly, the PayPal gateway receives calls from the client application to perform a payout operation (a payment going out of the system). The PayPal gateway is responsible for communicating with the PayPal server and the blockchain. There are two main communications between the client application and the PayPal gateway, two sub-communications between the PayPal gateway and the PayPal server, and one between the PayPal gateway and the blockchain, all these communications are discussed in more detail in chapter 4. Thus, this part of the system also requires five integration tests.
By combining the two parts of the system, a total of ten integration tests are conducted in order to verify the communication between the components of the system. All integration tests are conducted in a similar manner, and iterated 30 times each. A test is considered successful if, and only if, the response from the tested call is identical to an expected response, in all 30 iterations. The expected responses of the sub-communications are based on the information provided by the Swish API documentation, PayPal API documentation and the blockchain API documentation. Some of the responses may contain some randomness, for example a unique generated ID, which cannot be predicted. However, these fields in the responses are compared to generated IDs from other responses and the test is considered successful if all IDs are unique.
Integration tests of the main communications, are conducted in a similar manner, the only difference is that the expected responses are based on the API designed specifically for this prototype. Data is collected throughout the testing process. The data that is collected during the integration tests is the number of successful tests and the number of total tests.
Below is an example of a integration test of the Swish gateway communicating with the Swish server to create a payment request in the Swish system.
19 Request Sent
POST: https://mss.cpc.getswish.net/swish−cpcapi/api/v1/paymentrequests Headers : Content−Type: application/json Body : { ”payeePaymentReference” : ”0123456789”, ”callbackUrl” : ”https://somedomain.com/callback”, ”payeeAlias” : ”1231181189”, ”amount” : ”100”, ”currency” : ”SEK”, ”message” : ”message” }
Expected Response
Headers : Location: https://mss.cpc.getswish.net/swish−cpcapi /api/v1/paymentrequests/RANDOM_ID Server: nginx/1.12.1 Connection: keep−a l i v e PaymentRequestToken : RANDOM_TOKEN Content−Length : 0 Date : TODAY_DATE
Actual Response
Headers : Location: https://mss.cpc.getswish.net/swish−cpcapi /api/v1/paymentrequests/C01438B476CC42A185CE423336104598 Server: nginx/1.12.1 Connection: keep−a l i v e PaymentRequestToken: 6d91b0bb2698416e906f014a7b71ff9d Content−Length : 0 Date: Mon, 20 May 2019 15:42:06 GMT
20 3.6.2 System Testing
When the integration testing is completed, the next step is to conduct system testing by simulating a transaction from a Swish account to a PayPal account. As stated in the delimitations, the prototype would not be handling any real transactions from real accounts, but only test accounts and transactions. This is due to the fact that there are no financial resources provided to this project. Furthermore, both Swish and PayPal require a merchant licence in order to accept real payments or conduct real payouts.
The Swish gateway uses Swish’s own test environment to test the communication. The environment is called Merchant Swish Simulator or MSS and requires the same API calls as one would use in a real case, but the url endpoint is different [23]. The PayPal gateway uses sandbox accounts, which can perform transactions like a real account, except there are no real transfers conducted. The tests that are conducted on the initial prototype are a test-driven simulation.
The test is considered successful if the specified PayPal sandbox account receives an expected amount of money sent by the sender. The test is iterated 50 times in order to ensure that the collected data is truthful and reliable. The data which is collected is the number of tests and the number of successful tests.
3.6.3 System Validation
In order to validate the performance of the implemented system, the execution time is measured. Since the system is running on multiple machines, the total execution time is calculated by dividing the whole system process into components, and measuring the component’s execution time individually using the Java function System.nanoTime(). The measured components will be the four main communications of the system. The total execution time is then estimated by adding up the different components average execution time. In the measurement, two time values are collected per component, at the start of the call and at the response. The difference between the time values will be considered as the execution time for that component.
21 In a real life situation the sender needs to interact with the client application to start a payment by entering an amount and the recipient information. The sender also needs to approve the payment in order to complete the operation by following steps in the Swish and BankID apps. To automate these operations and collect data, a script is used to simulate a sender using the client application. The script makes the same request calls as when the user makes a payment from Swish to PayPal.
The time of the step where the sender should approve the payment should not be included in the time measurements. This step is also automated through the use of the Swish API. When creating a Payment request calling the Swish API test server (MSS), the server responds with payment request information, and considers the payment paid immediately, thus there is no need to actually simulate a real life scenario where the user has to approve the payment in the Swish system. For the payout gateway there are no need for either the sender or recipient to interact, so it is easily automated by the system. Each component is measured 50 times and values such as minimum and maximum are collected and average time and standard deviation are calculated.
3.7 Data Analysis
A potential full implementation which connects different e-wallets is considered feasible if, and only if, all integration tests are passed for the different components in the system. The system is also validated by comparing the execution time of a payment that uses test cases with the execution time of a payment in other payment systems. If the conclusion that there is a feasible complete implementation which answers the research question is found, it will also be concluded that Centiglobe’s full system which connects e-wallets in N*N directions is plausible.
22 4 Design and Implementation
This section contains a description of the developed software for the initial prototype. The individual components are first introduced, with a description of the full system work flow following.
4.1 API Design
For the implementation, an API is designed in order to structure the communications between the client application and the gateways. In the full system which Centiglobe is building, each gateway should be able to handle these API calls. Each gateway has a different implementation depending on the corresponding e-wallet, but the functionality should remain the same for these API calls among the gateways. This means that in a full working system, gateways should have both payIn and payout functionalities, and the client application should be able to call any of the main communication methods using these API calls. The execution time of these calls is measured in order to validate the system. The API calls implemented are described individually below. startPayout - This API call is implemented with the purpose of asking a gateway if a specified user exists as a user in the gateways corresponding e-wallet and return an unique ID for the payout. This is done because the system should not start the payout, unless the user exists in the receiving e-wallet. Since the distributed system is run on different machines, there is no other way for the sending gateway or client application to know if the user exists in the receiving e-wallet. However, PayPal does not support for verifying a user. Therefore, the step where the gateway communicate with the PayPal server is not executed in the initial prototype, but should be included in a complete product. The startPayout call is illustrated in figure 4.1.
23 Figure 4.1: Illustration of startPayout call startPayIn - The API call startPayIn is called from the client application to the sending gateway (Swish in the implementation), in order to initiate a payment to the sending e-wallet. In the prototype, the client application calls startPayIn in the Swish Gateway, which communicates with the Swish server in order to get a payment token which can be used to open the Swish application and pay the specified amount. This call requires information like the amount of money to send and the sending user’s identification. See figure 4.2.
Figure 4.2: Illustration of startPayIn call completePayIn - When the user completes the payment to the sending e- wallet, the client application notifies the sending gateway by using the API call completePayIn in the gateway. This API call makes the sending gateway verify that the payment was successful with the corresponding service API. The last step is that the sending gateway uses the blockchain API calls in order to conduct the virtual transaction and sends a verification to the client application. The process can be viewed in figure 4.3.
24 Figure 4.3: Illustration of completePayIn call completePayout - When the client application receives the verification after completing completePayIn, it needs to request a payout from the receiving gateway. This is done by the API call completePayout in the receiving gateway. This call should contain information about the blockchain operation and the destination user’s identification. See figure 4.4.
Figure 4.4: Illustration of completePayout call
4.2 Transaction Handling
As stated in the section delimitations, there is no real money transaction in the implementation. However, the prototype still simulates the transaction of the virtual currencies contained in the blockchain which would be a part of a complete system. There are three virtual currencies involved in the transaction of the
25 system. Firstly, there is a virtual currency which is representing the Swedish Crown, this currency should convert 1-1 to the Swedish crown. This currency is referred to as Swish.SEK. The second virtual currency involved in the project is the core currency of the Centiglobe blockchain system, this currency is referred to as CORE. The last virtual currency that is be used in the project represents US Dollar, and should convert 1-1 to the US Dollar. This last currency is referred to as PayPal.USD.
When a transaction is to be made in the system, the Swish gateway asks the blockchain for a currency exchange from its own currency Swish.SEK to PayPal.USD, owned by the PayPal gateway. The blockchain will use its own CORE currency as the intermediate currency for the exchange. The process is illustrated in figure 4.5
Figure 4.5: Illustration of Virtual Transaction
This process is however not part of this project. In the prototype, the gateways only uses the blockchain’s API, which conducts the money exchanges. The amount received is directly connected to the behaviour of the blockchain, and since the blockchain is still under development and not connected to the real market, a simulation of real traders provided by Centiglobe is used.
The simulation guarantees trading with 1 to 1 factor at a fixed rate for testing purposes. This means that the trading through the blockchain will be as trading currency A to crypto-core, then crypto-core to currency B, where both currencies A and B have the same value, and a fixed 1 percent of the amount is lost through the trading, which means sending 10 SEK will give 9.9 USD. In real life, currencies will have their market value, and trading might result a loss or profit in the amount.
26 4.3 Gateway Implementations
Two gateways are implemented in this project. The first is the Swish gateway which handles a payment from the user using the Swish application. The second gateway is the PayPal gateway which conducts the payout to a specified PayPal account. The two gateways are described in more detailed below.
4.3.1 Swish Gateway
This gateway is responsible for all communication with the Swish server in order to create and handle a payment. All data flow for startPayIn and completePayIn is sent through this gateway. In order to use Swish as a payment option in any application, one needs to use their API calls with HTTPS and a provided certificate attached. Since no merchant licence is acquired, no certificate is available either. However, if the application uses the MSS[23], it can use a fake certificate which is also provided by Swish and used for testing purposes.
The first step of using Swish as payment is creating a payment request. This is done by sending a POST request object to the Swish server. This gateway manipulates the data coming from the client app and constructs the request object to be sent to the Swish server. The object requires information like amount, callbackUrl, payeeAlias, currency and more. When the request object is successfully sent, the Swish server responds with the ID of the payment and a unique token called ”PaymentRequestToken”. This token can be used in the client app in order to switch to Swish application and populate the app with the right amount and recipient.
Once the payment is done in the app, the method completePayIn is called from the client app. This call triggers two tasks in the Swish gateway. The first task is to verify the status of the payment through a communication with the Swish server. The second task is to communicate with the blockchain which will handle the currency exchange and return an ID for the blockchain money exchange operation.
27 4.3.2 PayPal Gateway
This gateway mainly handles the payout part of the transaction. Both methods startPayout and completePayout are handled in this gateway. When the client app wants to transfer money from Swish to PayPal, the app calls startPayout which verifies the recipient and generates a unique ID for the payout.
After the work of the PayIn gateway is done (Swish in our case), the recipient’s information and the ID of the blockchain operation is sent to this gateway. A communication with blockchain takes place to get the right amount of the USD should be sent to the recipient’s account. Once the amount of the payout is retrieved from the blockchain, a series of communication with the PayPal server is executed. First, in order to do any kind of communication with the PayPal server, it requires the client to authenticate themselves. This is done by asking for an auth token by exchanging an ID and password with the server. PayPal uses OAuth2.0 to handle this.[24] Once the token is acquired, a request is sent to create a payout. Lastly, a verification request which makes sure that the payout has been conducted is sent. By sending the verification, the PayPal server verifies that the transaction has been successful. The gateway then responds to the completePayout request, notifying the client app that the payout is successful.
4.4 System Work Flow
The built system is implemented to be a simulation of a transaction where the user intends to send money to a PayPal account, using the Swish e-wallet. A full illustration of the system work flow can be found in figure 4.6, and a brief description of every step in table 4.1. The first step in the simulation, after the user specifies the destination account and amount, is that the client application calls startPayout in the PayPal gateway. This makes sure that the account exists in the PayPal e-wallet and returns a unique payout ID. The next event that occurs in the system is that the client application calls startPayIn in the Swish gateway. This method POST:s a HTTPS payment request to the Swish server using Retrofit and the Java library OkHttp3. The Swish server then creates the payment request and returns a token. This token is forwarded to the client application and used to
28 open the Swish application which handles the payment and identifies the user using BankID. When the payment is completed, the Swish gateway is notified by the client application with completePayIn, and the gateway verifies this with the Swish server. The next step that the Swish gateway does is to call the blockchain API which performs the transaction. A more detailed description of the transaction can be found in the section Transaction Handling.
When the Swish gateway receives the confirmation from the blockchain considering the transaction, the gateway responds to the completePayIn which was previously called by the client application. The client application can then proceed with calling completePayout in the PayPal application which initiates the payout in the PayPal gateway. The first thing that the PayPal gateway does when completePayout is called is to check that it has received the funds in the blockchain system. When this has been confirmed, the PayPal gateway initiates the communication with the PayPal server. The PayPal gateway sends a request for an OAuth2.0 token to the PayPal server, which is used to authenticate the gateway. After the PayPal server responds with the token, the PayPal gateway sends another request to the server, this time to make a payout to the recipient. When the payout is conducted and the PayPal gateway has received the verification from the PayPal server, it responds to the completePayout call from the client application as a verification.
4.5 Potential Failures
Since the project does not contain any error or case handling, there are quite many potential failures in the system. Technical errors might occur in the gateways, the blockchain, the client application and the integrated e-wallet servers. These potential errors are not handled in the current version of the system. For example, if the payout fails for any reason, there is not any case handling which would refund the user, which would be required in a complete implementation since the user already has completed the payment. One could also take advantage of the vulnerabilities in the system by for example eavesdropping, masquerading and message tampering.
29 Figure 4.6: Illustration of system flow
30 Table 4.1: Steps of Figure 4:2
Step 0 Client chooses to send money from Swish to PayPal Step 1a Client APP calls startPayout in PayPal gateway Step 1b PayPal gateway responds with payout ID Step 2 Client APP calls startPayIn in Swish gateway Step 3a Swish gateway POST:s payment request to Swish API Step 3b Swish server creates and returns payment request Step 4 Swish gateway responds to startPayIn (2) including Swish token Step 5a Client APP opens Swish using Swish token Step 5b Swish application identifies user using BankID Step 5c Swish transaction is successful, user is directed back to Client APP Step 6 Client APP calls completePayIn in Swish gateway Step 7a Swish Gateway asks for verification from Swish server Step 7b Swish server responds with verification Step 8a Swish Gateway makes API call to blockchain to conduct transaction Step 8b Blockchain verifies transaction Step 9 Swish gateway responds to completePayIn(6) Step 10 Client APP calls completePayout in PayPal gateway Step 11a PayPal gateway checks that it has received funds in blockchain Step 11b Blockchain verifies that funds were transferred Step 12a PayPal gateway request OAuthToken from PayPal server Step 12b PayPal server responds with OAuthToken Step 13a PayPal gateway requests to make payout to recipient Step 13b PayPal server verifies payout Step 14 PayPal gateway responds to completePayout (10) with verification
31 5 Results
This section contains the results from the tests run on the prototype. Firstly, the results from the integration tests are presented in table 5.1. Subsection 5.2 contains the results from the system testing and the system validation.
5.1 Integration Test Results
An integration testing strategy is used throughout the project in order to modularize and verify the system’s functionality. The integration tests are implemented differently, but with the same functionality. All tests are run on the same machine.
Moreover, the API calls startPayIn, completePayIn and completePayout contains multiple sub-communications. For example, completePayIn will retrieve payment status from Swish (test 4) and buy core from blockchain (test 5). The calls are therefore tested after the corresponding sub-communications are passed, in order to ensure that the full method worked like it was designed.
On the final prototype a total of 300 tests were conducted, 30 iterations per integration test, with all 300 resulting in a pass. The results from the integration tests can be found in table 5.1. The tests were conducted in the order of which they are presented in the table, starting with test number 1 and finishing with test number 10.
32 Table 5.1: Results of integration tests
Test Test Name Result
Pass 1 startPayout
Pass 2 Swish Payment Request
Pass 3 startPayIn
Pass 4 Retrieve Payment Status From Swish
Pass 5 Money Exchange Through Blockchain
Pass 6 completePayIn
Pass 7 Blockchain Check Funds Transferred
Pass 8 PayPal Get OAuthToken
Pass 9 PayPal Create Payout
Pass 10 completePayout
33 5.2 System Test Results
The functionalities of the system are tested in order to verify it. 10 SEK are sent from the client application and data are collected on how much money was received in the PayPal sandbox account. This simulation was repeated 50 times. The tests are considered successful if 9,9 dollars ends up in the recipient account, in all 50 iterations, since the trading factor is 1:1 with fixed rate.
In all 50 of the simulations, it was found that 9,9 dollars ended up in the recipient sandbox account. The functionality testing was therefore considered successful.
5.3 System Validation
As stated in the methodology section, simulations of creating a payment from a Swish account to a PayPal account in the system run 50 times and the execution time of each of the four main components is collected in each run.
34 The first part of the simulation is startPayout. The measurements on the component show a minimum value of 0,00361 s, a maximum value of 0,05546 s, an average value of 0.01129 s and a standard deviation 0,00877 s. The exact measured values in each simulation can be found in table 1 in the appendix. A graphical representation of the data showed by the graph below:
Figure 5.1: Time Measurements From startPayout
Minimum Value: 0,00361 s
Maximum Value: 0,05546 s
Average Value: 0,01129 s
Standard Deviation: 0,00877 s
35 The second part of the simulation is startPayIn. The measurements on the component show a minimum value of 0,25228 s, a maximum value of 2,18086 s, an average value of 0.51482 s and a standard deviation 0,46756 s. The exact measured values in each simulation can be found in table 2 in the appendix. A graphical representation of the data showed by the graph below:
Figure 5.2: Time Measurements From startPayIn
Minimum Value: 0,25228 s
Maximum Value: 2,18086 s
Average Value: 0,51482 s
Standard Deviation: 0,46756 s
36 The third part of the simulation is completePayIn. The measurements on the component show a minimum value of 9,65721 s, a maximum value of 53,7834 s, an average value of 24.67519 s and a standard deviation 14,48008 s. The exact measured values in each simulation can be found in table 3 in the appendix. A graphical representation of the data showed by the graph below:
Figure 5.3: Time Measurements From completePayIn
Minimum Value: 9,65721 s
Maximum Value: 53,7834 s
Average Value: 24,67519 s
Standard Deviation: 14,48008 s
37 The last part of the simulation is completePayout. The measurements on the component show a minimum value of 6,81883 s, a maximum value of 12,02098 s, an average value of 8.2507 s and a standard deviation 1,11634 s. The exact measured values in each simulation can be found in table 3 in the appendix. A graphical representation of the data showed by the graph below:
Figure 5.4: Time Measurements From completePayout
Minimum Value: 6,81883 s
Maximum Value: 12,02098 s
Average Value: 8,2507 s
Standard Deviation: 1,11634 s
38 6 Conclusions and Discussion
Here, the conclusions based on the results of the project are presented. The conclusions answer the research question and illuminates what the project has contributed to. These are followed by a discussion about the project which elaborates on the project’s debatable aspects. Lastly, the authors give some final words of the thesis, and evaluate the implementation accordingly.
6.1 Conclusions
By passing all of the 10 integration tests and the system tests which were implemented and conducted, it is demonstrated that there is a feasible solution to cross-platform micropayments using e-wallets. This is concluded since all of the communication between the components within the system are working as implemented, since they passed the corresponding integration tests. Furthermore, since the system also passed the system functionality testing, the functionality of the system is also verified. This means that the system works as intended and it is reliable since it has deterministic and continuous results, which indicate that the code has been implemented in a structured, logical and correct manner.
The performance measured for the system validates the implementation. The total execution time is considered as the sum of the averages execution time of the different components of the system. This sum is 33,452 seconds. The prototype meets the customer needs since the measured execution time is in seconds. The implementation competes with other instant payment methods, but also beats other global payment methods which could take days until a transfer is completed. It is therefore concluded that the implemented initial prototype is validated.
By verifying and validating the system, it is also concluded that there is a feasible solution which connects two different e-wallets, in order to create global, instant peer-to-peer micropayments. The two technologies Swish and PayPal are also concluded to be compatible when it comes to integrating towards the system.
39 A solution can be based upon the system which was implemented in this project, but the authors also believe that there are other potential solution which could create the same behaviour and functionality. In order to create a complete system however, there are a lot of functionality which needs to be implemented, more about this in the section Future Work below.
Since it is concluded that there is a feasible solution which connects two e-wallets, it is also concluded that the system which Centiglobe is building is feasible. This is concluded since more gateways could be added with the same functionality, without having to change this system implementation. By using the designed API, it would not matter which gateway is the endpoint. This would create N*N potential directions of transactions, where N is the number of integrated e-wallets in the system and also assuming that all gateways provide payIn and payout functionalities.
6.2 Discussion
If there would be a full system, where there are multiple different e-wallets integrated, peer-to-peer microtransactions would thrive, since they could be used in a big variety of ways, both locally and internationally. Furthermore, it would open up a lot of opportunities. For example, by integrating towards the full system, it would enable the user to send money from their e-wallet to any of the other integrated e-wallets in the system. This would mean that for example stores would only need support from one of the integrated e-wallets, which would enable the customers to use whichever else e-wallet in the system to pay.
Some of the time measurements from the simulations show values which greatly differs from the other values. This is easily noticable in figure 5.2, which graphs the measurements form startPayIn. These values are considered outliers. Furthermore, the completePayIn component showed a increasing execution time during the tests. This was because of the current behaviour of the blockchain, which is still under development. The authors believe that a completely developed blockchain would give this component more consistent results.
40 In the implementation for this project, the authors believe that they have tested the prototype enough and in a fair manner, in order to ensure that the data is accurate and truthful. It is not believed that different conclusions would have been made, given other endpoints of integration, or different parameters while testing. However, it should be acknowledged that while developing the system, it was realized how big of a project a full system would be. The prototype which was implemented is merely a happy-case implementation, and a single piece in a much bigger system, which would require a lot more work in order to become complete.
It was realized during the project that there are not only technical challenges with implementing the intended full system. There are many other challenges, and one which the authors wish to illuminate is possibility that PayPal and Swish would not allow a full system to be integrated towards their API by a third party that provides a similar service. This is because for example PayPal would earn the money if they would implement the system themselves, instead of letting for example Centiglobe earn money from integrating their system towards PayPal. Furthermore, PayPal takes a big fee when a person uses their service to send money internationally, which would be lost if one instead chooses to send the money using a system like the one implemented in this project. This is something which should be discussed with the e-wallet provider when one intends to integrate it towards a system like the one implemented in this project.
Considering the goals of the thesis, the goal of creating an initial prototype is completed, since the implemented system is just that. Moreover, the implementation is considered efficient since it in theory is capable of conducting global microtransactions in real-time. If one compares this to other payment services which would conduct a similar transactions in days time, the implementation is considered to be efficient, even though there is still room for improvement.
41 When it comes to the security of the prototype, there are a lot of aspects that still need to be implemented. The prototype which was implemented in this project is not secure, and there are quite many ways to take advantage of the vulnerable parts of the system. The only thing that currently is secure is the blockchain, and the transactions within it. Since the blockchain offers traceable and transparent transactions, the data which the blockchain handles cannot be corrupted easily.
6.3 Future Work
In the area of distributed systems, blockchain, e-wallets and global money transfer, there is a lot of potential future work. Blockchain is a growing technology which the authors believe will be used more and more in the future, since blockchain based systems are transparent, traceable and reliable.
Considering this project however, the full system which Centiglobe is building is what the authors consider future work. Firstly, merchant licences should be obtained and the system should be tested using real transactions. Moreover, the gateways should be running on real servers and not only one machine, this will probably affect performance drastically. Safety and error handling cases should also be implemented in the system. For example, one should consider what happens if the payout fails for any reason, since the user has already transferred money. Another thing that needs to be considered is how the cash flow of the system should be handled. Since the implementation is only able to send money in one direction, the PayPal gateway would run out of funds rather quickly. This is why one needs to consider how to balance the cash flow in a real system.
Moreover, an implementation could be made where one could also transfer money in the direction of PayPal to Swish. This however requires the possibility to make payouts as a merchant in the Swish application. Centiglobe are also developing more gateways which all could have the same role as Swish and PayPal in the system. This would create N*N possible directions of transfer.
42 The potential of such a system is huge, since one could make payments to any e- wallet or service, using any e-wallet. The problem of instant money transferring globally would also be solved, since the blockchain would handle the transactions in the system in real-time.
6.4 Final Words
We hope that our work in this project can be used as a basis for similar projects in the future, and that the conclusions can be used to simplify the work. We have learned a lot during this project, from how blockchain can be integrated into systems, to distributed systems and wire transfers.
If we would do the project again, we would spend less time researching on which would be our potential endpoints, since our conclusions indicate that most endpoints would have worked, using a similar model to the one which we built. We evaluate that the project was successful and that the two technologies are compatible, but that a lot of future work is needed before such a product can be released. This project could be improved further, iteratively, in many areas, but since the work was completed within a limited time scope, the project was limited.
43 References
[1] World Payment Report 2018. Capgemini, BNP Paribas, 2018. URL: https: //worldpaymentsreport.com/wp-content/uploads/sites/5/2018/10/ World-Payments-Report-2018.pdf.
[2] Khan, Burhan Ul Islam, Olanrewaju, Rashidah F., and Baba, Asifa Mehraj. “A Compendious Study of Online Payment Systems: Past Developments, Present Impact, and Future Considerations”. In: (IJACSA) International Journal of Advanced Computer Science and Applications 8.5 (2017), pp. 256–271. URL: https://thesai.org/Downloads/Volume8No5/Paper_ 32-A_Compendious_Study_of_Online_Payment_Systems.pdf.
[3] Frequently asked questions. Accessed 05/04/19. Western Union. URL: https://www.westernunion.com/ie/en/customer- support- topics. html#Q7.
[4] Swish Statistik 2012-2018. Swish, 2019. URL: https://www.getswish.se/ sv-press/statistik/.
[5] George Coulouris Jean Dollimore, Tim Kindberg and Blair, Gordon. Distributed Systems Concept and Design. fifth edition. ISBN: ISBN 13: 978-0-13-214301-1.
[6] Krishna Nadiminti, Marcos Dias de Assunção and Buyya, Rajkumar. “Distributed Systems and Recent Innovations: Challenges and Benefits”. In: ResearchGate (Jan. 2006).
[7] How long does an international wire transfer take? Accessed 12/04/19. TransferWise Team. URL: https : / / transferwise . com / us / blog / international-wire-transfer-time.
[8] Tierney, Spencer. Wire Transfers Explained. Accessed 11/04/19. URL: https : / / www . nerdwallet . com / blog / banking / what - is - a - wire - transfer/.
[9] Olsen, Mia, Hedman, Jonas, and Vatrapu, Ravi. e-Wallet Properties. 10th International Conference on Mobile Business, June 2011, pp.158-165.
44 [10] Jr., Dave Landry. “Digital Wallet: The Future of Pay, and Why You Should Care”. In: (2018). Accessed 11/04/19. URL: https://www.business.com/ articles/digital-wallet-the-future-of-pay-and-why-it-matters/.
[11] B, Singhal, G, Dhameja, and P., Panda. Beginning blockchain. A beginner’s guide to building blockchain solutions. 2018.
[12] Dughi, Paul. A simple explanation of how blockchain works. Accessed 15/04/19. mission.org. URL: https : / / medium . com / the - mission / a - simple-explanation-on-how-blockchain-works-e52f75da6e9a.
[13] Backlund, Ludvig. “A technical overview of distributed ledger technologies in the Nordic capital market”. MA thesis. Uppsala Universitet, July 2016.
[14] Atlam, H.F and Wills, G.B. “Technical aspects of blockchain and IoT”. In: Advances in Computers (Dec. 2018).
[15] Barco, Jose M. del. “Master’s Project: Micropayments Platform”. Accessed 25/04/19. MA thesis. 2009.
[16] Swish Merchant Integration Guide. Version 2.0. Swish. Mar. 2019. URL: https://developer.getswish.se/content/uploads/2019/03/Merchant- Integration-Guide.pdf.
[17] Venmo Developer API. Accessed 11/04/19. venmo. URL: http : / / developer.venmo.com/.
[18] Understanding Zelle. Accessed 11/04/19. American Banker Association. URL: https://www.aba.com/Tools/Function/Technology/Documents/ UnderstandingZelle.pdf.
[19] Zelle RESTful API Documentation. Accessed 11/04/19. IBM. URL: https: //www-01.ibm.com/support/docview.wss?aid=1&uid=swg27050366.
[20] PayPal Payouts API. Accessed 11/04/19. PayPal. URL: https : / / developer.paypal.com/docs/api/payments.payouts-batch/v1/.
[21] Spring Boot Documentation. Accessed 25/04/19. Pivotal. 2019. URL: https://spring.io/projects/spring-boot.
[22] Retrofit Documentation. Accessed 25/04/19. 2019. URL: https : / / square.github.io/retrofit/.
45 [23] Swish. User Guide, Merchant Swish Simulator. Version 1.4. Feb. 2019.
[24] OAuth 2.0. Accessed 15/05/19. OAuth. URL: https://oauth.net/2/.
46 Appendices
Here the measured times of the different protocols presented. All values are presented in seconds.
Table .1: Time Measurements for startPayout
Simulation Time Measured Simulation Time Measured 1 0,05546 26 0,01041 2 0,01586 27 0,00432 3 0,0183 28 0,01074 4 0,01546 29 0,00408 5 0,01552 30 0,01089 6 0,03403 31 0,0067 7 0,02252 32 0,00836 8 0,00577 33 0,02088 9 0,01384 34 0,01058 10 0,00689 35 0,00414 11 0,00381 36 0,00549 12 0,01272 37 0,00392 13 0,01549 38 0,00373 14 0,00581 39 0,00382 15 0,0044 40 0,0132 16 0,0116 41 0,00453 17 0,01544 42 0,00901 18 0,01406 43 0,00927 19 0,01385 44 0,00361 20 0,01458 45 0,00462 21 0,01112 46 0,00379 22 0,0108 47 0,0098 23 0,01748 48 0,01032 24 0,01092 49 0,00593 25 0,01236 50 0,00409
Minimum Value: 0,00361 s
Maximum Value: 0,05546 s
Average Value: 0,01129 s
Standard Deviation: 0,00877 s
47 Table .2: Time Measurements for startPayIn
Simulation Time Measured Simulation Time Measured 1 0,27922 26 0,30578 2 0,26866 27 0,27303 3 0,26731 28 0,99736 4 0,32888 29 1,36897 5 0,25228 30 0,39279 6 0,34129 31 0,40847 7 0,31748 32 2,17956 8 0,25294 33 0,32301 9 0,37996 34 0,31942 10 0,34954 35 0,34406 11 0,27286 36 0,27007 12 0,26166 37 0,3742 13 0,30459 38 0,58809 14 0,35665 39 2,18086 15 0,26577 40 0,28509 16 0,27132 41 0,5383 17 0,26785 42 0,53925 18 0,26167 43 0,28243 19 0,28062 44 1,46523 20 0,35329 45 0,35681 21 0,2784 46 0,85357 22 0,32726 47 0,31812 23 0,39391 48 0,5454 24 0,30221 49 1,62458 25 0,31761 50 1,05334
Minimum Value: 0,25228 s
Maximum Value: 2,18086 s
Average Value: 0,51482 s
Standard Deviation: 0,46756 s
48 Table .3: Time Measurements for completePayIn
Simulation Time Measured Simulation Time Measured 1 12,77218 26 16,65681 2 14,18026 27 14,27692 3 12,26179 28 19,5912 4 10,08878 29 37,07527 5 9,91803 30 24,99899 6 9,65721 31 21,05396 7 10,78965 32 29,377 8 10,1403 33 21,36204 9 12,8058 34 21,30094 10 11,352 35 30,69928 11 12,57871 36 24,37809 12 12,00548 37 20,21883 13 11,92078 38 53,58913 14 10,37793 39 38,18756 15 19,48283 40 35,68517 16 12,50813 41 48,51048 17 12,86676 42 49,58647 18 12,6332 43 53,7834 19 17,04913 44 49,21717 20 14,39434 45 48,55132 21 16,15497 46 48,21667 22 19,518 47 35,79008 23 30,14014 48 37,26221 24 22,28093 49 50,71793 25 15,66797 50 50,12749
Minimum Value: 9,65721 s
Maximum Value: 53,7834 s
Average Value: 24,67519 s
Standard Deviation: 14,48008 s
49 Table .4: Time Measurements for completePayout
Simulation Time Measured Simulation Time Measured 1 8,56504 26 8,32988 2 7,4256 27 8,41678 3 9,53926 28 8,99145 4 8,8572 29 7,94664 5 12,02098 30 8,40243 6 8,02464 31 7,70945 7 9,31169 2 7,20072 8 6,82696 33 8,63344 9 8,29446 34 9,12652 10 7,22082 35 6,81883 11 7,56355 36 7,57063 12 8,21201 37 7,88836 13 7,93182 38 7,72742 14 6,94392 39 8,61373 15 6,95444 40 7,81627 16 6,95729 41 7,53702 17 7,14624 42 8,54509 18 7,35042 43 8,47695 19 10,23485 44 11,82154 20 8,56587 45 10,22353 21 7,16889 46 7,65739 22 8,20571 47 8,84801 23 8,07387 48 9,22308 24 8,64271 49 8,20372 25 7,28237 50 7,48547
Minimum Value: 6,81883 s
Maximum Value: 12,02098 s
Average Value: 8,2507 s
Standard Deviation: 1,11634 s
50 51 TRITA-EECS-EX-2019:169
www.kth.se