ADAMA SCIENCE AND TECHNOLOGY UNIVERSITY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTING

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SENIOR PROJECT
Payment Gateway

Group Members ID
Abdulmejid Shemsu………………………………………… A/UR15168/10
Abduselam Hafiz……………………………………………. A/UR14744/10
Fuad Endris ……………………………………………….... A/UR5107/09
Hayat Ahmed ………………………………………………. A/UR15378/10

Advisor: Mr. Anteneh Alemu

June, 2022
Submitted by
Abdulmejid Shemsu ________________________ 2/2/2022

Student signature date

Abduselam Hafiz ________________________ 2/2/2022
Student signature date

Fuad Endris ________________________ 2/2/2022

Student signature date
Hayat Ahmed ________________________ 2/2/2022

Student signature date

Advisor

Anteneh Alemu signature ______________________

Acknowledgment

We have taken efforts in this project. However, it would not have been possible without the kind
support and help of many individuals and organizations. Our first appreciation goes to our advisor
Mr. Anteneh Alemu for his supervision, advice, guidance and continuous support.

Also, our deepest gratitude is in orders for all our friends and the teachers who supported as . They
all have given time and go through the project and helped us when needed.

i
Acronym

➢ MoIT: Ministry of Innovation and Technology

➢ Fintech: Financial Technology
➢ CSS: cascade style Sheet
➢ VSCode: visual studio code
➢ JS: java script
➢ MS- Microsoft word
➢ PHP: hypertext preprocessor
➢ HTML: hypertext mark-up language
➢ DB: database
➢ AWS amazon web service
➢ OPT – One Time Password
➢ 2FA – Two Factor Authentication
➢ API - Application Programming Interface

ii
Table of Contents
Acknowledgment........................................................................................................................................ i
Acronym .................................................................................................................................................... ii
List of Tables ............................................................................................................................................. v
List of Figures .......................................................................................................................................... vi
1. Chapter one ....................................................................................................................................... 1
1.1. Introduction ............................................................................................................................... 1
1.2. Background of the Project ............................................................................................................ 2
1.3. Statement of the Problem ............................................................................................................. 2
1.4. Justification of the Project ............................................................................................................ 3
1.5. Objective of the Project ................................................................................................................ 3
1.5.1. General Objective.................................................................................................................. 3
1.5.2. Specific Objective .................................................................................................................. 3
1.6. Scope and Limitations............................................................................................................... 3
1.6.1. Scope of the Project ............................................................................................................... 3
1.6.2. Limitation of the Project ....................................................................................................... 4
1.7. Feasibility Study ............................................................................................................................ 4
1.7.1. Operational Feasibility ......................................................................................................... 4
1.7.2. Technical Feasibility ............................................................................................................. 4
1.7.3. Economic Feasibility ............................................................................................................. 4
1.8. Significance of the Project ............................................................................................................ 5
1.9. Beneficiaries of the Project ........................................................................................................... 5
1.10. Methodology .............................................................................................................................. 5
1.11. Development Tools .................................................................................................................... 6
1.12. Required Resource with Cost ................................................................................................... 7
1.13. Task and Schedule .................................................................................................................... 8
1.14. Team Composition .................................................................................................................... 8
2. Chapter Two.......................................................................................................................................... 9
2. Description of existing system/ Literature Review ......................................................................... 9
2.1. Major function of existing system ............................................................................................ 9
2.2. Users of current system............................................................................................................. 9
2.3. Drawback of current system .................................................................................................. 10
2.4. Business Rule ........................................................................................................................... 10
3. Chapter Three ..................................................................................................................................... 11

iii
3. Proposed System ............................................................................................................................. 11
3.1. Overview .................................................................................................................................. 11
3.2. Functional Requirements ....................................................................................................... 11
3.3. Non-functional requirements ................................................................................................. 12
3.4. System Model .......................................................................................................................... 12
3.4.1. Scenarios .............................................................................................................................. 12
3.4.2. Use Case Model .................................................................................................................. 15
3.4.3. Use case diagram and description ...................................................................................... 16
3.5.1. Data dictionary .................................................................................................................... 26
3.5.2. Class diagram ...................................................................................................................... 27
3.5.3. Dynamic Model ................................................................................................................... 28
3.5.3.1. Sequence Diagram ........................................................................................................... 28
3.5.3.2. Activity Diagram ............................................................................................................. 33
3.5.3.3. State chart Diagram ........................................................................................................ 38
4. Chapter Four....................................................................................................................................... 40
4. System Design .................................................................................................................................. 40
4.1. Overview .................................................................................................................................. 41
4.1.1. Purpose of the System ......................................................................................................... 41
4.1.2. Design Goal .......................................................................................................................... 41
4.2. Proposed system architecture..................................................................................................... 43
4.2.1. System Process ........................................................................................................................ 43
4.2.2. Subsystem decomposition ................................................................................................... 45
4.2.3. Hardware/Software Mapping............................................................................................. 46
4.2.4. Persistent data management............................................................................................... 47
4.2.5. Component Diagram ........................................................................................................... 51
4.2.6. Database Design .................................................................................................................. 51
4.2.7. Access Control ..................................................................................................................... 52
4.2.8. User Interface Design .......................................................................................................... 53
5. Chapter Five ........................................................................................................................................ 54
5. Implementation ............................................................................................................................... 54
5.1. Overview .................................................................................................................................. 54
5.2. Coding Standard ..................................................................................................................... 54
5.3. Prototype.................................................................................................................................. 54
5.4. Implementation Details ........................................................................................................... 55
5.5. Deployment .............................................................................................................................. 56

iv
6. Chapter Six .......................................................................................................................................... 57
6. System Testing .................................................................................................................................... 57
6.1 Objective ........................................................................................................................................ 58
6.2. Scope ............................................................................................................................................. 58
6.3. Resource........................................................................................................................................ 58
6.4. Roles .............................................................................................................................................. 58
6.5. Schedule ........................................................................................................................................ 60
6.6 Test Case Scenarios and Requirements ....................................................................................... 60
6.6.1 Data and Database Integrity ................................................................................................. 60
6.6.2 Function testing ...................................................................................................................... 60
6.6.3 User interface testing ............................................................................................................. 60
6.6.4. Performance Testing ............................................................................................................. 61
6.6.5 Load testing ............................................................................................................................ 61
6.6.6. Security and Access Testing ................................................................................................. 61
6.7 Estimated Risk .............................................................................................................................. 61
6.8 Contingency plan .......................................................................................................................... 61
7. Chapter Seven ..................................................................................................................................... 61
7.1 User Manual ............................................................................................................................ 62
7.1.1 Authentication ........................................................................................................................ 62
7.1.2 Dashboard............................................................................................................................... 63
8. Chapter Eight .................................................................................................................................. 70
8.1 Conclusion ..................................................................................................................................... 70
8.2 Recommendation........................................................................................................................... 70
References................................................................................................................................................ 71

List of Tables

Table 1. 1 Front end implementation software tools ................................................................................... 6

