System implementation, testing and validation

report for ICEngIM Payment and Transaction

Service.

i

Document No: 1

Prepared by: Abubakari Simba, Nyende

Mahmood, Ayesiga Tony

Nsubuga and Kiggundu

Ismail Ssali

Date: 06-DEC-2020

Version: 1.0

ii

Document Approval

Name Role Date Signature

Kiggundu Ismail

Ssali, Nyende

Mahmood

Author(s) 06th/12/2020

Ayesiga Tony

Nsubuga

Validation

Abubakari Simba Client

iii

Table of Contents1 Introduction..............................................................................................................................1

1.1 Background and scope of the project................................................................................1

1.2 Overview of the document................................................................................................1

2 System Specifications...............................................................................................................3

2.1 Version of requirements and Version Control..................................................................3

2.2 Input..................................................................................................................................3

2.2.1 The checkout view.....................................................................................................3

2.2.2 The donation view.....................................................................................................4

2.2.3 The Support ticket view.............................................................................................4

2.3 Output................................................................................................................................4

2.4 Functionality.....................................................................................................................5

2.4.1 Payments....................................................................................................................5

2.4.2 Donations...................................................................................................................5

2.4.3 Support ticketing........................................................................................................5

2.5 Limitations and safety.......................................................................................................5

2.6 Default settings.................................................................................................................6

2.7 Special requirements.........................................................................................................6

2.8 Errors and alarms..............................................................................................................6

2.8.1 Empty field errors......................................................................................................6

2.8.2 Mime type errors........................................................................................................6

2.8.3 Expired session errors................................................................................................6

2.8.4 Automatic form filling errors.....................................................................................6

2.8.5 Invalid email or wrong email syntax error................................................................7

3 Design output...........................................................................................................................8

3.1 Implementation (coding and compilation)........................................................................8

4 Inspection and testing.............................................................................................................10

4.1 Introduction.....................................................................................................................10

4.2 Test plan and performance..............................................................................................12

4.2.1 Test objectives.........................................................................................................12

4.2.2 Scope and Relevancy of tests..................................................................................13

iv

4.2.3 Levels of tests..........................................................................................................14

4.2.4 Types of tests...........................................................................................................15

4.2.5 Sequence of tests......................................................................................................16

4.2.6 Configuration...........................................................................................................17

5 Installation and system acceptance test..................................................................................18

5.1 Input files........................................................................................................................18

5.2 Supplementary files.........................................................................................................18

5.3 Installation qualification.................................................................................................18

6 Performance, servicing, maintenance, and phase out.............................................................20

6.1 Service and maintenance.................................................................................................20

6.2 Performance and Maintenance........................................................................................20

7 Conclusion and Recommendations........................................................................................22

v

List of Figures Figure 1 Registration page........................................................................................................................23Figure 2 Login page..................................................................................................................................24Figure 3 Payment interface.......................................................................................................................25Figure 4 Donation interface......................................................................................................................26Figure 5 Support Ticket interface..............................................................................................................27Figure 6 Support Ticket sent to user..........................................................................................................28Figure 7 Admin Dashboard.......................................................................................................................29Figure 8 assigning a developer to a support ticket....................................................................................29Figure 9 View showing all the support tickets...........................................................................................30

vi

List of Tables Table 3.1 Documentation............................................................................................................................9Table 4.1 Inspection plan and performance..............................................................................................10Table 4.2 Inspection plan and performance..............................................................................................12Table 4.3 Sequence of Test results.............................................................................................................16Table 5.1 Checklist of the Installation and system acceptance test............................................................18Table 5.2 Installation Procedure Check....................................................................................................19Table 6.1 Performance and maintenance details.......................................................................................20

vii

1 Introduction

1.1 Background and scope of the project

Many innovative projects are started and prototyped by students in College of Computing and

Information Systems (CoCIS) and College of Engineering, Design, Art and Technology

(CEDAT) every year. These innovative projects and prototypes that have been motivated by the

community, research, and commercial problems and thus provide early-stage solutions. But they

are abandoned consequently losing potential solutions to the problems that have been identified

by the student’s teams thus the idea for creating the ICT and Engineering Innovation

Marketplace for further development of the innovation prototypes. The development teams

require funds to turn these early-stage solutions into ready to use artifacts and technical expertise

