finalyearprojectgroupzhome.files.wordpress.com · web viewname (s): kiggundu ismail ssali, ayesiga...
TRANSCRIPT
(BSSE 20-15)
(ICEngIM Payment and Transaction Service)
Software Design Document
Name (s): KIGGUNDU ISMAIL SSALI, AYESIGA TONY NSUBUGA, NYENDE MAHMOOD, ABUBAKARI SIMBA
Lab Section:
Workstation:
14
Date: 7TH December, 2020
Table of ContentsLIST OF TABLESvi1.INTRODUCTION11.1Purpose11.2Scope11.2.2Objectives11.3Document Overview21.4Definitions and Acronyms32.SYSTEM OVERVIEW43.System Architecture53.1Architectural Design.53.2 Decomposition Descriptions63.3Top level diagram for Payment and Transaction service83.4The use case diagrams93.4.1Make project purchase use case93.4.2Make donation use case103.4.3Support use case113.5Design Rationale114.DATA DESIGN124.1Data Description124.1.1Conceptual Design124.1.2PHYSICAL DESIGN134.1.3Logical Design174.1.4Domain analysis184.1.5Binary relationships184.1.6Data base and software utilities194.2Data Dictionary194.2.1Design decisions215.Component Design.215.1 System views226.HUMAN INTERFACE DESIGN266.1Overview of User Interface266.2Screen images276.3Screen Objects and Actions357.REQUIREMENTS MATRIX37
TABLE OF FIGURES
Figure 1: Architectural design5
Figure 2 : The modular composition of the ICEngM Payment and Transaction service.6
Figure 3 :The context diagram of the ICEngM payment and transaction service.8
Figure 4:The make purchase use case of the ICEngM payment and transaction service9
Figure 5: The donate use case of the ICEngM payment and transaction service10
Figure 6: The support ticket use case of the ICEngM payment and transaction service.11
Figure 7: The Conceptual Design12
Figure 8:The Component Diagram of the ICEngM payment and transaction service.22
Figure 9:The high-level overview of the payment sub-module23
Figure 10:: The high-level overview of the donation sub-module24
Figure 11:The high-level overview of the support sub-module.24
Figure 12: Customer Login Page.27
Figure 13: Payments Page28
Figure 14: Payment Succesful Interface29
Figure 15: Payment Unsuccessful Interface30
Figure 16: Choose Project to Donate to Interface31
Figure 17: Donation Form Interface32
Figure 18: Donation Payment Interface33
Figure 19: Donation Successful Interface34
Figure 20: Donation Unsuccessful Interface35
LIST OF TABLES
Table 1.1Definitions, acronyms and abbreviations.3
Table 4.1 Customer13
Table 4.2 Project13
Table 4.3 Transaction14
Table 4.4 Support-Ticket15
Table 4.5 Donor15
Table 4.6 Developer16
Table 4.7 Donation16
Table 4.8 Developer17
Table 4.9 Donor17
Table 4.10 Support ticket17
Table 4.11 Donation17
Table 4.12 Transaction17
Table 4.13 Project17
Table 4.14 Customer18
Table 4.15 During the domain analysis, we identified the following domains and their respective attributes.18
Table 4.16 shows the various software products that are legible for use in association with the databases of the Payment and Transaction service.19
Table 4.17 Data Dictionary19
Table 6.1 Screen Objects and Actions35
Table 7.1 Requirement matrix37
1. INTRODUCTION
This Software Design Document provides details about how the ICT and Engineering Innovation Marketplace Payment and Transaction Service (PTS) system will be implemented. It entails the system architecture, data design, component design, and human interface design and requirements matrix of the system. The document should be read by an individual with a technical background understand and interpret the theory and graphical content.
Purpose
The purpose of this document is to provide a description of the design of the Payment and Transaction Service system. It adequately provides the software development team with a better understanding of the system and how it will be built. Ultimately, it provides a comprehensive and detailed architectural overview of the system regarding the significant architectural decisions that have been made on the system. This document will be used by software developers, software architects, software testers and maintenance engineers.
1.2 Scope
The PTS system is a sub-system of the ICT and Engineering Innovation Marketplace and its purpose is to handle all payment transactions that will take place on the overall platform. The payment transactions will be in form of direct purchase of ready-made software artifacts, donations to projects and payment for Customer support provided by the development teams on the marketplace
1.2.1 Goal
To develop a Payment and Transaction Service system that will securely handle all the payment transactions on the marketplace in a secure and effective manner.
Objectives
· To implement a system that enables customers to make direct purchases for ready-to-use software artifacts and to raise funds through donations from well-wishers across the world.
· To create a platform that enables customers to request for support inform of additional features to the system and then make payment for the support provided.
1.2.2 Benefits
· Customers will be able to purchase ready-to-use software artifacts on the marketplace.
· Student premature projects will be able to receive funds through donations from the platform.
· Customers will be able to request for support from the development teams on the marketplace and then make payment for the support received.
1.3 Document Overview
This document entails the following sections;
· Introduction; this section describes the overview of the document and its significance to the project. It also consists of subsections like purpose, goal, objectives and benefits of the system.
· System overview; this section provides an abstract context and design of the Payment and Transaction Service system.
· Architecture; this section describes the architectural design, decomposition, description, and the design rationale of PTS system.
· Data design; this section gives information about how major entities are stored and organized. It also involves determining the system entities along with their types and descriptions.
· Component design; this section contains a closer look at what each component in the system does in a more systematic way.
· Human Interface Design; this section covers the overview of the user interface, screen images and screen objects together with their actions.
· Requirements Matrix; this section provides a cross-reference that traces components and data structures to the requirements in the SRS document.
· Appendices; this section provides supporting details that will aid the understanding of the Software Design Document
1.4 Definitions and Acronyms
Table 1.1 Definitions, acronyms and abbreviations.
Definition, acronym or abbreviation
Description
PTS
Payment Transaction Service
ICEngIM
ICT and Engineering Innovation Marketplace
CSS
Cascading Styling Sheet
HTML
Hyper Text Markup Language
API
Application Programming Interface
HTTPS
Hyper Text Transfer Protocol Secure
SDD
Software Design Document
2. SYSTEM OVERVIEW
1.1 Background Information
The Payment Transaction Service system is a sub-system of the ICT and Engineering Innovation Marketplace and its purpose is to handle all payment transactions that will take place on the platform. The system is centered on three main functionalities which are making direct purchases for ready-made software artifacts, donations to premature projects and tracking the donation analytics and providing customer support inform of added system features.
Every year, students develop innovative projects and prototypes that have been motivated by the community, research, and commercial problems. These innovations later reduce on the current problems and further provide effective solutions. In most cases, various development teams completely don’t have or have inadequate funds to support development of these projects to completion. Thus the proposed marketplace will provide a platform for interested donors to donate funds to different projects and allow the donor track the development of the projects. The proposed market-place will as well provide a channel for interested buyers to purchase ready and complete to use software artefacts to provide solutions to their respective problems and solutions in particular fields. It will as well provide a payment channel for any support provided by the development team to customers who purchased artifacts from the marketplace. The PTS system will be developed as a web application consisting of a customer side, server side and a database. Communication between the customer and server side will take place via HTTPS. The customer side will be designed with front end tools like HTML, JavaScript and CSS. The customer part runs in a web browser and communicates with the marketplace interface. The system will incorporate a payment API called Stripe a platform that will handle all the user data ranging from credit card details. A customer token will also be provided to the user for any transaction carried out.
3. System Architecture
This section discusses the architectural structure of the Payment and Transaction Service system. It describes the architectural design, decomposition description of each system feature.
3.1 Architectural Design.
The PTS system shall be based on a three-tier architecture composed of layers namely Presentation layer, Application layer and Data layer.
Figure 1: Architectural design
3.1.1 Presentation layer
This is the front-end layer in the 3-tier system and it consists of user interfaces. These user interfaces are graphical in nature and they are accessible through a web browser which displays content and information useful to the end user (Customers and administrators). The tier is built based on technologies such as HTML 5, CSS & JS and it communicates with other layers through API calls.
3.1.2 Application layer
This is often called the business logic layer and contains the functional business logic which drives the system’s core capabilities. The PTS system will be developed using PHP and Laravel framework.
3.1.3 Data Layer
This layer comprises of the PTS database in which all the payment transaction records will be stored and it will be developed using Structured Language Query.
3.2 Decomposition Descriptions
The decomposition diagram below shows the relationships between the modules constituted within the PTS system in collaboration with other modules on the ICT marketplace
Figure 2 : The modular composition of the ICEngM Payment and Transaction service.
The above architectural diagram of the Payment and Transaction Service contains certain modules as explained below:
a) Payment and Transaction Service Module
This module is responsible for all the payment and transactions that occur on the marketplace. It contains other sub-modules that include:
· Purchase sub-module
This sub-module specifically handles direct purchases of the complete ready-to-use artefacts uploaded in the collaboration module. It provides an interface to Customers that enables them choose a payment plan and also enter their payment credentials as required via various channels such as VISA, Mobile Money, Mpesa money and PayPal.
· Donation sub-module
This sub-module provides an interface to Customers that enable them to donate to their preferred projects.
· Support sub-module
This sub-model enables Customers submit support issues to the development team and also handle the payment of the support fee as agreed between the Customer and development team on the marketplace.
b) Payment Gateway (Stripe)
This module receives, verifies and processes all user data from the above sub-models especially payment details so that it allocates accurate funds to the merchant account. It also contains secure measures that prevent any kind of fraud to user information especially regarding payment credential such as credit card PINs.
c) Payment Database
This module is responsible for storing and retrieving payment and transaction details for example Customer names and their respective information such as emails, payments and corresponding donations. This helps in proper record keeping for purposes of accurate analytics.
3.3 Top level diagram for Payment and Transaction service
The context diagram below shows the main actors that interact with the sub-system.
Figure 3 :The context diagram of the ICEngM payment and transaction service.
3.4 The use case diagrams3.4.1 Make project purchase use case
Figure 4:The make purchase use case of the ICEngM payment and transaction service
3.4.2 Make donation use case
Figure 5: The donate use case of the ICEngM payment and transaction service
3.4.3 Support use case
Figure 6: The support ticket use case of the ICEngM payment and transaction service.
3.5 Design Rationale
Customer-server Architecture provides benefits for production and development environments by modularizing the user interface, business logic, and storage layers. Doing so gives greater flexibility to development teams by allowing them to update specific part of an application independently on the other parts. This added flexibility can improve overall time to market and decrease development cycle times by giving the development team the ability to replace or upgrade independent tiers without affecting other parts of the system. For example, the user interface of the IoT market place could be redeveloped or modernized without affecting the underlying functional business and data access logic underneath.
4. DATA DESIGN4.1 Data Description4.1.1 Conceptual Design
Figure 7: The Conceptual Design
4.1.2 PHYSICAL DESIGN
Customer table
Table 4.1 Customer
Attribute
Domain name
Data type
Length
Constraints
Keys
user_id
Customer identification number
Integer
11
Not null
Primary
username
Customer username
Varchar
255
Not null
Roles
Customer role
Varchar
Not null
password
Customer password
Varchar
255
Not null
Project Table
Table 4.2 Project
Attribute
Domain name
Data type
Length
Constraints
Keys
project_id
Project identification number
Integer
11
Not null
Primary
Title
Project username
Varchar
255
Not null
Icon
Project icon
Varchar
255
Not null
description
Project password
Long text
255
Not null
published_at
Project publish date
Date
Not null
category
Project category
Varchar
255
Null
Transaction table
Table 4.3 Transaction
Attribute
Domain name
Data type
Length
Constraints
Keys
Date
Transaction date
Date
Not null
amount
Transaction amount
Integer
11
Not null
transaction_id
Transaction identification number
Integer
11
Not null
Primary
payment_mode
Payment mode
Integer
11
Not null
Support ticket table
Table 4.4 Support-Ticket
Attribute
Domain Name
Data Type
length
Constraints
Keys
Date
Date of request
DATE & TIME
NO
amount
Amount
INT
11
NO
support_ticket_id
Support_ticket identification
INT
11
NO
payment_mode
Payment mode
INT
11
NO
transaction_id
Transaction identification
INT
11
NO
project_id
Project identification
INT
11
NO
priority
Priority
VARCHAR
255
NO
Donor table
Table 4.5 Donor
Attribute
Domain Name
Data Type
length
Constraints
Keys
donor_id
Donor identification
INT
11
NO
organization
Organization
VARCHAR
255
YES
Name
Name
VARCHAR
255
YES
Developer table
Table 4.6 Developer
Attribute
Domain Name
Data Type
length
Constraints
Keys
Name
Name
VARCHAR
255
Not null
user_id
User identification
INT
11
Not null
developer_id
Developer identification
INT
11
Not null
Donation table
Table 4.7 Donation
Attribute
Domain Name
Data Type
length
Constraints
Keys
donation_id
Name
VARCHAR
255
Not null
donor_id
User identification
INT
11
Not null
project_id
Developer identification
INT
11
Not null
amount
Developer identification
INT
11
Not null
date
Developer identification
INT
11
Not null
4.1.3 Logical Design
Developer
Table 4.8 Developer
name
user_id
developer_id
Donor
Table 4.9 Donor
name
Donor_id
organisation
User_id
Support ticket
Table 4.10 Support ticket
Date
amount
Support_ticket_id
payment_mode
transaction_id
project_id
priority
Donation
Table 4.11 Donation
donation_id
user_id
project_id
amount
date
Transaction
Table 4.12 Transaction
Date
Amount
transaction_id
payment_mode
Project
Table 4.13 Project
project_id
title
icon
description
published_at
category
User
Table 4.14 Customer
user_id
username
roles
password
4.1.4 Domain analysis
Table 4.15 During the domain analysis, we identified the following domains and their respective attributes.
Domain
Attributes
General User
{first name, last name, mobile number, user ID[PK], nationality, date of birth}
Donor
{ user ID [FK], organization name, donor ID[PK]}
Transaction
{Date, amount, payment mode, transaction ID[PK] }
Donation
{Date, amount, payment mode, donor ID[PK], transaction ID [FK] , project ID[FK] , donation ID[FK] }
Developer
{name, developer ID[PK], user ID[FK]}
Project
{user manual, project ID[PK], developer ID[FK]}
Pay mode
{name, ID[PK] }
Payment status
{status, ID[PK] }
Support ticket
{Date, amount, payment mode, support ID[PK], transaction ID [FK] , project ID[FK], Priority}
4.1.5 Binary relationships
One to many general users can purchase one to many complete projects.
One to many developers make one to many uploads for purchase or support.
One to many donors donate to one to many incomplete projects.
One to many collaborators join one to many incomplete projects via support tickets.
One to many general users make one to many transactions.
One to many general users make transactions using one to many payment modes.
One to many donors offer one or more donations.
One to many donations involve one to many transactions.
4.1.6 Data base and software utilities
Table 4.16 shows the various software products that are legible for use in association with the databases of the Payment and Transaction service.
Vendor
Product
Version
Comments
Laravel software
Laravel
Edition 8.*
laravel-based free and open-source web framework
MYSQL
MYSQL
Edition 3.*
Relational database management system contained in a C library.
4.2 Data Dictionary
Table 4.17 Data Dictionary
Table Name
Fields
Type
Null
Default
User
User_id
INT(11)
NO
NULL
Username
VARCHAR(255)
NO
NULL
Role
JSON
NO
NULL
Password
VARCHAR(255)
NO
NULL
Project
Project_id
INT(11)
NO
NULL
Title
VARCHAR(255)
NO
NULL
Icon
VARCHAR(255)
NO
NULL
Description
LONG TEXT
NO
NULL
Published at
DATE TIME
NO
NULL
Category
VARCHAR(255)
YES
NULL
Transaction
Date
DATE(10)
NO
NULL
Amount
INT(11)
NO
NULL
transaction_id
INT(11)
NO
NULL
Payment_mode
INT(11)
NO
NULL
Donation
Donation_id
INT(11)
NO
NULL
User_id
INT(11)
YES
NULL
Project_id
INT(11)
YES
NULL
Amount
INT(11)
NO
NULL
Created at
DATE TIME
NO
NULL
Payment_mode
INT(11)
NO
NULL
Payment status
Paystatus_id
INT(11)
NO
NULL
Status
VARCHAR(255)
NO
NULL
Payment mode
Paymode_id
INT(11)
NO
NULL
Name
VARCHAR(255)
NO
NULL
Support ticket
Date
DATETIME
NO
NULL
Amount
INT(11)
NO
NULL
Support_ticket_id
INT(11)
NO
NULL
Payment_mode
INT(11)
NO
NULL
transaction_id
INT(11)
NO
NULL
project_id
INT(11)
NO
NULL
Priority
VARCHAR(255)
NO
NULL
Donor
Donor_id
INT(11)
NO
NULL
Organization
VARCHAR(255)
YES
NULL
Name
VARCHAR(255)
YES
NULL
User_id
INT(11)
NO
NULL
Developer
Name
VARCHAR(255)
YES
NULL
User_id
INT(11)
NO
NULL
Developer_id
INT(11)
NO
NULL
4.2.1 Design decisions
· A general user has to sign up or log in before they access the Payment and Transaction Module.
· A general user can be a developer, normal user or donor.
· The payment view will be a button to the actual page.
5. Component Design.
The Payment and Transaction Service high level architecture comprises of views, modules and databases. The component diagram below shows the system components and their interrelations.
Figure 8:The Component Diagram of the ICEngM payment and transaction service.
5.1 System views
A system view is an expression that is meant to remind you that you should focus on the whole system and prevent you from sub-optimizing parts of it. It is basically what a computer user is able to see on the computer screen. The users’ view of the computer varies according to the interface being used. Our system will have the following views;
· Customers View
This is will be used to capture Customer details involved in purchasing the software projects on the platform for example Customer credentials and payment methods among others.
· Donor View
This view is intended to be used by donors willing to donate to the projects on the platform.
It will basically capture donor details such as contact and payment details
· Developer View
This view is intended for the developers that came up with the platform for purposes of attending to any support flags being raised by Customers that have purchased the projects and have deployed them into production.
Figure 9:The high-level overview of the payment sub-module
Figure 10:: The high-level overview of the donation sub-module
Figure 11:The high-level overview of the support sub-module.
5.2 Database
These act as the repository for the systems information. The Payment and Transaction Service will only have one database called Payment and Transaction Service Database. This database will store information for all the payments and transactions that take place across the platform
6. HUMAN INTERFACE DESIGN6.1 Overview of User Interface
· Purchase
The user navigates the projects page through various categories until he chooses a project of his choice and that which matches his desired purpose. The selected project is then added to his cart which he refers to make payment. After user checks out and the selects a preferred payment method from those provided. The user then fills the payment details in regard to his choice and then submits by clicking the submit button. A pop up is the displayed showing the payment status whether successful, unsuccessful or pending.
· Donation
The user navigates through the page containing projects that require donations. The donor chooses the project of their choice by clicking on their preferred project. The donor is later provided with a donation form which he fills and later click on the donate button. The donate button will direct him to the payment methods page where he will be required to choose a method of his choice, fill and submit the payment details as required. A pop up is displayed showing the current status whether the donation details were successfully received, unsuccessful or pending due to some missing details.
· Support ticket
The customer will fill a support form and then submit the form by clicking the submit button. After some time, the ticket will be assigned a development team whose details he receives and then negotiates payment and other related issues such as time via comments. After the ticket price has been agreement upon, the customer is directed to a payment form and selects a payment method of their choice, fills and submits the details by clicking the pay button. A pop up is displayed to acknowledge the receipt of the payment and more payment details forwarded to the customers’ email.
6.2 Screen images
· Customer login page
All customers attached to the marketplace must have accounts and they will have to login before making any payment transaction.
Figure 12: Customer Login Page.
· Making Payment
Once a customer chooses a project to purchase, they will be directed to payment form where they will choose a payment method, enter their payment details and finally make payment.
Figure 13: Payments Page
· Payment status notification status
After a customer submits their payment, their payment status will be provided inform of a pop up whether it’s successful or unsuccessful.
Figure 14: Payment Succesful Interface
Figure 15: Payment Unsuccessful Interface
· Choose project to donate to
A donor will have to first choose a project of their choice to donate to
Figure 16: Choose Project to Donate to Interface
· Make donation
After choosing a project to donate to, the donor will be required to fill in some donation details such as names, phone number, email and the amount they wish to donate.
Figure 17: Donation Form Interface
· Make donation payment
The customer will then be directed to a payment page where they will choose their preferred payment method and finally make the donation.
Figure 18: Donation Payment Interface
· Donation notification status
After a donor submits their donation, their donation status will be provided inform of a pop up whether it’s successful or unsuccessful
Figure 19: Donation Successful Interface
Figure 20: Donation Unsuccessful Interface
6.3 Screen Objects and Actions
Table 6.1 Screen Objects and Actions
Screen Object
Actions taken
Result
Payment Form
A user inputs his/her payment detail
The details are captured
Pay Button
A user clicks it to make a payment
Payment confirmation page is displayed once the process is successful.
Donate button
A user clicks it to make a donation.
Donation confirmation page is displayed once the process is successful.
Donation Form
A user inputs his/her donation detail.
Donation details captured.
Radio Buttons
A user chooses only one of the payment methods/Ticket type / Priority
Payment form displayed according to the method chosen. Ticket type and priority are also chosen.
Checkbox
A user chooses which project feature to donate to.
Chosen features displayed.
User account icon
A user clicks it to check his account details
User account displayed.
7. REQUIREMENTS MATRIX
The system has three main components- payment, donation and support. The matrix below shows the requirements that map to each component.
Table 7.1 Requirement matrix
COMPONENTS
REQUIREMENTS ID
REQ-1
REQ-2
REQ-3
REQ-4
REQ-5
REQ-7
REQ-8
REQ-9
PAYMENT
X
X
X
X
X
DONATION
X
X
X
X
SUPPORT
X
References
1. Ayo CK, Adewoye JO, Oni AA. The state of e-banking implementation in Nigeria: A post-consolidation review. Journal of Emerging Trends in Economics and Management Sciences. 2010; 1(1):37–45.
2. Oyewole OS, Abba M, El-maude JG. E-banking and bank performance: Evidence from Nigeria. International Journal of Scientific Engineering and Technology (IJSET). 2013; 2(8):766–71.
3. Oyewole OS, El-Maude JG, Abba M, Onuh ME. Electronic payment system and economic growth: a review of transition to cashless economy in Nigeria. International Journal of Scientific and Engineering Research. 2013; 2(9):913–8.
4. Singh A, Singh K, Shahazad, Khan MH, Chandra M. A review: secure payment system for electronic transaction. International Journal of Advanced Research in Computer Science and Software Engineering. 2012 Mar; 2(3): 236–43.
5. Shilpa, Sharma P. Advance technique for online payment security in e-commerce: Double Verification. International Journal on Computer Science and Engineering. 2013 Jun 1; 5(6):508–13.
6. Abrazhevich D. Electronic payment systems: A user-centered perspective and interaction design. Dennis Abrazhevich; Eindhoven, Netherland: Technische. 2004; 1–202.
7. Roy S, Sinha I. Determinants of customers’ acceptance of electronic payment system in Indian banking sector–a study. International Journal of Scientific and Engineering Research. 2014; 5(1):177–87.
8. Kabir MA, Saidin SZ, Ahmi A. Adoption of e-payment systems: a review of literature, International Conference on E-Commerce, Kuching, Sarawak. 2015. p. 112–20.
9. Electronic Briggs A, Brooks L. Electronic payment systems development in a developing country: The role of institutional arrangements. The Electronic Journal of Information Systems in Developing Countries. 2011 Sep 24; 49(3):1–16.
10. Slozko O, Pelo A. Problems and risks of digital technologies introduction into e-payments. Transformation in Business and Economics. 2015 Jan 1; 14(1):42–59.
11. Lu S, Smolka SA. Model checking the secure electronic transaction (SET) protocol. 7th International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, IEEE.1999; 358–64. Crossref
12. Guttmann R. Cybercash: the coming era of electronic money. Springer. 2002 Oct 22.
13. Sirbu M, Tygar JD. NetBill: An internet commerce system optimized for network-delivered services. IEEE Personal Communications. 1995 Aug; 2(4):34–9. Crossref
14. First Virtual Internet Payment System. Available from: Crossref. Date accessed: 15/02/2017.
15. Nuthan K, Rashmi PC. An E-payment System: Literature Review. First International Conference on Recent Advances in Science & Engineering, 2014.
16. Fiallos F, Wu L. Digital Money: Future Trends and Impact on Banking. Financial Institutions, and eBusiness. 2005.
17. Appiah A, Agyemang F. Electronic retail payment systems: user acceptability and payment problems in Ghana. In: School of Management Business Administration Blekinge Institute of Technology, Sweden. 2006.
18. Kumaga D. The challenges of implementing electronic payment systems–The case of Ghana’s E-zwich payment system. 2012; 1(3):1–9.
19. Taddesse W, Kidan TG. e-Payment: Challenges and opportunities in Ethiopia. United Nations Economic Commission for Africa. 2005 Oct.
20. Siyanbola TT. The effect of cashless banking on Nigerian economy. eCanadian Journal of Accounting and Finance. 2013; 1(2):9–19.
CustomerCustomer_idPKUsernameRolesSupport TicketSupport_ticket_idPKAmountTransactionTransaction_idPKDateDonationDonation_idPKDonor_idFKProjectProject_IdPKTitleIconDeveloperDeveloper_idPKCustomer_idFKNameDonorDonor_idPKOrganisationNamePasswordTransaction_idFKProject_idPriorityAmountProject_IDFKAmountDateCustomer_idFKDescriptionPublished_atCategoryRequestsPaysMakesReceivesMakesAccepts
CustomerTableCustomer_idPKFKUsernamePKFKRolesPKFKSupport TicketTableSupport_ticket_idPKFKAmountPKFKTransactionTableTransaction_idPKFKDatePKFKDonationTableDonation_idPKFKDonor_idPKFKProjectTableProject_IdPKFKTitlePKFKIconPKFKDeveloperTableDeveloper_idPKFKCustomer_idPKFKNamePKFKDonorTableDonor_idPKFKOrganisationPKFKNamePKFKPasswordPKFKTransaction_idPKFKProject_idPKFKPriorityPKFKAmountPKFKProject_IDPKFKAmountPKFKDatePKFKCustomer_idPKFKDescriptionPKFKPublished_atPKFKCategoryPKFKRequestsPaysMakesReceivesMakesAccepts