Table 1. 2 Backend End implementation software tools ............................................................................. 6

v
Table 1. 3 Other software tools ................................................................................................................... 7
Table 1. 4 Required resources and cost ....................................................................................................... 7
Table 1. 5 Team composition ...................................................................................................................... 8

Table 3. 1 Actor identification .................................................................................................................. 15

Table 3. 2 Use case description sign up .................................................................................................... 17
Table 3. 3 Use case description login ........................................................................................................ 18
Table 3. 4 Use case description deposit money ......................................................................................... 19
Table 3. 5 Use case description withdraw money ..................................................................................... 20
Table 3. 6 Use case description send money ............................................................................................. 21
Table 3. 7 Use case description view balance ........................................................................................... 22
Table 3. 8 Use case description view transactions .................................................................................... 23
Table 3. 9 Use case description online payment ....................................................................................... 23
Table 3. 10 Use case description integrate payment.................................................................................. 25
Table 3. 11 data dictionary ........................................................................................................................ 26

Table 4. 1 System property ....................................................................................................................... 42

Table 4. 2 Subsystem description.............................................................................................................. 46
Table 4. 3 Access control .......................................................................................................................... 52

Table 6. 1 Scope ....................................................................................................................................... 58

Table 6. 2 Testing Roles ........................................................................................................................... 59
Table 6. 3 Testing schedule....................................................................................................................... 60

List of Figures

Figure 1. 1 Task and schedule ..................................................................................................................... 8

vi
Figure 3. 1 Use case diagram .................................................................................................................... 16
Figure 3. 2 Class diagram ......................................................................................................................... 27
Figure 3. 3 Sequence diagram of customer and merchant registration ...................................................... 28
Figure 3. 4 Sequence diagram of customer and merchant login ................................................................ 29
Figure 3. 5 Sequence diagram of deposit money....................................................................................... 29
Figure 3. 6 Sequence diagram of withdraw money ................................................................................... 30
Figure 3. 7 Sequence diagram of transfer money ...................................................................................... 31
Figure 3. 8 Sequence diagram of view transaction .................................................................................... 31
Figure 3. 9 Sequence diagram of creating APP ......................................................................................... 32
Figure 3. 10 Sequence diagram of paying online ..................................................................................... 33
Figure 3. 11 Activity diagram of registration ............................................................................................ 33
Figure 3. 12 Activity diagram of login ...................................................................................................... 34
Figure 3. 13 Activity diagram of deposit money ....................................................................................... 34
Figure 3. 14 Activity diagram of withdraw money .................................................................................. 35
Figure 3. 15 Activity diagram of transfer money ...................................................................................... 35
Figure 3. 16 Activity diagram of online payment ..................................................................................... 36
Figure 3. 17 Activity diagram of view transaction .................................................................................... 36
Figure 3. 18 Activity diagram of view balance ......................................................................................... 37
Figure 3. 19 Activity diagram for creating APP ........................................................................................ 38
Figure 3. 20 State chart diagram of registration ........................................................................................ 38
Figure 3. 21 State chart diagram of login .................................................................................................. 39
Figure 3. 22 State chart digram of withdraw money ................................................................................. 39
Figure 3. 23 State chart diagram of transfer money .................................................................................. 39
Figure 3. 24 State chart diagram of online payment .................................................................................. 40
Figure 3. 25 State chart diagram for creating App .................................................................................... 40

Figure 4. 1 Customer overview ................................................................................................................. 43

Figure 4. 2 System process of customers .................................................................................................. 43
Figure 4. 3 Merchant overview ................................................................................................................. 44
Figure 4. 4 System process of Merchant overview.................................................................................... 44
Figure 4. 5 Admin overview ..................................................................................................................... 45
Figure 4. 6 System process of admin ........................................................................................................ 45
Figure 4. 7 System decomposition ............................................................................................................ 46
Figure 4. 8 Hardware/software mapping ................................................................................................... 47
Figure 4. 9 Role mapping.......................................................................................................................... 47
Figure 4. 10 User mapping....................................................................................................................... 47
Figure 4. 11 Transaction mapping ............................................................................................................ 48
Figure 4. 12 Apps mapping ....................................................................................................................... 48
Figure 4. 13 Wallet mapping..................................................................................................................... 49
Figure 4. 14 Card Mapping ....................................................................................................................... 49
Figure 4. 15 RoleHasPermission mapping ................................................................................................ 49
Figure 4. 16 Permission mapping.............................................................................................................. 50
Figure 4. 17 ModelHasPermission mapping ............................................................................................. 50
Figure 4. 18 ModelHasRole mapping ....................................................................................................... 50
Figure 4. 19 Component diagram.............................................................................................................. 51

vii
Figure 4. 20 Database design .................................................................................................................... 51
Figure 4. 21 User interface design ............................................................................................................ 53
Figure 4. 22 Mockup interface .................................................................................................................. 53

Figure 5. 1 How EthSwitch work with our system .................................................................................... 56

Figure 7. 1 Login Page .............................................................................................................................. 62

Figure 7. 2 Registration Page .................................................................................................................... 62
Figure 7. 3 OTP Confirmation Page.......................................................................................................... 63
Figure 7. 4 Customer Dashboard Page ...................................................................................................... 63
Figure 7. 5 Merchant Dashboard Page ...................................................................................................... 64
Figure 7. 6 Send/Transfer Money Page ..................................................................................................... 64
Figure 7. 7 Wallet Page............................................................................................................................. 65
Figure 7. 8 Deposit Page ........................................................................................................................... 65
Figure 7. 9 Activities Page ........................................................................................................................ 66
Figure 7. 10 Merchant APP Create Page ................................................................................................... 66
Figure 7. 11 Merchant APP Detail Page ................................................................................................... 67
Figure 7. 12 Admin Login Page ................................................................................................................ 67
Figure 7. 13 Role Management Page ........................................................................................................ 68
Figure 7. 14 Admin 2FA Creation ............................................................................................................ 68
Figure 7. 15 Github Repo.......................................................................................................................... 69

viii
1. Chapter one
1.1. Introduction

A payment gateway is a service that offers an electronic payment by a variety of payment methods
such as credit card, bank-based payments such as bank transfer, and real-time bank transfer based
on online banking. A payment gateway can be provided by banks to their customers or it can be
provided by a specialized financial service provider as a separate service.

A payment gateway can connect to multiple acquiring banks, cards, and payment networks. In
many cases, the payment gateway will fully manage these technical connections, relationships with
the external network, and bank accounts and therefore takes care of the technical processing of
payment methods for online shops. [1]

So, in general speaking, a payment gateway is a tool that securely validates your customer's credit
card details, ensuring funds are available for you to get paid. The payment gateway works as the
middleman between your customer and the merchant. It lets your customer submit their credit card
details and then securely passes this information from the customer to the merchant and then
between the merchant and the bank, ensuring the transaction is carried out securely and promptly.
An online payment gateway can simplify how merchants integrate the necessary software. As the
middleman during the payment processing, the gateway manages the customer’s sensitive card
details between the acquirer and the merchant. [2]