to improve the prototyped solutions. The proposed marketplace will provide a payment platform

where interested buyers will have an option to buy high-end artifacts, donors to donate funds to

different projects on the proposed marketplace and other development teams to provide technical

support and contribute to the Engineering artifacts designed by talented and experienced high-

end system designers.

1.2 Overview of the document

This document describes the implementation, testing and validation findings for the ICEngIM

Payment and Transaction service. It is divided into the following sections:

Section 1: This section provides a brief introduction about our project and an overview of this

report.

Section 2: This describes and specifies the service completely. It provides the details of what we

used as a basis for the validation process

Section 3: This describes the development tools used to implement the Payment and Transaction

service, the anomalies, integration details, all the device interfaces, the equipment that our

service supports as well as the operating environment in which our service can be used. In

addition to this, it provides an insight in the kind of documentation that has been used as a bench

mark for writing this report.

Section 4: This provides some additional information about the payment and transaction service

testing process for example the extent of the testing in compliance with the requirements, the

viii

system acceptance test specification, and the testing approach used, the complexity of the testing

process and risks involved.

Section 5: This describes the installation and system acceptance test. It includes information

about the validation of the installation process ensuring that all system elements are properly

installed in the host system.

Section 6: This describes the performance, servicing and maintenance procedures required for

the payment and transaction service.

ix

2 System Specifications

2.1 Version of requirements and Version Control

The versions of the software requirements specification document are based on the field study

carried out prior to writing the document. Version 1.0 of our requirements specification

document had system requirements that we generated after analysis of the field study which

involved searching for software marketplaces on the internet that had a payment gateway similar

to that we intended to develop.

Versions of the Payment and Transaction service are based on the changes in the schemas. For

example, Version 1.0 of the payment and transaction service did not account for users having a

dashboard. Therefore, in Version 2.0, users having access to a dashboard was included. We

chose to use Git as a version control tool during the implementation of the payment and

transaction service and all the implementation code has been hosted on GitHub, a version control

cloud repository.

2.2 Input

2.2.1 The checkout view

On this view, there are several input fields that are expected to be filled by a user. Some input

fields are compulsory while others are optional. Compulsory fields include name, email, account

number, security number and expiry date of the credit card. Other fields such as user’s address,

phone number etc. are optional. The name entered should consist of a given length of characters

and should be the same name that appears on the credit card. The account number on the credit

card consists of a specific number of integers depending on the card provider who issued it. The

security number also appears on the back of the credit card and should consist of three (3) or four

(4) characters depending on the bank that issued it. If the name, account number or the security

number entered do not match the details on the credit card, the payment and transaction service

will display an output to the screen and ask the user to check their payment info and try again. If

the details entered are correct, a success message will be displayed on the screen.

x

2.2.2 The donation view

This view consists of an amount input field which requires a user to input an amount they are

willing to donate to a particular project, their name, email, account number, expiry date and

security number as seen on the user credit card. The amount field is an integer input field and if a

user enters a datatype other than an integer, the payment and transaction service asks the user to

enter a positive integer number. A user can then submit the details in order to make a donation to

a project of their choice.

2.2.3 The Support ticket view

The support ticket view consists of 8 input fields. A name field, email field, feature title field in

which a user can input the name of the feature they want the development team to implement e.g.

AI scanning feature, select project input field for selecting projects that are already on the

marketplace, description input field in which users describe the details of the feature they want to

be implemented to the project, a priority drop-down input field which allows users of select

different levels of priority that is high, low or medium, a category drop-down input field and

lastly, the attachments field which allows users to attach a file or files to their support ticket

request. All the fields in this view are compulsory. Once the form is submitted successfully, the

support ticket request is stored in the database and a flash message is displayed on the screen. In

case of an error in the form fields, an output is returned on the screen.

2.3 Output

The payment and transaction service provides users with automated generation of documents

known as invoices after every successful transaction process. An invoice generated by the

service is in form of a portable digital format (pdf) that is seen to users via email. The service

also enables users to use the print-out option offered by modern browsers to print out invoices

generated.

For every operation that involves the payment and transaction service, a flash or status message

is displayed on the screen to let users know the outcome of their operation. A green-colored

success message is displayed when the operation of the successful and a red-colored error

