(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