Different countries have different ways of supervision on their financial institutions. In Ethiopia
financial institutions are supervised by National Bank of Ethiopia, since online payment or
payment gateways are categorized under financial technology institutions (or fintech) they are also
monitored by National Bank of Ethiopia. In Ethiopia for fintech to get a license they have to get
approval from the Ministry of Innovation and Technology (or MoIT).

There are lots of payment gateways in our world. Such as PayPal, Stripe, and so on. Coming to
our country, financial companies like yenepay are engaged in providing a payment gateway.

The system we are going to develop is a payment gate way that works by integrating with ethswitch
for accessing user bank account and making transactions easy for our users.

1
1.2. Background of the Project

By the mid-’90s arrival of the internet, new business models arose which demanded a new kind of
payment method, one that could meet the needs of internet-based businesses. That meant the
beginning of the companies known as payment gateways, such as PayPal, Braintree or Stripe
Square. They revolutionized not only the evolution of payments, but it also meant a turning point
in the e-commerce industry.
Electronic payments quickly became the new face of payments and people started to relay on e-
payments, thus, making payment gateway a common term. In 1994, Amazon, one of the e-
commerce pioneers was founded. One year later eBay is launched and Pizza Hut starts accepting
online food ordering. The need for cheap electronic payment acceptance services fostered the
evolution of the payments industry. [3]

Coming to our country, Even though there are some online payment methods in our country, most
of them are provided by the bank to its customers. For instance CBE allow customers to pay their
different bills online. But this kind of service is only provided from a single bank. Even if there is
a specialized financial service provider as a separate service unlike the banks, for instance
companies like yenepay charge very high transaction fee. There is also Telebirr which charge low
transaction fee but customers cannot deposit to their account directly...plus there have been
numerous bug report on their mobile app (according to Telebirr users comment on the official
Telebirr Google play page).

1.3. Statement of the Problem

Beside the need for more payment gateways in our country there are also problems on the existing
once. This project focuses on solving the following problems:
➢ Charges a lot per transaction.
➢ Security issue.
➢ Can’t pay online.
➢ High down time.
➢ Rolling back transactions.
➢ Process transaction till the end and notify the user as it is done successfully while it already
fails.

2
1.4. Justification of the Project

➢ Building a system that costs less per transaction for users.

➢ Minimize downtime as much as possible.
➢ Fix errors that terminate transactions as fast as possible.
➢ Provide an online payment service.
➢ Make customer data and transactions secure.
➢ Notify the user if there is a problem during transactions.

1.5. Objective of the Project

1.5.1. General Objective

The general objective of our project is to design and develop a web based payment gateway.

1.5.2. Specific Objective

In order with achieving the general objective the following specific objectives will achieved:

➢ Design a payment gateway system.

➢ Implement our system using the appropriate tool.
➢ Integrate the system with ethswitch.
➢ Provide an API for third party service provider (example merchants)
➢ Enable users to pay online for their services using our system.
➢ Test the system using different methods
➢ Deploy the system

1.6. Scope and Limitations

1.6.1. Scope of the Project

The scope of our project is building a payment gateway system for users that have an Ethiopian
bank account.

3
1.6.2. Limitation of the Project

➢ The system doesn’t work without the internet.

➢ Doesn’t have a local language version.
➢ It is only designed for Ethiopian banks.

1.7. Feasibility Study

1.7.1. Operational Feasibility

Since our system is a web-based application, anybody who has an internet service can access our
system easily and due to the understandable nature of the system anybody can register and use the
system easily.

1.7.2. Technical Feasibility

Our system is going to be implemented using PHP framework Laravel and we are also going to
use a relational database system which is called MariaDB. Since every tool we are going to use is
open source and available it is technically feasible.

1.7.3. Economic Feasibility

There are several reasons that make our system economically feasible. Firstly there is no need to
setup branch banks. In terms of customer base expansion only marketing and server cost (Using
services like AWS will save us a lot of money rather than build our own server, since our server
billing will be metered or based on our usage and traffic). We also don’t need to hire lots of
employees like banks to serve customers, this intern saves money. No need to print customer
account books and other related items only online system.

4
1.8. Significance of the Project

Here are some significances of our project:

➢ Saves time for the user: users will no longer wait for longer queues to withdraw
money from banks.
➢ Secured customer data.
➢ Quick payment method.
➢ Increase the convenience of making payments by enabling them to be made
swiftly and remotely from various devices connected to networks
➢ Credibility for the merchants: The merchant receives the money without any
fear of losing money or cheque bounce.
➢ Increase payment efficiency by reducing transaction costs.

1.9. Beneficiaries of the Project

➢ End User: might have a busy life for going shopping, waiting for bank queue etc..,
and our system eliminates such problems.
➢ Third Party Service Provider: could use our system to interact and accept payment
from their customers. Example of service providers
❖ Ecommerce websites
❖ Bill payment service providers

1.10. Methodology

Before implementing our system to make it easy for us we will start by designing each part of the
system. I.e., the database model, class diagrams, subsystem decomposition and so on that are
mentioned and depicted in detail in our documentation. Based on these designs we are going to
implement the system using the development tools that we mentioned in this documentation.
After starting our implementation, we are going to use the unit test method for checking frequently
if our code works properly. We will also build a system like ethwitch and bank for showing the
functionality of our system. We also planned to build third party service provider like ecommerce
for testing our system functionality.
Since our system is modularized, we will make integration testing when we integrate each
component. We will also make security testing to ensure that our system is free from any type of
treats.

5
1.11. Development Tools
While developing the project starts from each phase of documentation to the end, we will use the
following tools.

➢ Hardware
o Personal Computers
o Flash Drive

➢ Software tools

Table 1. 1 Front end implementation software tools

Tools Abbreviation Use

Hypertext markup HTML5 For front end display.

language
Cascade Style Sheet CSS3 For layout design, content decoration
in user interface design and to give the
style of the interface.
Tailwindcss (CSS Tailwindcss For CSS manipulation.
Framework)
JavaScript Js For Client-side manipulation.
AlpineJs Alpinejs To manipulate html Dom for a
reactiveness.

Table 1. 2 Backend End implementation software tools

Tools Abbreviation Use

Hypertext preprocessor (PHP) PHP 8.1 For Backend implementation.

Maria Database MariaDB 10.1.36 For database.

XAMPP XAMPP As a web server solution stack
package consisting mainly of the
Apache HTTP server, MariaDB
database, and interpreters for scripts
written in the PHP
Laravel (PHP Framework) Laravel For Backend implementation.

6
Table 1. 3 Other software tools

Tools Abbreviation Use

Enterprise Architect - To designing the project.

Microsoft word MS Word For documentation.

VScode Visual Studio Code For code writing.

Browser (chrome) - To view our system.

Adobe XD - To design our view.

Mysql Work Bench - To design database schema.

1.12. Required Resource with Cost

Table 1. 4 Required resources and cost

Material name Number of materials Price per unit Total price