message is shown in case the operation is not successful.

xi

2.4 Functionality

2.4.1 Payments

The service enables customers to make payments using multiple currencies such as dollars,

euros, shillings and pounds for mature and complete projects to deploy in their organizations.

2.4.2 Donations

Users can select and donate to projects of their choice by clicking the donate button close to the

project. The service allows users to track the development status of the project they donated to.

2.4.3 Support ticketing

The service enables customers to request for new features to be added to existing projects, allows

clients to negotiate with the developers for the ticket submitted via comments, and provides

visualizations for tickets so as to come up with insights and finally generating reports.

2.5 Limitations and safety

The service requires an active 24/7 internet connection in order to verify transactions carried out

by users of the marketplace. The verification process is done by third party systems that can only

be accessed online thus the need for a constant internet connection. The service also is intended

to be hosted on the internet where it can be accessed by the public.

All form fields on views are first validated and verified using input validation scripts before they

are sent to the service thus the input fields have to be filled with their corresponding right data

types to ensure that the service works appropriately. This also helps to prevent SQL injection

attacks.

The service uses a session manager to ensure that once a user has ended his session, another

unauthenticated user cannot perform any operations on the platform related to the previous user’s

account. For example, if the unauthenticated user tries to access other views, his authentication

will not be successful.

To prevent cases of cross site request forgery (CSRF), cross site request forgery tokens enable

the system to display errors to prevent any person who attempts to access the service in this way.

xii

2.6 Default settings

The service runs on a device on which PHP version 7.4.12 and above, an apache server version

2.4.35 and above, Wamp server 64-bit version 3.13 and above, MySQL version of 5.7.24 and

above are installed.

The payment and transaction service has no default values as all the values stored in the database

are entered by users.

2.7 Special requirements

The service uses the Argon hashing algorithm to hide rather explicit and sensitive user credit

card details from attackers. Payment details such as the account number, expiry date of the credit

card and the security code/number on the credit card are hashed before they are stored in the

database.

2.8 Errors and alarms

2.8.1 Empty field errors

Once a user attempts to submit a form with empty fields, an error message is displayed as shown

in the figure below prompting the user to fill in the empty field. In the example below, the user

attempted to submit an empty content field about a support ticket.

2.8.2 Mime type errors

These occur when a user tries to upload a file with a different file extension than the one that is

required in that particular field.

2.8.3 Expired session errors

Once a user’s session has expired, any operation carried out on for example, an open tab in the

browser that a user who has ended his session forgot to close will not allow any authentication

whether the inputs are valid or not. In the figure below, once an attacker attempts to submit the

form an error is displayed.

2.8.4 Automatic form filling errors

These prevent the browsers auto filling capabilities on views that have fields which require

sensitive information.

xiii

2.8.5 Invalid email or wrong email syntax error

For example, on the support ticket request form, if the email field is not filled correctly, an error

message is displayed.

xiv

3 Design output

3.1 Implementation (coding and compilation)The implementation process was carried out in Windows operating system. Visual Studio Code,

VS code was used as the development environment during the implementation process. Laragon

software was used to install all the remaining components that were needed for the

implementation process. Laragon helped us to install Laravel framework, composer which is a

dependency manager for PHP, Apache server and the MySQL server.

The Laravel framework provides classess called controllers that handle specific functionalities of

a service/system. The payment and transaction service comprises of a variety of controllers.

These controllers include; the AdminController, BannerController, BrandController,

CartController.php, CategoryController.php, ChartController, CouponController,

FrontendController, HomeController, InvoiceController, MessageController,

NotificationController, OrderController, PaypalController, PostCategoryController,

PostCommentController, PostController, PostTagController, ProductController,

ProductReviewController, ShippingController, TicketController, UsersController,

WishlistController, HomeController, AuditLogsController, PermissionsController,

PrioritiesController, RolesController, DonationController, and StatusesController. Each

controller is named basing on the view whose functionalities it handles. For example, the

HomeController contains the implementation for the home page, the AdminController contains

the implementation for the functionalities that involve the administrator, and the TicketController

contains the implementation for the functionalities that involve support tickets and so on.

xv

Table 3.1 Documentation

Topics Design output

Good programming

practice

Source code is... Source code contains...

Dynamic testing

Comments:

SeleniumHQ, a web application automation tool was used to test

whether all the service functionalities were executing as

expected. Some of the modules of the service have not been

implemented yet so they were not eligible for dynamic testing.

xvi

Modulized

Encapsulated

Functionally divided

Strictly compiled

Fail-safe (handling errors)

Revision notes

Comments

Meaningfull names

Readable source code

Printable source code

All statements have been executed at least once

All functions have been executed at least once

All case segments have been executed at least once

All loops have been executed to their boundaries

Some parts were not subject to dynamic test

4 Inspection and testing

4.1 Introduction

The inspection and testing of the computer system is planned and documented in a test plan. The

extent of the testing is in compliance with the requirements, the system acceptance test

specification, the approach, complexity, risks, and the intended and expected us of the system.

Table 4.2 Inspection plan and performance

Topics 3.3.1 Inspection plan and performance Date / Initials

Design output

Comments:

The design verification was in consistence

with the corresponding document reviews of

the Software Design Document.

Abubakari

Simba,

Kiggundu Ismail

Ssali

(Between

16th/10/2020 and

7th/12/2020)

Documentation

Comments:

The user manual explicitly elaborates (with

the help of images) how a novice user can

access functionalities based on the buttons

they click which enables them to access

specific views.

Ayesiga Tony

Nsubuga,

Nyende

Mahmood

(Between

16th/10/2020 and

7th/12/2020)

xvii

Program coding structure and source code

Evidence of good programming practice

Design verification and documented reviews

Change-control reviews and reports

System documentation, flow charts, etc.

Test results

User manuals, On-line help, Notes, etc.

Contents of user manuals approved

Topics 3.3.1 Inspection plan and performance Date / Initials

Software development

environment

Comments:

Abubakari

Simba,

Kiggundu Ismail

Ssali

(Between

16th/10/2020 and

7th/12/2020)

Result of inspection

Approval of inspection. Comments:

Abubakari

Simba (Between

30th/11/2020 and

7th/12/2020)

xviii

Data integrity

File storage

Access rights

Code protection

Installation kit, replication and distribution

Inspection approved

4.2 Test plan and performance

xix

4.2.1 Test objectives

The main objective of the testing is to find out as many system defects as possible so that they

are corrected and it remains bug free after release.

The system testing was done after all modules were integrated into one complete service so as

to verify service operation and performance with respect to the system specification.

Table 4.3 Inspection plan and performance

WHAT WHY HOW

Capture of user payment

details

To ensure that all form fields

are filled and that all credit

card details are successfully

captured.

Filling in the user details

while leaving out some

mandatory fields to test

whether the payment service

can accept partially filled

form fields.

Capture of donation details To ensure that all form fields

are filled and that all

donation details are

successfully captured.

Filling in the donation details

while leaving out some

mandatory fields to test

whether the database can

accept partially filled form

fields.

Capture of support ticket

details

To ensure that all form fields

are filled and that all support

ticket details are

successfully captured.

Filling in the support ticket

details while leaving out some

mandatory fields to test

whether the database can

accept partially filled form

fields.

xx

4.2.2 Scope and Relevancy of tests

The scope of testing the payment and transaction service was based on functions (modules),

validating user input data and code. We also tested the non-functional requirements like

system performance, stress, and response time. It is assumed that unit testing already provided

thorough black box testing, extensive coverage of source code, and testing of all module

interfaces.

The relevancy of the tests is;

Identify existing project information and the software that should be tested.

List the recommended test requirements (high level).

Recommend and describe the testing strategies to be employed.

Identify the required resources and provide an estimate of the test efforts.

List the deliverable elements of the test activities.

xxi

4.2.3 Levels of tests• Integration Testing

Integration testing is critical while integrating with a payment gateway. As a tester, you would

need to verify that the integration of the proposed marketplace is working fine with the chosen

payment gateway. As a tester you need to verify the entire transaction flow.

• User Acceptance Testing

User Acceptance testing verifies a user’s interaction with the payment and transaction service.

The goal of this testing is to ensure that the user is provided with the appropriate access and

navigation through the functions of the payment service.

• Module Testing

This involves testing for all the separate modules of the payment and transaction service.

These modules are basically the various controllers in the implementation code.

4.2.4 Types of tests

The below types of testing that are required for testing the payment gateway.