Laptop 1 22,000 22,000
Flash 8GB 1 80 80
Airtime 10 10 100
Pen 4 10 40
Total cost of material - - 22,220 birr

7
1.13. Task and Schedule

Figure 1. 1 Task and schedule

1.14. Team Composition

Table 1. 5 Team composition

Name Id Email Responsibility

Abdulemjid A/ur14447/10 abdudlh1@gmail.com Backend developer
Shemsu
Abduselam Hafiz A/ur15168/10 abduselamhafiz@gmail.com Backend developer
Fuad Endris A/ur5107/09 Fudi1723@gmail.com System Integrator
Hayat Ahmed A/ur15378/10 hahmedayat@gmail.com Frontend developer

8
2. Chapter Two

2. Description of existing system/ Literature Review

2.1. Major function of existing system

The existing system function as follows:

Creating Bank Account

The current payment process follows the following steps

➢ Customers come to the bank and create an account.
➢ The bank teller checks the form filled by the customer and creates an account for the
customer by adding the customer to the bank database.
➢ The bank teller gives a bank book to the customer.
Sending Payment

➢ In order for a customer to send a payment they have to bring their bank book and fill the
form prepared for sending a payment
➢ If they use mobile banking, they can make their payment using their mobile phones.
➢ If the sender uses other online payment methods like telebirr or yenepay he/she can make
their payment through those services.
Deposit Money

➢ In order for a customer to deposit money they have to bring their bank book, money and
fill the form prepared for depositing payment.
➢ If the customer wants to deposit money in their telebirr account they can transfer money
from their bank account to their telebirr account.

2.2. Users of current system

➢ Customers
o Send payment to another customer.
o Deposit money.
o Receive money from another customer.

➢ Banks
o Create an account for customers, provide a bank book.
o Accept payment from the user.
o Use the bank book or Kebele identification to perform the transaction
requested by the customer.

9
2.3. Drawback of current system

The current system has the following drawbacks:

✓ Some of them cost a lot per transaction

✓ Some has security issue
✓ Doesn’t allow online payment.
✓ Some have high down time.
✓ Rolling back transactions.

2.4. Business Rule

The following are business rules of the system according to BANKING BUSINESS
PROCLAMATION NO. 592/2008 [4]

✓ The minimum amounts of capital and reserves to be maintained by banks and the rules for
their computation shall be determined by the directive to be issued by the National Bank.
✓ The National Bank may prescribe different capital and reserve requirements to be
maintained by different banks depending on their risk profile.
✓ Where the National Bank considers that the capital of a bank is below the prescribed
minimum, it shall require the bank to take, within a specified period of time, measures
necessary to rectify the situation.
✓ No bank may at any time declare, credit the account of, or pay to shareholders any dividend
until all impairments of its capital, as determined by the National Bank, have been
removed.
✓ Any bank shall, at the end of each financial year, transfer to its legal reserve account a sum
of not less than 25 percent of its net profit.
✓ Notwithstanding the provisions of sub-article (1) of this Article, when the legal reserve
equals the paid-up capital of the bank, the amount to be retained by the bank as a legal
reserve from the net profit each year shall be determined by the directives to be issued by
the National Bank.
✓ The National Bank may, by directives, specify the circumstances under which the legal
reserve account may be reduced.
✓ Maximum withdrawal is 200,000 ETB

10
3. Chapter Three

3. Proposed System
3.1. Overview

The proposed system is designed for helping people for make payments using their smart devices.
The system consists of the following advantages time saving, providing information, and reliable
payment service. The system is going to be web based which helps different users and
organizations to access the system regardless of their location.

3.2. Functional Requirements

The system is going to accomplish the following functionality:

1. Security
➢ Encryption
o Sensitive data at rest like card information are encrypted and decrypted via
OpenSSL using AES-256-CBC. All encrypted values are signed using a
message authentication code (MAC) so that their underlying value cannot be
modified or tampered with once encrypted.
o Data in transit or in case of information or data transfer between the merchant
website and our payment gateway, all information will be encrypted and
decrypted using Secure Socket Layer (SSL). This standard security protocol
establishes an encrypted channel to allow for the safe transfer of private data
over public channels, such as between a web server and a browser and this is a
requirement for a merchant website in order to integrate their system with our
payment gateway.
➢ Strong Customer Authentication (SCA) is used to reduce fraud and increase online
payments security in the authentication process. In our case we will implement OTP
verification on each login.
➢ Filtering and Protection mechanism against Code injections (SQL injections, XSS
attacks, Object injections etc…)
➢ Web Application Firewall
➢ CSRF token management to prevent cross-site request forgery request
➢ Rate and payload size limiter to prevent Brute force & Distributed Denial-of-Service
(DDoS
➢ Role Based Access Control

11
 2. In customer accounts
• Send money
• Deposit money,
• Withdraw money, view transactions, and pay online.
3. In merchant account
• Send money, deposit and withdraw money,
• Withdraw money, View transactions,
• Create app credentials for their payment integration
• See their customers’ transaction activities if it involves them.

3.3. Non-functional requirements

➢ Compatible and portable: we have made the system responsive so that it can be accessed
on every device. It is also accessible on every browser and operating systems.
➢ Usability: we made the user interface clear, easy and understandable for every user.
➢ Availability: as long as there is a working internet connection the system will give service
24/7 hours for the users.
➢ Performance: the maximum response time of the system is 10-20 second.

3.4. System Model

3.4.1. Scenarios

1. Deposit
Actors: Merchant, Customer
Flow Event

No Event
1 Open web
2 Login to platform
3 Navigate to deposit page
4 Enter card information or select previously attached card
5 Enter the amount of money
6 Click deposit button
7 Process deposit request
8 Logout

12
2. Withdraw
Actors: Merchant, Customer

Flow Event

No Event
1 Open web
2 Login to platform
3 Navigate to withdraw page
4 Enter card information or select previously attached card
5 Enter the amount of money
6 Click withdraw button
7 Process withdraw request
8 Logout

3. Transfer
Actors: Merchant, Customer

Flow Event

No Event
1 Open web
2 Login to platform
3 Navigate to send payment page
4 Enter phone number
5 Enter the amount of money
6 Click transfer
7 Logout

4. Online Payment

Actors: Customer
Flow Event

No Event
1 Go to merchant website
2 Click checkout
3 Redirect to our payment gateway’s payment page
4 Enter phone number
5 Enter OTP

13
 6 Display detail information about the payment
7 Click pay
8 Redirect to merchant website

5. View balance
Actors: Merchant, Customer

Flow Event

No Event
1 Open web
2 Login to platform
3 Navigate to balance page
4 Logout

6. View transactions

Actors: Merchant, Customer

Flow Event

No Event
1 Open web
2 Login to platform
3 Navigate to transaction page
4 Logout

7. Integrate payment system with merchant website

Actors: Merchant
Flow Event

No Event
1 Get app credential
2 Integrate our payment system with their website using their app credential
following payment gateway integration guide line documentation

14
3.4.2. Use Case Model
Actor identification

Table 3. 1 Actor identification

Name Description Role

Customer Actor or users that use the platform for a
simple transaction purpose.
• Register themselves.
• Deposit and withdraw
money.
• Transfer money.
• View balance.
• View transaction.
• Manage their account.
• Make online payments.

• Register themselves.
Merchant Merchant or users that manage their • Deposit and withdraw
customer’s payment through our payment
money.
gateway.
• Transfer money.
• View balance.
• View transaction.
• Create APP
• Integrate payment to their
system.
• See their customers'
transaction activities if it
involves them.
• Manage their account.

• Manage the platform.

Administrator manage and control the whole system of
• Control user behavior.
the payment gateway
• Manage integration with
other platforms
(EthSwitch).
• Assist customers.

15
 • Send transaction request
EthSwitch The interface gateway that facilitates to the issuing banks
request and response exchange between
• Return response of the
issuing banks and the payment gateway.
transaction request

• Perform transaction
Bank Users/Issuer bank where the actual money request
resides • Debit and Credit account
• Perform card validation
and send response

3.4.3. Use case diagram and description

Figure 3. 1 Use case diagram

16
Description of use case model

Table 3. 2 Use case description sign up

Use case name Signup

Use case ID UC01

Use case description New users sign up for our service.

Actor • Customer
• Merchant

Pre-conditions • Users must have mobile number & open our sign-
up page.

Post conditions The user has an account on our platform.

Main Flow 1.Actor open the sign-up page.

2.Actor insert phone number.
3.System send OTP to the actor phone number.
4.Actor enter OTP.
5.Actor fill essential information & click create
account.
Exceptional flow • Actor doesn’t have proper phone number
• Actor enters invalid OTP

Include -

Frequency of use Once on every user.

17
Table 3. 3 Use case description login

Use case name Login

Use case ID UC02

Use case description To login actors on our platform.

Actor • Customer
• Merchant

Pre-conditions • Users must have an account on our platform.

Post conditions Actor login in on our platform.

Main Flow 1. Actor navigate to our login page.

2. Actor insert phone number
3. System send SMS OTP code to the phone
number.
4. Actor enter OTP.
5. Actor click “Login” button.
6. System redirect actor to intended page.
Exceptional flow • Actor doesn’t have an account
• Actor enters invalid OTP

Include -

Frequency of use Depending on the user sign in frequency

18
Table 3. 4 Use case description deposit money

Use case name Deposit

Use case ID UC03

Use case description To deposit money to our payment gateway wallet

Participating actor • Customer

• Merchant

Pre-conditions • Users must have a balance in their bank account.

• User must have a valid card.

Post conditions Successfully deposit money to their wallet.

Main Flow 1. Actor open the deposit money page

2. The system display input form.
3. User fills correct information (New card
information or select previously attached card &
amount).
4. Click deposit button.
5. The system will check the information validity
and perform the operation through EthSwitch.
Exceptional flow • Actor doesn’t have enough balance
• Invalid card

Include • Login

Frequency of use Depends on the user need.

19
Table 3. 5 Use case description withdraw money

Use case name Withdraw

Use case ID UC04

Use case description To withdraw money to their bank account.

Participating actor • Customer

• Merchant

Pre-conditions • Users must have a balance in their payment

gateway wallet.
• User must have a valid card.
Post conditions Successfully withdraw money to their bank account.

Main Flow 1. Actor open withdraw page

2. The system display input form.
3. User fills correct information (New card
information or select previously attached card &
amount).
4. Click withdraw button.
5. The system will check the information validity
and perform the operation.
Exceptional flow • Not enough balance
• Invalid card

Include • Login

Frequency of use Depends on the user need.

20
Table 3. 6 Use case description send money

Use case name Transfer money

Use case ID UC05

Use case description To transfer money to another user on our platform.

Participating actor • Customer

• Merchant

Pre-conditions • Users must have sufficient balance in their

wallet.

Post conditions Successfully transferred money to another user.

Main Flow 1.Actor open the send money page

2.The system display input form.
3.User fills correct information.
4.Click send button.
5.The system will check the information validity
and transfer the money.
Exceptional flow • Phone number doesn’t exist on our platform
• Insufficient balance.

Include • Login

Frequency of use Depends on the user need.

21
Table 3. 7 Use case description view balance

Use case name View balance

Use case ID UC06

Use case description To view balance in their wallet or wallets of it is a

merchant account

Participating actor • Customer

• Merchant

Pre-conditions -

Post conditions View their balance.

Main Flow 1. Actor open balance page

2. The system displays their balance.

Exceptional flow -

Include • Login

Frequency of use Depends on the user need.

22
Table 3. 8 Use case description view transactions

Use case name View transactions

Use case ID UC07

Use case description To view transactions

Participating actor • Customer

• Merchant

Pre-conditions • Users must have at least one transaction.

Post conditions View transactions.

Main Flow 1. Actor open the transaction page.

2. The system displays the transactions.

Exceptional flow • User don’t have any transaction; it will display

empty.

Include • Login

Frequency of use Depends on the user need.

Table 3. 9 Use case description online payment

Use case name Online Payment

Use case ID UC08

23
Use case description To perform online payment like ecommerce.

Participating actor • Customer

Pre-conditions • Users must be on a merchant website that support

our payment system and have a sufficient
balance in their wallet
Post conditions Successfully paid to the merchant.

Main Flow 1. Customer open a merchant website that support

our payment system
2. Customer click checkout
3. Merchant website send transaction information
via API
4. Payment gateway validate and saves data to our
database
5. Payment gateway returns pending transaction
data to merchant website.
6. Merchant website redirect to the payment
gateway’s online payment page.
7. Actor fills in the correct information.
8. Click the pay button.
9. The system will check the information validity
and perform the operation.
10. The system send transaction data to merchant
website via Callback URL.
Exceptional flow • Customer have insufficient balance

Include • Login

Frequency of use Whenever a customer shops on a merchant website and

wants to pay.

24
Table 3. 10 Use case description integrate payment

Use case name Create APP

Use case ID UC09

Use case description
Participating actor
To create an app (account) which the merchant can use
to integrate to its website using the app key so that
customers can pay online to the merchant using our
payment gateway in which the merchant app
credentials will be used to transfer data from the
merchant website to our payment gateway & vice
versa.
• Merchant

Pre-condition -

Post condition Successfully created an app in which merchants can

accept online payment from customers.

Main Flow 1. Actor open the APP page

2. Merchant enters app name and clicks create a
new app.
3. The system generates an APP key.
Exceptional flow

Include • Login

Frequency of use Whenever merchant wants to create a new APP

25
3.5. Object model
3.5.1. Data dictionary

Table 3. 11 data dictionary

Class Attributes Operation Function

Role id, name, guard to manage role
ModelHasRole model_id, role_id, model_type hasRole()
Permission id, name, guard to manage
permission
access on the
system
ModelHasPermission model_id, permission_id, hasPermission()
model_type
RoleHasPermission permission_id, role_id hasPermission()
User id, role_id, phon_number, login() Users of the
avatar, password, email, register() system Like
remember_token, settings, logout() manager,
two_factor_secret, deteteAccount() employee,
two_factor_recovery_codes, customer
two_factor_confirmed_at
Transactions Id, sender_id, receiver_id, show() Transaction
app_id, amount, fee, description, delete() taking place in
transaction_type, status, payload transfer() payment
deposit() system
withdraw()
App id, user_id, type, name, key, createApp() Merchant create
is_primary_app deleteApp() api for their
editApp() customer
Card id, user_id ,card_number, cvv, delete() User register or
expire_year, expire_month, store() delete its card
holder_name information
Wallet id, user_id, app_id, balance getBalance() Users wallet see
detail of their
balance

26
3.5.2. Class diagram

Figure 3. 2 Class diagram

27
3.5.3. Dynamic Model
3.5.3.1. Sequence Diagram

Figure 3. 3 Sequence diagram of customer and merchant registration

28
Figure 3. 4 Sequence diagram of customer and merchant login

Figure 3. 5 Sequence diagram of deposit money

29
Figure 3. 6 Sequence diagram of withdraw money

30
Figure 3. 7 Sequence diagram of transfer money

Figure 3. 8 Sequence diagram of view transaction

31
Figure 3. 9 Sequence diagram of creating APP

32
Figure 3. 10 Sequence diagram of paying online

3.5.3.2. Activity Diagram

Figure 3. 11 Activity diagram of registration

33
Figure 3. 12 Activity diagram of login

Figure 3. 13 Activity diagram of deposit money

34
Figure 3. 14 Activity diagram of withdraw money

Figure 3. 15 Activity diagram of transfer money

35
Figure 3. 16 Activity diagram of online payment

Figure 3. 17 Activity diagram of view transaction

36
Figure 3. 18 Activity diagram of view balance

37
Figure 3. 19 Activity diagram for creating APP

3.5.3.3. State chart Diagram

Figure 3. 20 State chart diagram of registration

38
Figure 3. 21 State chart diagram of login

Figure 3. 22 State chart digram of withdraw money

Figure 3. 23 State chart diagram of transfer money

39
Figure 3. 24 State chart diagram of online payment

Figure 3. 25 State chart diagram for creating App

4. Chapter Four

4. System Design

40
4.1. Overview

This section describes the design issues of the overall system, such as design goal, subsystem
decomposition, hardware/software mapping, and persistent data management. It provides the
complete architectural overview of the proposed system. It is intended to capture and express the
significant architectural decisions, which have been made, on the system.

4.1.1. Purpose of the System

The purpose of this design is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. This document
describes the design issues of the overall system. The objectives of these designs are to model the
system with high quality so that it could be easy to make a change to it.

4.1.2. Design Goal

The design goals describe the qualities of the system that are derived from the non-functional
requirements. Not only the system modeling techniques but also some system design techniques
like system decomposition design are covered well during this phase. These goals may be inferred
from the nonfunctional requirements.

Performance

• Response time: - Depending on the network connection that the user machine has the
system is going to interact and respond to the user's request in a maximum of 10–20
seconds.

• Memory: -The client system requires an average of 128MB of free RAM memory to be
loaded on a user’s web browser. The server system is going to require up to 500MB of
memory to store all the data and other components of the system and a minimum of
512MB of RAM.
Dependability

• Robustness: - since the system is a web-based system, that mainly uses a menu driven
entry there wouldn’t be an input problem by the user side. But for the server side there

41
 might be an error during the process of entering data. In this time the system will provide
an error page and the system will continue without failure or crash.
• Availability: - as long as there is an internet connection the system will be available 7 days
a week and 24 hours a day.
• Reliability: the information provided by the system is as reliable as it is presented on the
web page interface, and this is maintained by the persistent database.
• Security: - The system uses a phone number, OTP and 2 step verification (if user wish to
enable it) and they will manage their own page according to their level of access and the
system will encrypt sensitive information and uses SSL to establish an encrypted channel
to allow for the safe transfer of private data over public channels.
Maintenance

Extensibility: - if it is needed to add new functionality to the system, this must be achieved
•
by only making a separate page and integrating this page with the existing system.
• Modifiability: - if in the system, some functionality requires to be modified, this
modification must be done specifically to that function or page without affecting the
overall system organization.
• Portability: - the system is developed to be viewed and retrieved from any web browser
regardless of their version and platform it resides in.
End user

From the user point of view the system should provide the following end user criteria so that
the system is usable by the user

• Utility: - in order to help the user, to easily understand and interact with the system, the
system must provide the following utilities
o Mouse over tips
o Keyboard alternative
• Usability: to enhance the usability of the system, the system should be designed
incorporating the following usability concepts
o Site mapping & Consistent page pattern
o Less overcrowded interface.

Priorities of the System

The design goals of the payment gateway system are prioritized as follows

Table 4. 1 System property

Priority Design goal

1 End user

42
 2 Security
3 Performance
4 Dependability
5 Maintenance

4.2. Proposed system architecture

4.2.1. System Process

➢ Customer

Figure 4. 1 Customer overview

Figure 4. 2 System process of customers

43
 ➢ Merchant

Figure 4. 3 Merchant overview

Figure 4. 4 System process of Merchant overview

➢ Admin

44
Figure 4. 5 Admin overview

Figure 4. 6 System process of admin

4.2.2. Subsystem decomposition

45
Figure 4. 7 System decomposition

Subsystem description

Table 4. 2 Subsystem description

Subsystem Purpose Class

Access Control To give a role for users Role
Account Manager To manage accounts User
Wallet
Payment Process Concerned with transactions Transaction
App Manager Merchant can create app in App
order to integrate their website

4.2.3. Hardware/Software Mapping

46
Figure 4. 8 Hardware/software mapping

4.2.4. Persistent data management

Figure 4. 9 Role mapping

Figure 4. 10 User mapping

47
Figure 4. 11 Transaction mapping

Figure 4. 12 Apps mapping

48
Figure 4. 13 Wallet mapping

Figure 4. 14 Card Mapping

Figure 4. 15 RoleHasPermission mapping

49
Figure 4. 16 Permission mapping

Figure 4. 17 ModelHasPermission mapping

Figure 4. 18 ModelHasRole mapping

50
4.2.5. Component Diagram

Figure 4. 19 Component diagram

4.2.6. Database Design

Figure 4. 20 Database design

51
4.2.7. Access Control

Table 4. 3 Access control

Customer Merchant Admin

Role create()
update()
delete()
Permission create()
update()
delete()
User login() login() login()
register() register() logout()
logout() logout()
deteteAccount() deteteAccount()
Wallet getBalance() getBalance()
Transaction show() show()
delete() delete()
transfer() transfer()
deposite() deposite()
withdraw() withdraw()
App createApp()
deleteApp()
editApp()
Card delete() delete()
store() store()

52
4.2.8. User Interface Design

Figure 4. 21 User interface design

Mockup interface design

Figure 4. 22 Mockup interface

53
5. Chapter Five
5. Implementation
5.1. Overview

This section is to define the process of the information system that should be built (i.e., physical
system design), whether the system is operational and used, and if or not the system meets quality
standard (i.e., quality assurance).

5.2. Coding Standard

This means set of agreed upon rules that developers follow to ensure the reusability, efficiency
and readability of the written code. These rules or conventions often cover the organization,
indentation, comments, declarations, statements, white space, naming conventions, programming
practices, programming principles, programming rules of thumb, etc.
As we stated on the chapter one of this documentation the programming languages, we are going
to use for implementing our projects are PHP framework Laravel and alpine JS. We have listed
below the coding standards used for each language.
1. PHP - The coding standard used for our PHP is PSR-2 coding standard.
2. Laravel – The coding standard used for our Laravel is PSR-2 since the official Laravel
framework follows the PSR-2 coding and the PSR-4 autoloading standard.
3. Alpine.js (JavaScript): The coding standard used for our JavaScript is from a set of coding
conventions and rules for use in JavaScript programming. It is inspired by the Sun document
Code Conventions for the Java Programming Language. It is heavily modified of course
because JavaScript is not Java.

5.3. Prototype

The prototype we implemented for this project is only for demonstration purposes for performing
the basic operations in a payment gateway system. Because in our country we need a trade license
and other requirements like financial operating license from NBE etc…. we couldn’t integrate to
EthSwitch, so instead we built demos for the purpose of demonstration.

Our prototype consists of a Payment gateway, system like EthSwitch, 2 Banks and 1 Merchant
Ecommerce website in order to show the process and basic operations like deposit, online payment,
withdrawal and transfer.

54
5.4. Implementation Details

As our system is currently only a web application, we will cover both the client and server sides
of the implementation.
Client Side
The web-based application of our payment gateway offers a variety of features. All users can
perform the required function from the system according to their access level and role, thanks to
our adaptive and responsive user interface web application.
Here we have listed the features of our web application for users.

• Online Payment
• Transaction Histories
• Wallets
• Balance Check
• Deposit
• Withdraw
• Transfer or send money

Server Side
This is where users on the client side ask and get a response, in addition this is where the interaction
between EthSwitch and our payment gateway occurs in order to handle the deposit and withdrawal.

Our implementation is based on the followings.

PHP (Hypertext Preprocessor) programming language: PHP is a general-purpose scripting
language geared towards web development. It was originally created by Danish-Canadian
programmer Rasmus Lerdorf in 1994. [5]
Laravel: Laravel is a free, open-source PHP web framework, created by Taylor Otwell and
intended for the development of web applications following the model–view–controller
architectural pattern and based on Symfony. [6]
MariaDB: MariaDB is a community-developed, commercially supported fork of the MySQL
relational database management system, intended to remain free and open-source software under
the GNU General Public License. [7]
Ethswitch: Ethswitch, established in 2011, is a share company fully owned by all banks in Ethiopia.
It is established mainly to provide simple, affordable, secured, and efficient e-payment

55
infrastructure services to retail payment service providers, and through them, to end users in
Ethiopia; by deploying state-of-the-art technology along with highly skilled and motivated
professionals. The underling mandate of Ethswitch is contributing to the modernization of the
national payments system and enhancement of financial inclusion in the country. Since 2016, it
has enabled interoperability of ATMs and POS terminals operated by all banks. Currently, it is
also rolling out projects to achieve interoperability of other digital payment platforms operated by
all financial service providers. In October 28, 2021 EthSwitch S.C, Ethiopia’s National Switch
announced the commencement of interoperability of Digital Wallet, Mobile & Internet Banking
systems run by banks, Microfinance Institutions (MFIs) and E-money issuers, following the
authorization from the National Bank of Ethiopia after successful pilot test. The interoperability
enables customers of banks and MFIs & e-money issuers with digital wallet, mobile & internet
banking & accounts to send funds from one institution to another. The interoperability includes
transfers from bank account to bank account, wallet to wallet, wallet to bank account and from
bank accounts to wallet using internet based and USSD channels as well as smart phone
applications. [8]

Figure 5. 1 How EthSwitch work with our system

5.5. Deployment
➢ Nginx: - is a well-known high-performance HTTP server and reverse proxy server.
NGINX provides an abundance of features, such as load balancing, caching, SSL/TLS
offloading, log rotation, and so on.
➢ Git: - open platform for developing, shipping, and running applications. Docker is used to
separate the application from the infrastructure so that we can deliver software quickly.
With Docker, you can manage your infrastructure in the same ways you manage your
applications. By taking advantage of Docker’s methodologies for shipping, testing, and
56
 deploying code quickly, you can significantly reduce the delay between writing code and
running it in production.
➢ GitHub: - we sued it for the distributed version control and source code management
functionality of Git.
Table 5. 1 Components

Component name Implementation detail

Authentication controller Implemented using PHP code on Laravel
framework to perform Authentication. It is
required when the user wants to login. It
checks the validity of the user login inputs
with a combination or OTP.
Page controller This is a route class which will direct the user
to each intended pages according to the user
actions. It will be implemented using PHP
code on Laravel framework.
API gateway A gateway in which we connect to the
Merchant websites with our payment
processor so that the server can provide
service.
Access Controller Implemented using Laravel middleware with
combinations of Policy to ensure security
Web Application Firewall Wrapper and check every route end point to
ensure our security policy

6. Chapter Six
6. System Testing

57
6.1 Objective
The main purpose of this section is to plan, schedule and specify the modules and methods to
perform testing of the system. The main objectives are:

• Determine which features will be tested and which will not.

• List the recommended test requirements.
• Recommend and describe test strategies to be implemented.
• Identify the required resources and provide an estimate of the test efforts.

6.2. Scope
This testing documentation will be imposed on the following System and Version

Table 6. 1 Scope

System Name Payment Gateway

System Description This is a system designed for helping people
for making payments using their smart devices
System version 1.0.0
Type Web App

The overall testing plan will include testing all the modules individually and the integration of the
modules. Task of this section include:
• Test the functionality of the features.
• Test the system security.
• Test the usability of the system.

6.3. Resource
Various resources will be used in the implementation of tests. The main roles are role (human)
resources and system resources.

6.4. Roles

58
Table 6. 2 Testing Roles

Human Resources
Roles Minimum Resource Responsibilities
Recommended
Test Manager Abduselam Hafiz Provides management
oversight Responsibilities:
➢ Provide technical
direction
➢ Acquire appropriate
resources
➢ Management
reporting
Test Designer Hayat Ahmed Identifies, prioritizes, and
implements test cases
Responsibilities:
➢ Generate test plan
➢ Generate Test Suite
➢ Evaluate effectiveness
of test effort
System Tester Abdulmejid Shemsu Executes the tests
Responsibilities:
➢ Execute tests
➢ Log results
➢ Recover from errors
➢ Document defects
Test System Administrator Fuad Endris Ensures test environment and
assets are managed and
maintained.
Responsibilities:
➢ Administer test
management system
Database Administration Abdulmejid Shemsu Ensures test data (database)
environment and assets are
managed and maintained.
Responsibilities:
➢ Administer test data
(database)
Designer Abduselam Hafiz & Hayat Identifies and defines the
Ahmed operations, attributes, and
associations of the test classes
Responsibilities:
➢ Identifies and defines
the test class(es)

59
 Implementer Abdulmejid Shemsu & Fuad Implements and unit tests the
Endris test classes and test packages
Responsibilities:
➢ Creates the test
classes and packages
implemented in the
Test Suite.

6.5. Schedule

The testing schedule for the proposed system will be conducted in the following manner.

Table 6. 3 Testing schedule

Milestone Tasks Effort Date of Testing

Test Planning 1 June 9, 2022
Test Design 1 June 9, 2022
Test Development 1 June 10, 2022
Test Execution 1 June 11, 2022
Test Evaluation 1 June 11, 2022

6.6 Test Case Scenarios and Requirements

6.6.1 Data and Database Integrity
➢ Verify access to payment gateway Database.
➢ Verify access to EthSwitch Database.
➢ Verify access to users Database.
➢ Verify access to transaction Database.
➢ Verify access to wallet Database.
➢ Verify correct retrieval of update of database data.
6.6.2 Function testing
Verify Various user types registration, login & creation.
➢ Merchant user login and registration
➢ Customer user login and registration
➢ Admin login
➢ Merchant App creation
➢ Card registration
6.6.3 User interface testing
➢ Verify ease of navigation through a sample set of screens.
➢ Verify sample screens conform to GUI standards.

60
6.6.4. Performance Testing
➢ Verify response time to authenticate
➢ Verify response time for API response
➢ Verify response time for transaction takes place
➢ Verify response time for multiple request
6.6.5 Load testing
Testing our system how it can handle multiple request and transactions is our highest and most
important issue. To achieve this goal, we have used a queue transaction type that offers by the
Laravel.
6.6.6. Security and Access Testing
➢ Verify Authentication from a local PC.
➢ Verify Authentication from a remote PC.
➢ Verify API credential from API request.
➢ Verify Login security through OTP mechanism
➢ Verify two factory authentication method

6.7 Estimated Risk

The following are the primary risks that might stymie the testing and verification process:
➢ Not meeting schedule deadlines.
➢ Shortage of technical skills to perform required testing.
➢ Shortage of budget to conduct testing.

6.8 Contingency plan

The following is the contingency plan for dealing with the aforementioned risks:
➢ Conduct testing on the smallest and most limited budget possible.
➢ Compile progress and show to stakeholders even if the testing is not fully completed.
➢ Perform load and stress testing with available resource.

7. Chapter Seven

61
7.1 User Manual
7.1.1 Authentication
Users will be sent to the login page as soon as they visit our website. Then, after they've logged
in, they'll be sent to the dashboard.
Both login and registration page redirected to the same page. After inserting their phone number
if its already found on our database the system sends the OTP for the user. If it isn’t found the
system asks for this information.
Login

Figure 7. 1 Login Page

Registration
Registration page where users insert their information. Name and account type

Figure 7. 2 Registration Page

OTP confirmation page
After a user successfully inserted their information, we will send an OTP via SMS. This OTP
works for both registration and login.

62
Figure 7. 3 OTP Confirmation Page

7.1.2 Dashboard
A dashboard is where a user gets after authentication. Dashboard helps the user to manage and
see about his account

Figure 7. 4 Customer Dashboard Page

63
Figure 7. 5 Merchant Dashboard Page

7.1.3 Activities
As we see from the above manual there are several navigation menus found in both merchant and
customer page namely: Send, wallet, deposit, withdraw and activity

Send
Send page with were we send a money to others with in the system.

Figure 7. 6 Send/Transfer Money Page

64
Wallet
In the wallet page the users can see how much balance they have and their card used so far.

Figure 7. 7 Wallet Page

Deposit
Deposit page is where you can transfer your money from the bank to our system. It requires card
(ATM) number, cvv, expire month and expire year.

Figure 7. 8 Deposit Page

65
Activity
This page dedicated to look at their activities they have been working on our payment system

Figure 7. 9 Activities Page

7.1.4 App
For a merchant to use our API end points, they have to register their app in our system. Once
they register their app we will generate an key for them.

Figure 7. 10 Merchant APP Create Page

66
Once the app was created the user can user our api endpoints

Figure 7. 11 Merchant APP Detail Page

7.1.5 Admin page

Login
Admin have separate login page for their authentication.

Figure 7. 12 Admin Login Page

67
Role management page
Users have multiple permission and also have a role, this feature managed by the admin on the
admin control page. Currently there are only 3 roles: Super Admin, Customer, and Merchant.

Figure 7. 13 Role Management Page

Two factor authentication.

If an admin needs to set a two-factor authentication method they get in to the profile page and
they can enable it.

Figure 7. 14 Admin 2FA Creation

68
7.2 Git address
https://github.com/abdulmejidshemsu/payment_gateway

Figure 7. 15 Github Repo

69
8. Chapter Eight
8.1 Conclusion
The proposed system is a Payment Gateway System. Its main goal is to provide a means to
process payment transaction for service providers like merchants, bill payment services at
once place. It makes it easy for users to easily pay for merchants, for merchant to collect
payments. On this project we tried to describe the problem statement that means the need or
the use of the system define our business plan based on small research we did on current
existing systems or current Payment Gateway. The problem statement led to the formulation
of general objective of the project which is to design and implement an online nationwide
payment gateway. This will be done by implementing the functional requirements like
security, processing payment and transferring money and while maintaining the non-
functional requirements like robustness, reliability and performance.
The challenges faced during this project are a lack of data and cooperation from other
parties.

8.2 Recommendation
Through the making of the system, the team and advisor has faced and tackled many
challenges. Owing to the experience we have developed while designing the proposed
Payment Gateway we have few points to suggest for anybody who plans to work on similar
projects to ours. All the group made Now all the group members recommend to other
developers who want to maintain this system, to add some features which are not covered by
the system due to lack of time or resources like implementing subscription-based payment,
fraud detection using Machine Learning so that the system can protect uses form different
security issues.

70
References

[1] https://www.nyongesasande.com/payment-service-provider/, access date (December 27, 2021).

[2] https://www.linkedin.com/pulse/what-payment-gateway-moneypayhk, access date (December 27, 2021).

[3] https://truust.io/blog/the-evolution-of-payments-industry/, access date (December 27, 2021).

[4] https://dfsobservatory.com/sites/default/files/Ethiopia%20-%20Proclomation%20No.%20592-2008%20-
%20Banking%20Business.pdf, access date (January 10, 2022).

[5] https://en.wikipedia.org/wiki/PHP, access date (January 21, 2022).

[6] https://en.wikipedia.org/wiki/Laravel, access date (January 21, 2022).

[7] https://en.wikipedia.org/wiki/MariaDB, access date (January 21, 2022).

[8] https://ethswitch.com/2021/11/15/ethswitch-enables-digital-wallet-mobile-and-internet-banking-interoperability/,
access date (January 29, 2022).

71