Functional Testing

Whenever a new payment gateway integrated into a system, functional testing is required to

see if the application behaves the way it behaves with other payment gateways. It should

handle the calculation as it is mentioned in documentation provided. For some gateways who

are well renowned in the market such as PayPal, functional testing can be avoided.

Integration Testing

Integration testing is a very important testing that must be performed on any payment

gateway. You need to verify that your application behaves the way you want to be even after

integrating a payment gateway. You need to check if the customer is successfully able to

place an order and then after successful payment, you need to make sure that the funds are

successfully received in the merchant’s bank.

Also, you need to verify if the transaction is void or refunded.

xxii

Performance Testing

Performance testing is critical for testing a payment gateway. You need to have a maximum

number accessing the payment gateway at the same time and see if the payment processor

fails. You need to increase users above a threshold level to check the performance of the

payment gateway.

Security Testing

Security testing must be done on any payment gateway on priority because of the sensitive

information provided while filling the payment details.

It is very important to check if the payment details entered by the user are encrypted properly

and to check if any kind of tweaks is not possible.

xxiii

4.2.5 Sequence of tests

The following are the test cases that have to be carried out on the payment gateway;

Table 4.4 Sequence of Test results

TEST CASE ID TEST CASE ACTUAL RESULT

TC_Payment_01 Users enter their payment

details in the payment form.

Payment received. An invoice

for the transaction sent to your

email.

TC_Donation_02 Users enter an amount to be

donated to a project of their

choice.

Donation received

successfully. An invoice sent

via email.

TC_Support-Ticket_03 Users submit a support ticket

request.

Support ticket sent

successfully.

Other test cases carried out include;

1. Test payment gateway with different card numbers — credit and debit. You should

have dummy card numbers to test this flow.

2. Verify the flow when there is a successful response from the issuing bank.

3. After a successful transaction from the issuing bank, the successful payment message

should be displayed to the user.

4. When the payment is successful on the payment gateway, the update must be sent to

the customer email or phone number.

5. Verify the flow when there is a failed transaction.

6. Verify the flow when the payment gateway stops responding.

7. Verify the transaction flow with fraud protection or security settings.

8. For testing purposes, after the successful transaction, an entry must be made in the

database. That entry must be checked according to the architecture designed.

9. Checking the flow in case the session expires while doing transactions.

10. Verify if the payment gateway operates on the currency of the country in which the

customer is doing the payment.

11. If the application allows payment through various options, then each option should be

xxiv

tested individually.

12. Verify the flow when a customer voluntarily cancels the transaction in the middle of

the transaction.

4.2.6 Configuration

The service operates on any operating system with the help of a web browser and it

communicates with different payment APIs on internet. The system also uses an email system

to send invoice to users about the transactions and payments.

xxv

5 Installation and system acceptance test

5.1 Input files

All the installation files are in PHP. The PHP files contain the application/service logic that is the code for

the whole project.

xxvi

5.2 Supplementary files

A README file has been uploaded together with the implementation code on GitHub. It introduces

and explains the payment and transaction service. It contains information that is commonly required to

understand what the project is about.

No License agreements have been reached with other third-party organizations.

5.3 Installation qualification

Table 5.5 Checklist of the Installation and system acceptance test

Topics Installation summary

Installation method

Comments:

Installation media

Comments:

The payment and transaction service code can be downloaded

from GitHub. GitHub link is provided in this document.

Installed files PHP files

xxvii

Automatic - installation kit located on the installation media

Manual - Copy & Paste from the installation media

Diskette(s)

CD-ROM

Source disk folder (PC or network)

Download from the Internet

Table 5.6 Installation Procedure Check

Topics Installation procedure Date / Initials

Authorization Person responsible: Kiggundu Ismail Ssali

Installation test

Comments:

Some modules were not fully implemented thus

not completely tested.

Kiggundu Ismail

Ssali

(Between

16th/10/2020 and

7th/12/2020)

xxviii

Tested and approved in a test environment

Tested and approved in actual environment

Completely tested according to test plan

Partly tested (known extent of update)

6 Performance, servicing, maintenance, and phase out

6.1 Service and maintenance

Clients will only use the available payment methods like MPesa, PayPal and MTN Mobile

Money. In case of a new payment method, users will be informed.

Several security standards and international compliance policies will be adhered by the payment

gateways to ensure security.

In case of any help a user manual will be provided to the users to help them understand the functionality

of the system.

6.2 Performance and Maintenance

During system execution, there may be delays with the local payment methods like MTN Mobile

Money due to poor network coverage and system shutdowns. Payment Fraud will also arise but

will be dealt with Fraud Detection Plugins. Customers may also initiate chargebacks.

Table 6.7 Performance and maintenance details

Topics Performance and maintenance Date / Initials

Problem / solution Problem: Payment Fraud like triangulation where

fake seller’s access client card details and Identity

theft where data thieves steal information of a

shopper.

Solution: Fraud Detection Plugin will be installed

in the system

Problem: Chargeback. A customer charges back

the money to demand a refund after making a

purchase.

Solution; Excellent Customer support through

briefing of clients about the functionality of the

payment system and responding to client queries

via email.

7th /12/2020

xxix

Topics Performance and maintenance Date / Initials

Functional maintenance The payment methods will always incorporate

new changes, especially Stripe and PayPal. The

system will be updated accordingly and users will

be notified.

Functional expansion and

performance improvement

We hope to incorporate a virtual account

that handles the money from the payment

transaction before distribution to the

respective parties.

We hope to integrate more payment

methods on top of the one we have to

increase diversity.

xxx

7 Conclusion and Recommendations

The main aim of this project was to provide a payment platform where interested buyers will have

an option to buy high-end artifacts, Donors to donate funds to different projects on the proposed

marketplace and other development teams to provide technical support and contribute to the

Engineering artifacts designed by talented and experienced high-end system designers.

xxxi

Appendix A: User Manual

Creating an account and login

Once a user has started the system, he or she is able to access the landing page which consists of

sign-up and sign-in buttons.

Figure 1 Registration page

xxxii

Before carrying out any activity on the marketplace, a user should have signed up and they own a

valid account. After registering they can now just sign in with their email and password so that

they gain access to the system. There is also an option of signing up with Gmail, Facebook

Figure 2 Login page

xxxiii

Make purchase

Once the user has accessed the projects page, they can navigate through various categories and

select a project of their choice which is added to the cart.

When the user is checking out, they have to select their preferred payment method from those

offered by the market place which include Visa, PayPal and Mobile Money.

Assuming the user selects the Visa option, they will be required to fill the corresponding

payment details.

Once the payment is successful, a confirmation message is displayed on the screen inform of a

pop up and an email is also sent to the user

Figure 3 Payment interface

xxxiv

Make donation

The donor will first login and then navigate to the premature projects page containing projects

that require donation.

The donor will then select the project they wish to donate to and then fill and submit the donation

details.

Figure 4 Donation interface

xxxv

Request for support

When a client needs support regarding a system he acquired on the marketplace, he/she is

entitled to fill in a form that will be submitted and received by the system administrator who later

assigns the ticket to the corresponding development. The interface below shows the ticket form.

The form contains certain specific fields that require detailed information from the clients

regarding the problem they are facing. i.e., Content field where the user fully describes the issues

that need attention, attachments field that allows the client to upload screen shots related to the

issue explained in the content field.

The client then submits the form by clicking the submit button.

Figure 5 Support Ticket interface

xxxvi

After the ticket has been submitted, the system administrator is then notified via email as shown

below.

Figure 6 Support Ticket sent to user.

The admin then clicks the button ‘View Full Ticket’ to access the ticket then assign it to the

development team.

Admin Section.

xxxvii

The section is only accessible to the administrator in charge of the system for monitoring the

overall activities for example tickets, payments and the donations.

The panel also contains a View Graphs button that when clicked displays charts that provide

insights to the admin regarding activities of the system.

Figure 7 Admin Dashboard

The admin has various permissions and among them is assigning the ticket received to the

corresponding development team.

Figure 8 assigning a developer to a support ticket

xxxviii

The admin has access to view all the tickets, payments and donations that were made by the

clients through the dashboard.

Figure 9 View showing all the support tickets

The admin can also edit the ticket using the buttons on the right-hand side. I.e. View, Edit,

Delete

Final approval for use

Identification:

Responsible for validation:

xxxix

Final approval for use

Remarks:

Date: Signature:

xl