0% found this document useful (0 votes)
17 views83 pages

SRS For PSO

This document contains requirements for the GBL Fintech Ltd. application. It provides an overview of the technical architecture and outlines sections for introduction, system overview with various diagrams, functional requirements including scopes, attributes and use cases, and non-functional requirements. The document aims to cover all aspects of requirement gathering, analysis, and development guidelines for the GBL Fintech application.

Uploaded by

Rakib Chowdhury
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views83 pages

SRS For PSO

This document contains requirements for the GBL Fintech Ltd. application. It provides an overview of the technical architecture and outlines sections for introduction, system overview with various diagrams, functional requirements including scopes, attributes and use cases, and non-functional requirements. The document aims to cover all aspects of requirement gathering, analysis, and development guidelines for the GBL Fintech application.

Uploaded by

Rakib Chowdhury
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 83

• Requirements for GBL Fintech Ltd.

• Technical Architecture design

GBL FINTECH GBL Fintech Ltd.

This document contains the requirements, mythology,


human resource, infrastructure info about the GBL Fintech
Ltd.’s application. This document provide end to end
overview and details about requirement gathering,
requirement analysis, guideline of development.
SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Contents
1 Introduction.......................................................................................................................................... 5
Purpose ..................................................................................................................................................... 5
Document Conventions ............................................................................................................................ 5
Intended Audience and Reading Suggestions........................................................................................... 5
GBL Fintech Scopes: .................................................................................................................................. 6
GBL Fintech Requirements: ...................................................................................................................... 7
GBL Fintech Functional Overview: .......................................................................................................... 10
2 Overview of the Module / Software................................................................................................ 12
GBL Fintech Management – Activity Diagram ........................................................................................ 12
GBL Fintech Management – Level 0 Diagram ......................................................................................... 14
GBL Fintech Management – Level 1 Diagram ......................................................................................... 15
GBL Fintech Management – Level 2 Diagram ......................................................................................... 16
ERD .......................................................................................................................................................... 18
ER Diagram (Conceptual) of Fintech System: ..................................................................................... 18
ER Diagram (DB) of Fintech System: ................................................................................................... 19
Process Flow ........................................................................................................................................... 20
GBL Fintech Process Flow ................................................................................................................... 20
Admin Process..................................................................................................................................... 22
Merchant Process ............................................................................................................................... 24
Payment Process ................................................................................................................................ 26
Payment Dispute Process.................................................................................................................... 27
Security Process .................................................................................................................................. 28
3 Functional Requirements – Scopes, Attributes & Use Cases ................................................... 30
Manage Payment Service Integration..................................................................................................... 30
Attribute List of Scope ..................................................................................................................... 30
Use Cases ......................................................................................................................................... 31
Manage Merchant Information .............................................................................................................. 35
Attribute List of Scope ..................................................................................................................... 35
Use Cases ......................................................................................................................................... 36
Manage Integration of Merchant's online payment service .................................................................. 40
Attribute List of Scope ..................................................................................................................... 40
Use Cases ......................................................................................................................................... 40

Developed By: GBL Fintech Ltd. Page 1 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Payment Request for Merchant ............................................................................................... 42


UI ........................................................................................................................................................ 43
Attribute List of Scope Transaction................................................................................................ 43
Use Cases ......................................................................................................................................... 45
Manage Dispute ...................................................................................................................................... 49
UI ........................................................................................................................................................ 50
Attribute List of Scope ..................................................................................................................... 50
Use Cases ......................................................................................................................................... 51
Manage System Notification / Messages ............................................................................................... 53
General Payment Notification: ........................................................................................................... 53
Escrow Payment .................................................................................................................................. 53
Dispute Notification: ........................................................................................................................... 53
Common Message / Notification for any transaction except describing before:............................... 53
Manage User Information....................................................................................................................... 54
Attribute List of Scope ..................................................................................................................... 54
Use Cases ......................................................................................................................................... 55
Manage Role Information ....................................................................................................................... 59
Attribute List of Scope ..................................................................................................................... 59
Use Cases ......................................................................................................................................... 59
Manage Password Reset Information .................................................................................................... 63
Attribute List of Scope ..................................................................................................................... 63
Use Cases ......................................................................................................................................... 63
Manage Fintech Reports ......................................................................................................................... 65
Invoice Generation .............................................................................................................................. 66
All Transaction Report Generation ..................................................................................................... 68
Merchant Wise Daily Transaction Report Generation ........................................................................ 70
Method Wise Daily Transaction Report Generation........................................................................... 72
4. Non-Functional Requirements ................................................................................................................ 74
A. System Requirements ......................................................................................................................... 74
Hardware ............................................................................................................................................ 74
Software: ............................................................................................................................................. 75
Hardware Inventory ............................................................................................................................ 76
Engineering Environment ................................................................................................................... 76

Developed By: GBL Fintech Ltd. Page 2 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

B. External Interface................................................................................................................................ 77
C. SSL ....................................................................................................................................................... 77
D. Data Specification ............................................................................................................................... 77
E. Integration........................................................................................................................................... 78
Payment Services Integration ............................................................................................................. 78
Transaction Monitoring Systems ........................................................................................................ 79
eKYC .................................................................................................................................................... 80
5. Appendix ................................................................................................................................................. 82
Glossary ................................................................................................................................................... 82

Developed By: GBL Fintech Ltd. Page 3 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

List of Figures

Figure 1: Activity Diagram of GBL Fintech .......................................................................................... 12


Figure 2: DFD of GBL Fintech – Level 0 ............................................................................................. 14
Figure 3: DFD of GBL Fintech – Level 1 ............................................................................................. 15
Figure 4: DFD of GBL Fintech – Level 2 ............................................................................................. 16
Figure 5: ERD of GBL Fintech System .............................................................................................. 18
Figure 6: ER Diagram (DB) of GBL Fintech System ........................................................................... 19
Figure 7: GBL Fintech Process of GBL Fintech System ....................................................................... 20
Figure 8: Admin Process of GBL Fintech System ................................................................................ 22
Figure 9: Merchant Manage of GBL Fintech System ........................................................................... 24
Figure 10: Payment Process of GBL Fintech System .......................................................................... 26
Figure 11: Payment Dispute Process of GBL Fintech System .............................................................. 27
Figure 12: Security Mechanism of GBL Fintech System ...................................................................... 29
Figure 13: Integration of GBL Fintech System ..................................................................................... 78

List of Tables

Table 1: Reports ............................................................................................................................... 65

Revision History

Date Version Short Description Author


December 20, 1.0 First Version GBL Fintech Ltd.
2022

Developed By: GBL Fintech Ltd. Page 4 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

1 Introduction

Purpose

The purpose of this Software Requirements Specification (SRS) document is to provide a


detailed description of the functionalities of the GBL Fintech system. This document will cover
each of the system’s intended features. The document will also cover hardware, software, and
various other technical dependencies. This document is intended to give brief description and
work flow and diagram to illustrated data flow, process flow, activity diagram and many more.
This SRS will be used to create mapping towards our GBL payment system operation and
management description.

Document Conventions

Methods of defining an SRS are described by the IEEE (Institute of Electrical and Electronics
Engineers) specification 830-1998.

Intended Audience and Reading Suggestions

The document is intended for requirements engineer, domain expert, developer and project
manager. Before reading this document, it is highly recommended to read the Vision Document
to get an overview of the GBL payment management system or payment system operations.
While the software requirement specification (SRS) document is written for a internal audience,
this document is intended for individuals directly involved in the development of GBL. This
includes software developers, project consultants, team managers, approve body related to this
software quality body and policy makers. This document need not be read sequentially; users
are encouraged to jump to any section they find relevant. Below is a brief overview of each part
of the document.

• Part 1 (Introduction) This part offers a summary of the global pay project, including goals
and objectives, project scope, general system details, and some major constraints
associated with the intended platform. Consists with purpose, document convention,
internal audience and reading suggestions, GBL fintech scopes, requirements and GBL
fintech functional overview.

• Part 2 (Overview of the Module / Software): this part deals with Readers interested in
how GBL organizes and handles the modules of the system should consult this section,
which covers process and flow patterns (Activity Diagram, Level 0,1,& 2 DFD, ERD) and
Process Flows (Software Technical Process Flow, Admin Process, Merchant Process,

Developed By: GBL Fintech Ltd. Page 5 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Payment Process, Payment Dispute Process and Security Process) utilized by the
system.

• Part 3 (Functional Requirements - Scopes, Attributes & Use Cases) This part describes the
GBL system Scopes, Attributes & Use Cases). This part has 10 (ten) scopes with its
attributes and use cases as follows:

o Payment Service Integration.


o Merchant: Information.
o Integration of Merchant Online Payment.
o Payment Request to Merchant.
o Dispute.
o System Notification / Messages.
o User Information.
o Role Information.
o Password Reset and
o Reports: this section describes how the report part of the system acts to the full
system. It consists of report description of invoice generation, all transaction
report generation, merchant wise daily transaction report, method wise daily
transaction report and monthly merchant on board report generation.

• Part 4 (Non-Functional Requirement) This part covers Non-Functional Requirements like


System Requirement (Hardware, Software, Hardware Inventory, Engineering
Requirements), External Interface, SSL and Data Specification.

• Part 5 (Appendices) This part includes Glossary which may be helpful to readers

GBL Fintech Scopes:


1. Integration of different types and organizations payment services (Bank, MFS, Internet
Banking, Wallets etc.).
2. Provides API to interact with the integrated payment services.
3. Merchants Registration process.
4. Integration of Merchant's online payment service by the Global Pay API.
5. Buyer / Customer (online buyers or online money payers) pay to the merchant for its products
/ service of other payments (bill, fees etc.).
6. Global Pay receives the buyer / customer / money payers given payment.
7. If no condition then sends to merchant's account from Global Pay Account (Trust Cum
Settlement Account).
8. If any condition (escrow - it is for eCommerce which need to buyer's acceptance for receiving
goods or services) then after acceptance the payment sends to Merchant’s Account from
Global Pay Account (TCSA).

Developed By: GBL Fintech Ltd. Page 6 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

9. If any dispute, raised by buyer forwarded to Merchant by Global Admin. Global Pay Holds the
Dispute Amount from the next / running payment received.
10. After acceptances from Merchant, Global Pay returned / Charged Back to Buyer Account.
11. If Dispute nor accepted then notify the buyer.

GBL Fintech Requirements:

1. Bank & MFS Integration

• GBL Fintech System will integrate the acquiring banks online payment system according to
each of their system process.
• MFS API will be integrated with GBL fintech system for MFS payment.
• iBankig API will be integrated of all available banks who provide this service for the faster and
cheaper transactions.

2. Super Admin

Dashboard
• Number of Successful Transactions
• Number of Initiated Transactions
• Number of Cancel/Failed/Declined Transactions
• Amount of Successful Transactions
• Amount of Initiated Transactions
• Amount of Cancel/Failed/Declined Transactions
• Today's/Date Wise/Payment Options Wise Transactions History
Merchant
• Register New Merchants
• Merchant Profile
• Merchant Store
• Merchant Store ID list
• Merchant Bank Account Details
• Merchant KYC
• Notice
• Document/Plugin/Module
• Merchant Password Changes
• Activate New Merchant
• Sub Domain Activation

Developed By: GBL Fintech Ltd. Page 7 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• Gateway Settings
• MID Activation
• Disbursement Setup
• Merchant Documentation
• QR Code Generator
• All Merchant Information
Payment
• View Transaction History
• Chargeback History
• Refund History
• MFS Transaction List
• Bank Transaction List
• Search Transaction
Dispute
Transaction Monitoring
Escrow
Withdraw/Settlement
• Manage Withdraw
• Withdraw Settings
• Withdraw Request History
• Withdraw Settlement History
Management
• View All Transaction Report
• Merchant Wise Daily Transaction Report
• Method Wise Daily Transaction Report
• Monthly Transaction Report
• Monthly Withdraw Report
• Monthly Merchant on Board Report
• Month & Year Wise Transaction Report
Settings
• Create User
• IP Block Settings
• Send SMS Notice
Activity Log
Logout

3. Merchant Super Admin

Merchant panel:
Dashboard
• Available Balance
• Total Paid Amount
• Total Transaction Amount

Developed By: GBL Fintech Ltd. Page 8 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• Today’s Total Transaction Amount


• Yesterday Total Transaction Amount
• Current Month Total Transaction Amount
• Previous Month Total Transaction Amount
Transaction
• Payment Statement
• All Statement
• Success Transaction History
• Failed/Declined Transaction History
• Search Transaction
Bank Account
• Bank Account Entry
Merchant Withdraw Request
Invoice Generator
• Create Invoice
• Invoice List
Documents & Plugin
• Documents & Plugin List
Privacy & Policy
• Settlement Policy
Settings
• Profile
• Password Change
Logout

4. Additional
E-MAIL/SMS NOTIFICATIONS
• Extends the standard notifications service built into GBL Fintech
• Automatically delivers notifications via e-mail and/or text message
GBL Fintech Tutorial
• Provides an abridged version of the Help menu for first-time users
• Offers a step-by-step run through of each feature, menu, etc.
• Enables any user to quickly and easily take advantage of all of GBL Fintech
system functionalities
• A major functionality present in several of these features is automatic synchronization.
Using internet capabilities, the application periodically communicates with the GBL
Fintech server. This allows bills, transactions, withdraws, and group histories to be
uploaded to a central server where the data can be shared with all other application
users. This process of exchanging data between the server and the applications using
web browser or devices is referred to as syncing.
• For more detailed information, see the document System Features.

Developed By: GBL Fintech Ltd. Page 9 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

GBL Fintech Functional Overview:

GBL Fintech Functional Scope Analysis

Module Feature Actor/User Feature Description


Admin Authentication GBL Admin User & Password Authentication by
the system. If not matched the
authentication,, then Decline to enter
the system. If authentication
accepted, then system displays the
authenticated features and functions
(menu option active or inactive).

Merchant Authentication Merchant User & Password Authentication by


the system. If not matched the
authentication, then Decline to enter
the system. If authentication
accepted, then system displays the
authenticated features and functions
(menu option active or inactive).
Merchant Registration Merchant Add, Update Request and View
Merchant Registration Information.
Buyer Information Merchant Import and View Merchant Store
Information.
Escrow Shipping Merchant Add, Update and View Escorw
Information Shipping Information.
Notification Merchant View Notification Information.
Payment information Merchant View Payment Information
Invoice Information Merchant View Invoice Information
Dispute Manage Merchant Update and View Dispute
Information.

Payment Payment Process Merchant User & Password Authentication by


Process the system. If not matched the
authentication,, then Decline to enter
the system. If authentication
accepted, then system displays the
authenticated features and functions
(menu option active or inactive).
Payment Dispute Buyer Buyer/Customer Opens GBL
application to raise the Dispute. GBL
System Validates transaction
number. Merchant selects dispute - If
disputes found OK with decision
making then the process ends OR

Developed By: GBL Fintech Ltd. Page 10 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Module Feature Actor/User Feature Description


dispute found not OK, then go for
another dispute selection

Merchant Merchant get Dispute Notification.


Escrow Information System Add and view Escrow Information.
Transaction System Add and View Transaction.
Dispute Buyer Add, update and View Dispute
Merchant View and Accept or Reject Dispute

Security Security Management System System receives the user, password


and validate. If authentication is OK,
then allows user to the system.
SSL System It is a Third Party service integrated
to the system.
User Admin, Add, view, update and delete the
Merchant user of two major groups: GBL
Admin and Merchant.
Role Admin Add, view, update and delete user
role.
User Information
Password Reset by User update the user password.
user Specific

Reports Invoice Generation System Generates and Displays the Report


Merchant Viewed the Report
Admin viewed the Report
All Transaction System Generates and Displays the Report
Merchant viewed the Report
Admin viewed the Report
Merchant wise Daily System Generates and Displays the Report
Transaction
Merchant viewed the Report
Admin viewed the Report
Method wise Daily System Generates and Displays the Report
Transaction
Merchant viewed the Report
Admin viewed the Report
Monthly Merchant on System Generates and Displays the Report
Board
Merchant viewed the Report
Admin viewed the Report

Developed By: GBL Fintech Ltd. Page 11 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

2 Overview of the Module / Software


GBL is a one stop solution to make payment, purchase with different debit/credit card, bank
accounts, coupon etc. Also make sure payment is frictionless, transparent and secure.
.The interaction between GBL Fintech User in the current system is depicted in the diagrams
below:

GBL Fintech Management – Activity Diagram

Figure 1: Activity Diagram of GBL Fintech

GBL Fintech Management:

• User Authentication

Developed By: GBL Fintech Ltd. Page 12 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• Payment Services Integration


• Merchant Registration
• Import Buyer / Online Payment Giver Information
• Provide Global Pay API
• Integrates Merchant's eCommerce
• Online Payment Receives
• Receives Online Payment in TCSA A/C
• Dispute Raised by Buyer
• GBL Admin Holds Dispute Amount
• Receives Acceptance / Disagree from Merchant
• Settlement of Dispute
• Log Out

Developed By: GBL Fintech Ltd. Page 13 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

GBL Fintech Management – Level 0 Diagram

Figure 2: DFD of GBL Fintech – Level 0

GBL Fintech Management:

• Payment Management Note


• User Management
• Transaction Management
• Security Management
• Dispute Management
• Escrow

Developed By: GBL Fintech Ltd. Page 14 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

GBL Fintech Management – Level 1 Diagram

Figure 3: DFD of GBL Fintech – Level 1

GBL Fintech Management:


• Users: Admin, Merchant and Customer.
• Admin user add GBL Fintech Configuration.’
• Merchants Registered, sets Gateway. manages Payment Request and Dispute manage.
• Customers/Buyers Payments by eCommerce and set Dispute.

Developed By: GBL Fintech Ltd. Page 15 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

GBL Fintech Management – Level 2 Diagram

Figure 4: DFD of GBL Fintech – Level 2

Developed By: GBL Fintech Ltd. Page 16 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

GBL Fintech Management:


This system begins with Configuration insertion process which consists of:

• Create User
• IP Block Settings
• Send SMS Notice
• Bank with Branch Information
• Notice Settings
• MID Activation
• Bank Charge setup

Then the system goes for Merchant Registration which starts with Merchant entity’s application,
then the process consists with:

• Merchant Bank Account Setup


• Merchant User creation with Password and authentication settings
• Merchant Approval
• Merchant Activate
• Gateway Settings
• Disbursement Settings
• Customer Add
• QR Code Generation Setup

Then Customer go to Payment through Checkout process. It has two types of payment as follows:

• General
• Escrow

Escrow has Withdraw Request then go for actual Transactions. General Payment straight goes
to Transaction.
The system has Dispute process to mitigate any dispute incident.
So the whole process has 9 processes as follows:
1. User Authentication
2. Configuration Insert
3. Merchant Registration
4. Customer Add
5. Payment Request with Escrow
6. Payment Request with General
7. Payment Escrow Withdrawal Request
8. Payment Transaction
9. Dispute

Developed By: GBL Fintech Ltd. Page 17 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

ERD
ER Diagram (Conceptual) of Fintech System:

Figure 5: ERD of GBL Fintech System

Developed By: GBL Fintech Ltd. Page 18 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

ER Diagram (DB) of Fintech System:

Figure 6: ER Diagram (DB) of GBL Fintech System

Developed By: GBL Fintech Ltd. Page 19 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Process Flow
GBL Fintech Process Flow

Figure 7: GBL Fintech Process of GBL Fintech System

GBL Fintech Process

• System starts with Payment Portal Integration. GBL Fintech integrates different types of Payment Services
/ Portals like Mobile Banking, Internet Banking, Payment Wallets etc.
• After the integration GBL Fintech provides an API to Merchants to connect different payment services by
using it.
• If Payment Data and store not found then system returns to Payment Portal again.
• If Payment Data and store found, then Merchant connects Payment information using GBL Fintech System.
• GBL Fintech API shows Payment Options.
• User (Buyer / Customer or any other types payment giver (fees, utility bills, government levies or any kind of
online payment) selects payment options.
• GBL Fintech call Bank or Mobile Financial API.
• System then goes to Payment Response.
• GBL Fintech stores the information and validates the payment.
• If Failed to validate, system shows failed message to merchant.
• If failed to validate, then system shows appropriate message to buyer / Customer of any other online payment
giver.

Developed By: GBL Fintech Ltd. Page 20 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• If validation success, then system acts the payment transaction and shows success message.
• If validation success, then after showing success message to merchant, system shows appropriate message
to buyer / customer or any other online payment giver.
• And the system ends.

Developed By: GBL Fintech Ltd. Page 21 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Admin Process

Figure 8: Admin Process of GBL Fintech System


Admin Process

• Admin User go for Authentication.


• If not authenticated, then go for decline stage.

Developed By: GBL Fintech Ltd. Page 22 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• If authenticated approved, then go for Activities of:


o Security
o User Creation
o Profile Modification
o System Backup
o Merchant Approval
o Dispute Resolution
o Payment Settlement.
• If dispute resolution then go for dispute settlement.
• If dispute settlement not OK then go for Charge Back.
• If dispute settlement OK or any other payment remain go for payment settlement.
• After payment settlement go for merchant bank / account.
• And the system ends.

Developed By: GBL Fintech Ltd. Page 23 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Merchant Process

Figure 9: Merchant Manage of GBL Fintech System

Merchant Management

• Merchant request for registration.


• Merchant verification (NID, eTin etc.) taken place.
• If Decline, then to the start again for another merchant registration.

Developed By: GBL Fintech Ltd. Page 24 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• If Approved, then go to merchant activate.


• Then go to Website Integration. It is the action where payment gateway integrates to the merchant’s e-
commerce website.
• Payment Received request received by the system.
• Merchant received Dispute Notification.
• Merchant goes for Withdraw Request.
• System Settlement for the Payment or Dispute Claim.
• Then the process ends its action.

Developed By: GBL Fintech Ltd. Page 25 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Payment Process

A payment is considered as Transaction if:


• the amount is debited once,
• the capture delay is of 0 days.
An authorization request for the total amount is sent. The payment is captured by the bank as
soon as possible.

Figure 10: Payment Process of GBL Fintech System

Immediate Payment Process

• If Authorization Failed then go to Failed.


• If Authorization Accepted, then go to Merchant validation.
• If Merchant Validation then Yes then go for Authorization.
• Authorization can be Declined, then go to Failed.
• If authorization valid then go for Automatic / System Validation.
• If Automatic / System Validation Not OK, then go for Merchant Validation.
• If Automatic / System Validation OK,
o Then Payment Captured by the Bank.
o If Bank authorized the payment, then make settlement to TCSA (Trust Cum Settlement Account).

Developed By: GBL Fintech Ltd. Page 26 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Payment Dispute Process

Figure 11: Payment Dispute Process of GBL Fintech System

Payment Dispute Process

• In this process there are 03 Website which use the Payment Dispute Process: Buyer/User Portal, Merchant
Portal and Admin Portal.
• Buyer/Customer Opens GBL application to raise the Dispute.
• GBL System Validates transaction number.
• If Transaction Number not valid then go to GBL Application again.
• If Transaction Number is valid then go for upload dispute information.
• GBL Merchant (use GBL Merchant Portal) viewed in Dashboard to see the dispute. User popups and
dispute menu.
• Merchant selects dispute.

Developed By: GBL Fintech Ltd. Page 27 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

o If Dispute comes from Customer / Buyer then go for comparing the dispute and decision
making.
o If disputes found OK with decision making then the process ends.
o If dispute found not OK, then go for another dispute selection.
• If Merchant uploads the dispute, then go for Stores uploaded document.
o If Dispute uploads from Merchant then go for comparing the dispute and decision making.
o If disputes found OK with decision making then the process ends.
o If dispute found not OK, then go for another dispute selection.

Security Process
There are several ways to guarantee the security of online payments.

Guaranteeing the data interchanges integrity.

The integrity of shared information is preserved by the exchange of alphanumeric signatures between
the payment platform and the merchant website.

The payment gateway and the merchant website interact via HTML forms.

A form contains a list of specific fields (see chapter Generating a payment form) used to generate a
chain. This chain is then converted to a smaller chain through a hash function (SHA-1, HMAC-SHA-256).

The merchant will be able to choose the hash algorithm in the Merchant Back Office (see chapter
Choosing the hash algorithm).

The outcome chain is called the digest (empreinte in French) of the initial chain.

The digest must be transmitted in the signature field (see chapter Computing the signature

Modeling of security mechanisms:

Developed By: GBL Fintech Ltd. Page 28 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Figure 12: Security Mechanism of GBL Fintech System

Security Mechanism

• Security has three major user groups: Admin, Merchant and Gateway.
• Merchants Collects the form data, computes the signature and submits the form to gateway.
• Gateways receives the form data and computes the signature.
• Compares the computed signature with the signature transmitted.
• If Identifies the user authentication (signature) to the system.
• If Payment request is rejected
• If Payment request is accepted, then go for payment process.
• Then Receives the data of the result, computers the signature for the response and submits the form.
• Then Receives the data and computes the signature by Merchant.
• Compares the computed signature with the signature transmitted.
• Identical signatures by the system.
• If Not accepted, then Analyses the origin of the error.
• If Payment accepted, then Updates then database.

Developed By: GBL Fintech Ltd. Page 29 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

3 Functional Requirements – Scopes, Attributes & Use Cases

Manage Payment Service Integration


Integration of different types and organizations payment services (Bank, MFS, Internet Banking, Wallets
etc.).

GBL Fintech application integrates different types and organization payment service. Some are as
follows:

• Mobile Financial Services (MFS) like bKasah, Nogod etc.


• Banking Transaction API like Brac Bank, Sonali Bank, City Bank etc.
• Internet Banking like Astha, Upay etc.
• Wallets if any.

System integrates these and provides an API to the Merchants to integrate their payment receiving
terminal like eCommerce, Merchant Billing System etc.

GBL Fintech System’s one major task to integrates any other types of payment services in one system
and provides API to connect from one payment gateway with all other payment services.

Scope ID: GBL-Fin-PaySer


Name of Scope: Manage Payment Service Integration
Allow Administrator to Manage Payment Service Integration related information into the system.
It contains ID, Payment Service Name, API Name, API Parameters, URL with Four common fields
like Create At datetime, Updated By, Update At datetime, Delete At datetime.
Description:
1. The Administrator will be able to view the information. No other User can not
have the privilege.
2. Administrator will be able add to Payment Service Integration Information as
required.
3. Administrator will be able to delete particular Payment Service Integration
Information as required.
4. No Delete action takes place if any other function or processes use the
information.

Attribute List of Scope


Attribute Name Description Mandatory/ Remark
s

Developed By: GBL Fintech Ltd. Page 30 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Optional
Id bigint(20) NOT NULL Primary
Key
Payment_service_na varchar(100) NOT NULL unicode
me
short_name varchar(80) NOT NULL unicode
Type enum('CARD''MFS''IB''WALLE NOT NULL unicode
T')
API_Name varchar(100) NOT NULL unicode
API_Parameters varchar(100) NOT NULL unicode
Code varchar(50) NOT NULL unicode
url_ref varchar(80) DEFAULT NULL unicode
btn_text varchar(50) DEFAULT NULL unicode
btn_icon varchar(50) DEFAULT NULL unicode
emi_enable tinyint(4) DEFAULT ‘0
live_credentials longtext ‘NULL unicode
sandbox_credentials Longtext NULL unicode
Status tinyint(4) DEFAULT ‘0
updated_by int(11) DEFAULT NULL
created_at Datetime DEFAULT’
CURRENT_TIMESTAM
P
updated_at datetime DEFAULT
CURRENT_TIMESTAM
P
deleted_at datetime DEFAULT NULL

Use Cases

Add Payment Service Integration

Use Case ID: GBL-Fin-PaySer/uc/01


Use Case Name: Add Payment Service Integration
Actors: Admin
Description: This use case will allow Admin to add Payment Service Integration into the
system.
Preconditions:
• User be Admin and logged into the system (Login/uc/01).
Post conditions: Payment Service Integration t information is stored. System makes
the information as approved automatic.
Normal Flow:
1. User enters details attributes as follows:

Developed By: GBL Fintech Ltd. Page 31 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

i. ID,
ii. Payment Service Name,
iii. API Name,
iv. API Parameters,,
v. URL Reference,
vi. Text Button,
vii. Icon Button,
viii. EMI Enabled Flag,
ix. Live Credential,
x. Sand Box Credential,
xi. Status
xii. Four common field like Create At datetime, Updated By, Update At
datetime, Delete At datetime for quick audit Trail.
2. User commands to save information.
3. System checks for duplicate entry.
4. System stores the information.
Alternative Flows:
2a. In case of Administrator failed to login, system will go back to the login
screen.

View Payment Service Integration

Use Case ID: GBL-Fin-PaySer/uc/02


Use Case Name: View Payment Service Integration,
Actors: Admin.
Description: This use case will allow the Admin & User to view Payment Service
Integration information stored into the system.
Preconditions:
• User must be Admin and logged into the system (login/uc/01).
• Payment Service Integration information (GBL-Fin-MerSer/uc/01) must be
stored in the system.
Post conditions: Payment Service Integration information is viewed.
Normal Flow:

Developed By: GBL Fintech Ltd. Page 32 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

1. User selects particular Payment Service Integration information..


2. System shows respective Merchant information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Update Payment Service Integration

Use Case ID: GBL-Fin-PaySer/uc/03


Use Case Name: Update Payment Service Integration
Actors: Admin
Description: This use case will allow all Admin to update particular Failed Jobs Information
stored into the system.
Preconditions:
• User must be Admin and logged into the system (Login/uc/01-01)..
• Payment Service Integration Information (GBL-Fin-MerSer/uc/01) must be
stored in the system.
Post conditions: Payment Service Integration Merchant Information is updated.
• System shows a list with last updated information.
Normal Flow:
1. Particular Merchant Information is viewed by performing GBL-Fin-
MerSer/uc/02.
2. User changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update..
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Developed By: GBL Fintech Ltd. Page 33 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Delete Payment Service Integration

Use Case ID: GBL-Fin-PaySer/uc/04


Use Case Name: Delete Payment Service Integration Information
Actors: Admin
Description: This use case will allow Administrator to mark particular Payment Service
Integration Information (stored in the system) as deleted
Preconditions:
• User must be Website Administrator and logged into the system
(Login/uc/01-01)..
• Payment Service Integration Information (GBL-Fin-MerSer/uc/01) must be
stored in the system.
Post conditions:
• Payment Service Integration Information is marked as deleted.
• Deleted Payment Service Integration information will not be viewed.
Normal Flow:
1. Particular Payment Service Integration Information is viewed by performing
GBL-Fin- MerSer/uc/02.
2. Payment Service Integration Information commands to delete.
3. System generates alert for confirming update.
4. System updates (marks) the Payment Service Integration Information
record as deleted
5. No delete if Payment Service Integration Information record use in another
function or process.
Alternative Flows:
4a. In case particular Payment Service Integration Information use in another
function, system will inform Merchant Information that record cannot be
deleted.

Developed By: GBL Fintech Ltd. Page 34 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Merchant Information


Merchants who use payment services in their web service (eCommerce site, Payment Received sites or
tools (e.g. Merchant Billing Sysem).

System need to add merchant information. Merchant can apply through the GBL Fintech Application in
the Merchant Registration features. GBL Admin verifies the Merchant Information and Approves the
Application. Then Merchant ready to use the GBL Fintech System’s features and functions.

Scope ID: GBL-Fin-Merchant


Name of Scope: Manage Merchant Information
Allow Administrator to Manage the Gateway Information related information into the system. It
contains ID, Full Name, Short Name, Type, Charge, Title, Logo, Code, URL Reference, Text
Button, Icon Button, EMI Enabled Flag, Live Credential, Sand Box Credential, Status with one
common fields like Create At datetime, Updated By, Update At datetime, Delete At datetime.
Description:
1. The Administrator will be able to view the information. No other User can not
have the privilege.
2. Administrator will be able to Gateway Information as required.
3. Administrator will be able to delete particular Gateway Information as required.
4. No Delete action takes place if any other function or processes use the
information.

Attribute List of Scope


Attribute Name Description Mandatory/ Remark
s
Optional

Id bigint(20) NOT NULL Primary


Key
full_name varchar(100) NOT NULL unicode
short_name varchar(80) NOT NULL unicode
Type enum('CARD''MFS''IB''WALLET' NOT NULL unicode
)
Charge decimal(42) NOT NULL
Title varchar(100) NOT NULL unicode
Logo varchar(100) NOT NULL unicode
Code varchar(50) NOT NULL unicode
url_ref varchar(80) DEFAULT NULL unicode
btn_text varchar(50) DEFAULT NULL unicode
btn_icon varchar(50) DEFAULT NULL unicode
emi_enable tinyint(4) DEFAULT ‘0

Developed By: GBL Fintech Ltd. Page 35 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

live_credentials longtext ‘NULL unicode


sandbox_credential Longtext NULL unicode
s
Status tinyint(4) DEFAULT ‘0
updated_by int(11) DEFAULT NULL
created_at Datetime DEFAULT’
CURRENT_TIMESTAM
P
updated_at datetime DEFAULT
CURRENT_TIMESTAM
P
deleted_at datetime DEFAULT NULL

Use Cases

Add Merchant Information

Use Case ID: GBL-Fin- Merchant/uc/01


Use Case Name: Add Merchant Information
Actors: Admin
Description: This use case will allow Admin to add Merchant Information into the system.
Preconditions:
• User be Admin and logged into the system (Login/uc/01).
Post conditions: Merchant information is stored. System makes the information as
approved automatic.
Normal Flow:
1. User enters details attributes as follows:
i. ID,
ii. Full Name,
iii. Short Name,
iv. Type,
v. Charge,
vi. Title,
vii. Logo,
viii. Code,
ix. URL Reference,
x. Text Button,

Developed By: GBL Fintech Ltd. Page 36 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

xi. Icon Button,


xii. EMI Enabled Flag,
xiii. Live Credential,
xiv. Sand Box Credential,
xv. Status
xvi. Four common field like Create At datetime, Updated By, Update At
datetime, Delete At datetime for quick audit Trail.
2. User commands to save information.
3. System checks for duplicate entry.
4. System stores the information.
Alternative Flows:
2a. In case of Administrator failed to login, system will go back to the login
screen.

View Merchant Information

Use Case ID: GBL-Fin- Merchant/uc/02


Use Case Name: View Merchant Information
Actors: Admin.
Description: This use case will allow the Admin & User to view Merchant information
stored into the system.
Preconditions:
• User must be Admin and logged into the system (login/uc/01).
• Merchant information (GBL-Fin-MerGate/uc/01) must be stored in the
system.
Post conditions: Merchant information is viewed.
Normal Flow:
3. User selects particular Merchant information..
4. System shows respective Merchant information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Developed By: GBL Fintech Ltd. Page 37 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Update Merchant Information

Use Case ID: GBL-Fin- Merchant/uc/03


Use Case Name: Update Merchant Information
Actors: Admin
Description: This use case will allow all Admin to update particular Failed Jobs Information
stored into the system.
Preconditions:
• User must be Admin and logged into the system (Login/uc/01-01)..
• Merchant Information (GBL-Fin-Gateway/uc/01) must be stored in the
system.
Post conditions:
• Merchant Information is updated.
• System shows a list with last updated information.
Normal Flow:
1. Particular Merchant Information is viewed by performing GBL-Fin-
Merchant/uc/02.
2. User changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update..
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Delete Merchant Information

Use Case ID: GBL-Fin-MerGate/uc/04


Use Case Name: Delete Merchant Information
Actors: Admin

Developed By: GBL Fintech Ltd. Page 38 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Description: This use case will allow Administrator to mark particular Merchant Information
(stored in the system) as deleted
Preconditions:
• User must be Website Administrator and logged into the system
(Login/uc/01-01)..
• Merchant Information (GBL-Fin-Gateway/uc/01) must be stored in the
system.
Post conditions:
• Merchant Information is marked as deleted.
• Deleted Merchant information will not be viewed.
Normal Flow:
1. Particular Merchant Information is viewed by performing GBL-Fin- MerGate
/uc/02.
2. Merchant Information commands to delete.
3. System generates alert for confirming update.
4. System updates (marks) the Merchant Information record as deleted
5. No delete if Merchant Information record use in another function or
process.
Alternative Flows:
4a. In case particular Merchant Information use in another function, system
will inform Merchant Information that record cannot be deleted.

Developed By: GBL Fintech Ltd. Page 39 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Integration of Merchant's online payment service


GBL Fintech provides an API to integrate payment services to Merchant’s payment option. After
integrating the provided API, merchant’s system (eCommerce website, Merchant Billing System,
Payment option for other payment receives fees, utility bills, Form Price etc.

Scope ID: GBL-Fin-MerServ


Name of Scope: Manage Integration of Merchant's online payment service
Allow Administrator to Integration of Merchant's online payment service Information related
information into the system. It contains ID, Customer ID, Item Details with six common fields like
created user, created datetime, updated user, updated datetime, deleted user and deleted
datetime.
Description:
1. The Integration of Merchant's online payment service will be able to view the
information. No other User can not have the privilege.
2. Integration of Merchant's online payment service will be able to update
particular Customer Invoice Information as required.

Attribute List of Scope


Attribute Description Mandatory/ Remarks
Name
Optional

id int(10) NOT NULL Primary Key


customer_id int(10) NOT NULL FK (Customer Info)
item_details longtext NOT NULL
create_by int(11) NOT NULL
created_at datetime NOT NULL
updated_by int(11) DEFAULT NULL
updated_at datetime DEFAULT NULL
deleted_by int(11) DEFAULT NULL
deleted_at datetime DEFAULT NULL

Use Cases

View Integration of Merchant's online payment service Information

Use Case ID: GBL-Fin-MerServ/uc/01


Use Case Name: View Integration of Merchant's online payment service
Actors: Admin.

Developed By: GBL Fintech Ltd. Page 40 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Description: This use case will allow the Admin & User to view Integration of Merchant's
online payment service
Preconditions:
• User must be Admin and logged into the system (login/uc/01).
• Integration of Merchant's online payment service information (GBL-Fin-
CustPay/uc/01) must be stored in the system.
Post conditions: Integration of Merchant's online payment service information is
viewed.
Normal Flow:
1. User selects particular Integration of Merchant's online payment service
information.
2. System shows respective Integration of Merchant's online payment service
Information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Developed By: GBL Fintech Ltd. Page 41 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Payment Request for Merchant


GBL Fintech receives payment request for merchant from different sources (eCommerce, Merchant
Billing System (bills, fees etc.).

If system has no options to delay then payment requests taken place and payment receives merchant's
account from Global Pay Account (Trust Cum Settlement Account). The process is like as follows:

• Buyer / Customer (online buyers or online money payers) pay to the merchant for its products /
service of other payments (bill, fees etc.)/
• Global Pay API acts to the Buyer / Customer source of money (bKash, Nogod or Bank Account or Any
other online money source (e.g. Wallet) to get the money to Global Pay TCSA (Trust Cum Settlement
Account).
• If there is no delay instruction (according to the legal authority instruction, any eCommerce payment
must taken place after buyer / customer’s acceptance) then Global Pay TCSA account sends the
Merchant’s amount to the Merchant Account.
• If any delay (GBL Fintech define it as Escrow), then Global Pay TCSA holds the payment. After
approval of GBL Admin (Merchant upload Buyer’s / Customer’s acceptance and the GBL admin send
the money to Merchant Account.

Scope ID: GBL-Fin-Trans


Name of Scope: Manage Transaction Information
Allow Administrator to Manage the transactions related information into the system. It contains
ID, Transaction ID, Transaction Reference, Merchant Transaction ID, Amount, Currency,
Transaction Currency, Conversion Rate, Transaction Amount, Settlement Amount, Bank Charge,
Service Charge, Merchant Charge, Bank Ratio, Service Ratio, Merchant Ratio, Store ID,
Merchant ID, Status, Status Description, Settlement Status, Settlement Status Description, Error
Code, Error Description, Payment Option ID, Payment Channel, Payment QR Type ID, Card
Number, Card Issuer, Card Country, Card Type, Card Customer Name, Card Category, Bank
Transaction ID, Bank Transaction Message, Success URL, Failed URL, Cancel URL, IPN URL,
Risk Level, Risk Details, Customer Name, Customer Email, Customer Mobile, Customer Billing
Address (Address Line 1 & 2), Customer Billing City, Customer Billing State/Division, Customer
Billing Post Code, Customer Billing Country, Customer Shipping Address (Address Line 1 & 2),
Customer Shipping City, Customer Shipping State/Division, Customer Shipping Post Code,
Customer Shipping Country, Customer Payment Type, Customer Order Details, Merchant Invoice
Number, Additional Request Date, Payment Configuration ID, IS EMI Applicable, EMI Tenure,
EMI Installment Amount, Request IP, Request IP Details, Customer IP, Customer IP Details,
Request Time, Bank Response Time with two common fields like created user, created datetime,
updated user and updated datetime.
Description:
1. The Administrator will be able to view the information. No other User can not
have the privilege.
2. Administrator will be able to Update particular Transactions as required.

Developed By: GBL Fintech Ltd. Page 42 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

UI

Attribute List of Scope Transaction

Attribute Name Description Mandatory/ Remarks


Optional
Id bigint(20) NOT NULL Primary Key
Txnid varchar(70) NOT NULL unicode
transaction_ref varchar(70) NOT NULL unicode
merchant_txnid varchar(100) NOT NULL unicode
Amount decimal(104) NOT NULL
Currency varchar(10) NOT NULL unicode
transaction_currency varchar(10) DEFAULT NULL unicode
conversion_rate decimal(44) DEFAULT NULL
transaction_amount decimal(10,4) DEFAULT NULL

Developed By: GBL Fintech Ltd. Page 43 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

settlement_amount decimal(10,4) DEFAULT '0.0000' Format


'0.0000'
bank_charge decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
service_charge decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
merchant_charge decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
bank_ratio decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
service_ratio decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
merchant_ratio decimal(10,4) DEFAULT '0.0000' Format
'0.0000'
store_id bigint(20) NOT NULL
merchant_id bigint(20) NOT NULL
Status int(11) DEFAULT '0'
status_desc varchar(20) DEFAULT NULL unicode
settlement_status int(11) DEFAULT '0'
settlement_status_desc varchar(20) DEFAULT NULL unicode
error_code varchar(10) DEFAULT NULL unicode
error_desc varchar(20) DEFAULT NULL unicode
payment_option_id bigint(20) DEFAULT NULL
payment_channel varchar(30) DEFAULT NULL unicode
payment_gw_type_id int(11) DEFAULT NULL
card_no varchar(25) DEFAULT NULL unicode
card_issuer varchar(30) DEFAULT NULL unicode
card_country varchar(20) DEFAULT NULL unicode
card_type varchar(20) DEFAULT NULL unicode
card_Transaction_name varchar(70) DEFAULT NULL unicode
card_category varchar(20) DEFAULT NULL unicode
bank_txn_id varchar(25) DEFAULT NULL unicode
bank_txn_msg varchar(50) DEFAULT NULL unicode
success_url varchar(80) DEFAULT NULL unicode
failed_url varchar(80) DEFAULT NULL unicode
cancel_url varchar(80) DEFAULT NULL unicode
ipn_url varchar(80) DEFAULT NULL unicode
risk_level varchar(50) DEFAULT NULL unicode
risk_details varchar(50) DEFAULT NULL unicode
Transaction_name varchar(50) DEFAULT NULL unicode
Transaction_email varchar(70) DEFAULT NULL unicode
Transaction_mobile varchar(20) DEFAULT NULL unicode
Transaction_billing_address1 varchar(150) DEFAULT NULL unicode
Transaction_billing_address2 varchar(150) DEFAULT NULL unicode
Transaction_billing_city varchar(30) DEFAULT NULL unicode
Transaction_billing_state varchar(30) DEFAULT NULL unicode
Transaction_billing_postcode varchar(20) DEFAULT NULL unicode
Transaction_billing_country varchar(20) DEFAULT NULL unicode
Transaction_shipping_address1 varchar(150) DEFAULT NULL unicode

Developed By: GBL Fintech Ltd. Page 44 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Transaction_shipping_address2 varchar(150) DEFAULT NULL unicode


Transaction_shipping_city varchar(20) DEFAULT NULL unicode
Transaction_shipping_state varchar(20) DEFAULT NULL unicode
Transaction_shipping_postcode varchar(10) DEFAULT NULL unicode
Transaction_shipping_country varchar(20) DEFAULT NULL unicode
Transaction_payment_type varchar(50) DEFAULT NULL unicode
Transaction_order_details varchar(80) DEFAULT NULL unicode
merchant_invoice_no varchar(25) DEFAULT NULL unicode
additional_request_data longtext NULL unicode
payment_config_id bigint(20) NULL
is_emi_txn tinyint(4) NULL
emi_tenure varchar(255) DEFAULT NULL unicode
emi_installment_amount decimal(104) NULL
request_ip varchar(25) DEFAULT NULL unicode
request_ip_details varchar(30) DEFAULT NULL unicode
Transaction_ip varchar(25) DEFAULT NULL unicode
Transaction_ip_asn varchar(25) DEFAULT NULL unicode
Transaction_ip_country varchar(25) DEFAULT NULL unicode
Transaction_ip_details varchar(30) DEFAULT NULL unicode
request_time datetime DEFAULT
CURRENT_TIMESTAMP
bank_response_time varchar(50) DEFAULT NULL unicode
settlement_time datetime DEFAULT NULL
created_at datetime DEFAULT
CURRENT_TIMESTAMP
updated_at datetime DEFAULT
CURRENT_TIMESTAMP

Use Cases

Add Transactions

Use Case ID: GBL-Fin-Trans/uc/01


Use Case Name: Add transactions
Actors: System
Description: This use case will allow System to add Transactions into the system.
Preconditions:
• User must be System and logged into the system (Login/uc/01).
Post conditions: Transactions information is stored. System makes the information
as approved automatic.
Normal Flow:
1. User enters details attributes as follows:

Developed By: GBL Fintech Ltd. Page 45 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

i. ID,
ii. Transaction ID,
iii. Transaction Reference,
iv. Merchant Transaction ID,
v. Amount,
vi. Currency,
vii. Transaction Currency,
viii. Conversion Rate,
ix. Transaction Amount,
x. Settlement Amount,
xi. Bank Charge,
xii. Service Charge,
xiii. Merchant Charge,
xiv. Bank Ratio,
xv. Service Ratio,
xvi. Merchant Ratio,
xvii. Store ID,
xviii. Merchant ID,
xix. Status,
xx. Status Description,
xxi. Settlement Status,
xxii. Settlement Status Description,
xxiii. Error Code,
xxiv. Error Description,
xxv. Payment Option ID,
xxvi. Payment Channel,
xxvii. Payment QR Type ID,
xxviii. Card Number,
xxix. Card Issuer,
xxx. Card Country,
xxxi. Card Type,
xxxii. Card Customer Name,

Developed By: GBL Fintech Ltd. Page 46 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

xxxiii. Card Category,


xxxiv. Bank Transaction ID,
xxxv. Bank Transaction Message,
xxxvi. Success URL,
xxxvii. Failed URL,
xxxviii. Cancel URL,
xxxix. IPN URL,
xl. Risk Level,
xli. Risk Details,
xlii. Customer Name,
xliii. Customer Email,
xliv. Customer Mobile,
xlv. Customer Billing Address (Address Line 1 & 2),
xlvi. Customer Billing City,
xlvii. Customer Billing State/Division,
xlviii. Customer Billing Post Code,
xlix. Customer Billing Country,
l. Customer Shipping Address (Address Line 1 & 2),
li. Customer Shipping City,
lii. Customer Shipping State/Division,
liii. Customer Shipping Post Code,
liv. Customer Shipping Country,
lv. Customer Payment Type,
lvi. Customer Order Details,
lvii. Merchant Invoice Number,
lviii. Additional Request Date,
lix. Payment Configuration ID,
lx. Is EMI Applicable,
lxi. EMI Tenure,
lxii. EMI Installment Amount,
lxiii. Request IP,
lxiv. Request IP Details,

Developed By: GBL Fintech Ltd. Page 47 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

lxv. Customer IP,


lxvi. Customer IP Details,
lxvii. Request Time,
lxviii. Bank Response Time
lxix. Two common fields like created user, created datetime, updated
datetime for quick audit Trail.
2. User commands to save information.
3. System checks for duplicate entry.
4. System stores the information.
Alternative Flows:
2a. In case of Administrator failed to login, system will go back to the login
screen.

View Transactions

Use Case ID: GBL-Fin-Trans/uc/02


Use Case Name: View Transactions
Actors: Administrator, Merchant.
Description: This use case will allow the Administrator or Merchant & User to view
transactions information stored into the system.
Preconditions:
• User must be Administrator of Merchant and logged into the system
(login/uc/01).
• Transactions information (GBL-Fin-Trans/uc/01) must be stored in the
system.
Post conditions: Transaction information is viewed.
Normal Flow:
1. User selects particular transactions information.
2. System shows respective transactions information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Developed By: GBL Fintech Ltd. Page 48 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Dispute
If any disputes raised by the Buyer / Customer or any fees or payment giver, then GBL Admin hold the
dispute amount of the Merchant and raises the issue to the Merchant. If Merchant can show the proper
evidence by uploading those, then GBL Admin cancelled / dismissed the Dispute and notify the payment
giver (buyer / customer or any other payment giver) and releases the hold amount of Merchant. If the
dispute accept by the Merchant then GBL Admin returned the amount to the Buyer / Customer or any
other payment giver. The process as follows:

• Buyer / Customer or any other payment giver raised the Dispute.


• GBL Admin Hold the Dispute Amount from the concerned Merchant.
• GBL Admin Notifies the Merchant the Dispute.
• Merchant can Accept the Dispute, the GBL Admin Returned the Amount to Buyer / Customer or any
other payment giver account.
• If Merchant not accepts the Dispute, then Merchant upload the Acceptance Document of the Buyer /
Customer of any other payment giver.
• If GBL Admin found the document valid (Merchant non-acceptance of Dispute is Correct) then
dismissed the Dispute and system sends notification to Buyer / Customer or any other payment giver.

Scope ID: GBL-Fin-Dispute


Name of Scope: Manage Dispute Information
Allow Administrator to Manage the Dispute related information into the system. It contains Dispute
ID, Transaction ID, Invoice Number, Amount, Agreement, Email, Remarks, Status, SMS
Document, Other Info, Submit Date with two common fields like created datetime, updated
datetime.
Description:
1. The Administrator or Merchant will be able to view the information. No other
User can not have the privilege.
2. Administrator will be able to Update particular Dispute Information as required.

Developed By: GBL Fintech Ltd. Page 49 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

UI

Attribute List of Scope


Attribute Description Mandatory/ Remarks
Name
Optional

DisputeId int(11) NOT NULL Primary Key


Txnid varchar(50) NOT NULL FK (Transaction Info)
InvoiceNo varchar(50) NOT NULL
Amount decimal(64) DEFAULT NULL
Agreement varchar(100) DEFAULT NULL
Email varchar(80) DEFAULT NULL
Remarks varchar(150) DEFAULT NULL
Status tinyint(5) DEFAULT '0'
SMSDoc varchar(100) DEFAULT NULL e.g. social media screenshot
Other varchar(100) DEFAULT NULL
SubmiteDate datetime NOT NULL
CreateAt datetime DEFAULT NULL
UpdateAt datetime DEFAULT NULL

Developed By: GBL Fintech Ltd. Page 50 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Use Cases

View Dispute Information

Use Case ID: GBL-Fin-Dispute/uc/01


Use Case Name: View Dispute Information
Actors: Administrator or Merchant.
Description: This use case will allow the Administrator or Merchant & User to view
Customer Dispute information stored into the system.
Preconditions:
• User must be Administrator or Merchant and logged into the system
(login/uc/01).
• Customer Dispute information (GBL-Fin-Dispute/uc/01) must be stored in
the system.
Post conditions: Customer Dispute information is viewed.
Normal Flow:
1. User selects particular Customer Dispute information..
2. System shows respective Customer Dispute information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Update Dispute Information

Use Case ID: GBL-Fin-Dispute/uc/02


Use Case Name: Update Dispute Information
Actors: Administrator or Merchant
Description: This use case will allow all Administrator or Merchant to update particular
Dispute Information stored into the system.
Preconditions:
• User must be Administrator or Merchant and logged into the system
(Login/uc/01-01)..
• Dispute Information (GBL-Fin-Dispute/uc/01) must be stored in the system.
Post conditions:

Developed By: GBL Fintech Ltd. Page 51 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• Dispute Information is updated.


• System shows a list with last updated information.
Normal Flow:
1. Particular Dispute Information is viewed by performing GBL-Fin-
Dispute/uc/02.
2. User changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update..
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Developed By: GBL Fintech Ltd. Page 52 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage System Notification / Messages


General Payment Notification:
Event Notified status Name of the rule to configure
Instant Payment Notification URL on
Abandoned by the buyer ABANDONED
cancellation
Instant Payment Notification URL on an
Cancellation by the merchant CANCELLED
operation coming from the Back Office
AUTHORISED_TO_VALIDATE, Instant Payment Notification URL at the
Response to the authorization request
AUTHORISED, REFUSED end of payment

Escrow Payment
Event Notified status Name of the rule to configure
Response to the authorization
request for any amount (or REFUSED, WAITING_AUTHORISATION, Instant Payment Notification URL at
information request about the CB WAITING_AUTHORISATION_TO_VALIDATE the end of payment
network if the acquirer supports
it)
Response To the authorization AUTHORISED, REFUSED, Instant Payment Notification URL on
request AUTHORISED_TO_VALIDATE batch authorization

Dispute Notification:

Event Notified status Name of the rule to configure


Dispute Payment Notification URL on an
Notification to the merchant Add
operation coming from the System after
raising Dispute from buyer.
Dispute Payment Notification Result URL
Notification to buyer APPROVED
on batch authorization
Dispute Payment Notification Result URL
Notification to buyer DECLINED
on batch authorization

Common Message / Notification for any transaction except describing before:


• “Transaction Failed” message if the transaction failed.
• “Transaction Successful” message if the transaction successful.
• “Session Time Out” message if the time expired.

Developed By: GBL Fintech Ltd. Page 53 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage User Information


Scope ID: GBL-Fin-User
Name of Scope: Manage User Information
Allow Administrator to Manage the User information related information into the system. It
contains ID, Name, Email, Email Verification Datetime, Password, Remember Token, Role, Store,
Status with two common fields like created datetime and updated datetime user.
User Types

• User Management
• Administrator,
• Management,
• Accounts,
• Merchant

Description:
1. The Administrator or Merchant will be able to view the information. No other
User can not have the privilege..
2. Administrator or Merchant will be able to User information as required.
3. Administrator or Merchant will be able to delete particular User information as
required.
4. No Delete action takes place if any other function or processes use the
information.

Attribute List of Scope


Attribute Name Description Mandatory/ Remarks
Optional
id bigint(20) NOT NULL Primary Key
name varchar(100) NOT NULL unicode
email varchar(100) NOT NULL unicode
email_verified_at timestamp DEFAULT NULL
password varchar(70) NOT NULL unicode
remember_token varchar(100) DEFAULT NULL unicode
role_id int(10) DEFAULT NULL
store_id bigint(20) DEFAULT NULL
status tinyint(4) DEFAULT '1' 0=Disable
1=Enable
created_at timestamp DEFAULT NULL
updated_at timestamp DEFAULT NULL

Developed By: GBL Fintech Ltd. Page 54 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Use Cases

Add User Information

Use Case ID: GBL-Fin-User/uc/01


Use Case Name: Add User
Actors: Administrator or Merchant
Description: This use case will allow Administrator or Merchant to add User information
into the system.
Preconditions:
• User must be Administrator or Merchant and logged into the system
(Login/uc/01).
Post conditions: User information is stored. System makes the information as
approved automatic.
Normal Flow:
1. User enters details attributes as follows:
i. ID,
ii. Name,
iii. Email,
iv. Email Verification Datetime,
v. Password,
vi. Remember Token,
vii. Role,
viii. Store,
ix. Status
x. Three common fields like created user, created datetime and
deleted user for quick audit Trail.
2. User commands to save information.
3. System checks for duplicate entry.
4. System stores the information.
Alternative Flows:

Developed By: GBL Fintech Ltd. Page 55 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

2a. In case of Administrator failed to login, system will go back to the login
screen.

View User Information

Use Case ID: GBL-Fin-User/uc/02


Use Case Name: View User Information
Actors: Administrator, Merchant, any other user.
Description: This use case will allow the Administrator, Merchant or any other users &
User to view User information stored into the system.
Preconditions:
• User must be Administrator or Merchant or any other user and logged into
the system (login/uc/01).
• User information (GBL-Fin-User/uc/01) must be stored in the system.
Post conditions: User information is viewed.
Normal Flow:
1. User selects particular User information..
2. System shows respective User information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Update User Information

Use Case ID: GBL-Fin-User/uc/03


Use Case Name: Update User Information
Actors: Administrator or Merchant
Description: This use case will allow all Administrator or Merchant to update particular User
Information stored into the system.
Preconditions:
• User must be Administrator or Merchant and logged into the system
(Login/uc/01-01)..

Developed By: GBL Fintech Ltd. Page 56 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

• User Information (GBL-Fin-User/uc/01) must be stored in the system.


Post conditions:
• User Information is updated.
• System shows a list with last updated information.
Normal Flow:
1. Particular User Information is viewed by performing GBL-Fin-User/uc/02.
2. User changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update..
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Delete User Information

Use Case ID: GBL-Fin-User/uc/04


Use Case Name: Delete User Information
Actors: Administrator or Merchant
Description: This use case will allow Administrator or Merchant to mark particular User
Information (stored in the system) as deleted
Preconditions:
• User must be Website Administrator or Merchant and logged into the
system (Login/uc/01-01)..
• User Information (GBL-Fin-User/uc/01) must be stored in the system.
Post conditions:
• User Information is marked as deleted..
• Deleted User information will not be viewed.
Normal Flow:
1. Particular User Information is viewed by performing GBL-Fin-User/uc/02.
2. User Information commands to delete.

Developed By: GBL Fintech Ltd. Page 57 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

3. System generates alert for confirming update.


4. System updates (marks) the User Information record as deleted
5. No delete if User Information record use in another function or process.
Alternative Flows:
4a. In case particular User Information use in another function, system will
inform User Information that record cannot be deleted.

Developed By: GBL Fintech Ltd. Page 58 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Role Information


Scope ID: GBL-Fin-Role
Name of Scope: Manage Role Information
Allow Administrator to Manage the Role information related information into the system. It
contains ID, Name, Description with two common fields like created datetime and updated
datetime.
Description:
1. The Administrator will be able to view the information. No other Role can not
have the privilege..
2. Administrator will be able to Role information as required.
3. Administrator will be able to delete particular Role information as required.
4. No Delete action takes place if any other function or processes use the
information.

Attribute List of Scope


Attribute Name Description Mandatory/ Remarks
Optional
id int(10) NOT NULL Primary Key
name varchar(50) NOT NULL unicode
description varchar(50) NOT NULL unicode
created_at timestamp DEFAULT NULL
updated_at timestamp DEFAULT NULL
deleted_at timestamp DEFAULT NULL

Use Cases

Add Role Information

Use Case ID: GBL-Fin-Role/uc/01


Use Case Name: Add Role
Actors: Administrator
Description: This use case will allow Administrator to add Role information into the system.
Preconditions:
• User must be Administrator and logged into the system (Login/uc/01).

Developed By: GBL Fintech Ltd. Page 59 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Post conditions: Role information is stored. System makes the information as


approved automatic.
Normal Flow:
1. Role enters details attributes as follows:
i. ID,
ii. Name,
iii. Description,
iv. Three common fields like created Role, created datetime and
deleted Role for quick audit Trail.
2. Role commands to save information.
3. System checks for duplicate entry.
4. System stores the information.
Alternative Flows:
2a. In case of Administrator failed to login, system will go back to the login
screen.

View Role Information

Use Case ID: GBL-Fin-Role/uc/02


Use Case Name: View Role Information
Actors: Administrator.
Description: This use case will allow the Administrator & Role to view Role information
stored into the system.
Preconditions:
• User must be Administrator and logged into the system (login/uc/01).
• Role information (GBL-Fin-Role/uc/01) must be stored in the system.
Post conditions: Role information is viewed.
Normal Flow:
1. User selects particular Role information..
2. System shows respective Role information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Developed By: GBL Fintech Ltd. Page 60 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Update Role Information

Use Case ID: GBL-Fin-Role/uc/03


Use Case Name: Update Role Information
Actors: Administrator
Description: This use case will allow all Administrator to update particular Role Information
stored into the system.
Preconditions:
• User must be Administrator and logged into the system (Login/uc/01-01)..
• Role Information (GBL-Fin-Role/uc/01) must be stored in the system.
Post conditions:
• Role Information is updated.
• System shows a list with last updated information.
Normal Flow:
1. Particular Role Information is viewed by performing GBL-Fin-Role/uc/02.
2. Role changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update.
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Delete Role Information

Use Case ID: GBL-Fin-Role/uc/04


Use Case Name: Delete Role Information
Actors: Administrator

Developed By: GBL Fintech Ltd. Page 61 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Description: This use case will allow Administrator to mark particular Role Information
(stored in the system) as deleted
Preconditions:
• User must be Website Administrator and logged into the system
(Login/uc/01-01)..
• Role Information (GBL-Fin-Role/uc/01) must be stored in the system.
Post conditions:
• Role Information is marked as deleted..
• Deleted Role information will not be viewed.
Normal Flow:
1. Particular Role Information is viewed by performing GBL-Fin-Role/uc/02.
2. Role Information commands to delete.
3. System generates alert for confirming update.
4. System updates (marks) the Role Information record as deleted
5. No delete if Role Information record use in another function or process.
Alternative Flows:
4a. In case particular Role Information use in another function, system will
inform Role Information that record cannot be deleted.

Developed By: GBL Fintech Ltd. Page 62 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Manage Password Reset Information


Scope ID: GBL-Fin-PassReset
Name of Scope: Manage Password Reset Information
Allow Administrator, Merchant or Users to Manage the Password Reset Information related
information into the system. It contains Email, Token, Create At.
Description:
1. The Administrator or Merchant will be able to view the information. No other
User can not have the privilege.
2. User will be able to Password Reset Information as required.
3. Administrator or Merchant will be able to delete particular Password Reset
Information as required.
4. No Delete action takes place if any other function or processes use the
information.

Attribute List of Scope


Attribute Description Mandatory/ Remarks
Name
Optional

email varchar(255) NOT NULL unicode


token varchar(255) NOT NULL unicode
created_at timestamp DEFAULT
NULL

Use Cases

View Password Reset Information

Use Case ID: GBL-Fin-PassReset /uc/02


Use Case Name: View Password Reset Information
Actors: Administrator, Merchant or User.
Description: This use case will allow the Administrator, Merchant or User & User to view
Customer Password Reset information stored into the system.
Preconditions:
• User must be Administrator, Merchant or User and logged into the system
(login/uc/01).
• Customer Password Reset information (GBL-Fin-Migration /uc/01) must
be stored in the system.

Developed By: GBL Fintech Ltd. Page 63 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Post conditions: Customer Password Reset information is viewed.


Normal Flow:
1. User selects particular Customer Password Reset information..
2. System shows respective Customer Password Reset information.
Alternative Flows:
2a. In case the information not found, system will generate corresponding
message.

Update Password Reset Information

Use Case ID: GBL-Fin-PassReset /uc/03


Use Case Name: Update Password Reset Information
Actors: User
Description: This use case will allow all User to update particular Password Reset
Information stored into the system.
Preconditions:
• User must be Administrator, Merchant or Any other System User and
logged into the system (Login/uc/01-01)..
• Password Reset Information (GBL-Fin-Migration /uc/01) must be stored in
the system.
Post conditions:
• Password Reset Information is updated.
• System shows a list with last updated information.
Normal Flow:
1. Particular Password Reset Information is viewed by performing GBL-Fin-
PassReset /uc/02.
2. User changes information as necessary and commands to update..
3. System checks for duplicate information.
4. System generates alert for confirming update..
5. System updates existing information.
Alternative Flows:
3a. For each match found, system will generate an alert.

Developed By: GBL Fintech Ltd. Page 64 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.

Manage Fintech Reports


Allow Administrator to Manage the Reports of Invoice, All Transaction Report, Merchant Wise
Daily Transaction Report, Method Wise Daily Transaction Report, Monthly Transaction Report,
Monthly Withdraw Report, Monthly Merchant on Board Report, Month & Year Wise Transaction
Report
.
Description:
1. The authorize user will be able to view the information. No other User can not
have the privilege.
2. Reports of Invoice, All Transaction Report, Merchant Wise Daily Transaction
Report, Method Wise Daily Transaction Report, Monthly Transaction Report,
Monthly Withdraw Report, Monthly Merchant on Board Report, Month & Year
Wise Transaction Report information must be in the system.

Table 1: Reports
Use Case ID Report Name
GBL-Fin-Rpt/uc/01 Invoice
GBL-Fin-Rpt/uc/02 All Transaction Report
GBL-Fin-Rpt/uc/03 Merchant Wise Daily Transaction Report
GBL-Fin-Rpt/uc/04 Method Wise Daily Transaction Report

Developed By: GBL Fintech Ltd. Page 65 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Invoice Generation
Use Case ID: GBL-Fin-Rpt/uc/01
Use Case Name: Generate Invoice
Actors: Administrator, Merchant, Customer
Description: Authorized user can see the Invoice.

Preconditions: User must be logged into the system (Login/uc/01).


• Customer Information must be in the system (GBL-Fin-Cust)
• Transaction Information must be in the system (GBL-Fin-Trans)
Post conditions: Depending on the parameter(s), system will generate Invoice .

User provide following parameter(s)


o Date( Automatic system date).
o Customer Name (auto selection option).
o Merchant Selection (optional).

Normal Flow:

1. System Generates Invoice.

2. System have options to print the report in the printer OR export the report to MS Excel
form for further use.

Alternative Flows: 2A. System produces an Alert message that it can not show that
particular report.

UI Guideline
Format:

Developed By: GBL Fintech Ltd. Page 66 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Invoice

Invoice Number: System generated number datetime.

Order Number: comes from e-Commerce.

Item List with Price:

Item Name: comes from eCommerce.

Price: comes from eCommerce.

Grand Total: Summation of all items price.

Billing Address: comes form eCommerce.

Developed By: GBL Fintech Ltd. Page 67 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

All Transaction Report Generation


Use Case ID: GBL-Fin-Rpt/uc/02
Use Case Name: Generate All Transaction Report
Actors: Administrator, Merchant
Description: Authorized user can see the Merchant Wise Daily Transaction Report.

Preconditions: User must be logged into the system (Login/uc/01).


• Customer Information must be in the system (GBL-Fin-Cust)
• Merchant Information must be in the system (GBL-Fin-Mer_
• Transaction Information must be in the system (GBL-Fin-Trans).
Post conditions: Depending on the parameter(s), system will generate Invoice .

User provide following parameter(s)


o Date Range ( Automatic system date).
o Buyer / Customer Name (optional).
o Merchant Selection (optional).
o Method wise (optional)

Normal Flow:

1. System Generates Invoice.

2. System have options to print the report in the printer OR export the report to MS Excel
form for further use.

Alternative Flows: 2A. System produces an Alert message that it can not show that
particular report.

UI Guideline
Format:

Developed By: GBL Fintech Ltd. Page 68 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

All Transaction Report:


S/L: Report record auto number.

Amount: Transaction Amount.

TxnID: Transaction ID.

Transaction: Transaction Detail Description.

Order Details: Order Description.

Buyer Details: Buyer Description.

Date: Transaction Date.

Status: Transaction Status (e.g. successful).

Invoice: Invoice download option.

Developed By: GBL Fintech Ltd. Page 69 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Merchant Wise Daily Transaction Report Generation


Use Case ID: GBL-Fin-Rpt/uc/03
Use Case Name: Generate Merchant Wise Daily Transaction Report
Actors: Administrator, Merchant
Description: Authorized user can see the Merchant Wise Daily Transaction Report.

Preconditions: User must be logged into the system (Login/uc/01).


• Customer Information must be in the system (GBL-Fin-Cust)
• Merchant Information must be in the system (GBL-Fin-Mer_
• Transaction Information must be in the system (GBL-Fin-Trans).
Post conditions: Depending on the parameter(s), system will generate Invoice .

User provide following parameter(s)


o Date( Automatic system date).
o Customer Name (auto selection option).
o Merchant Selection (optional).

Normal Flow:

1. System Generates Invoice.

2. System have options to print the report in the printer OR export the report to MS Excel
form for further use.

Alternative Flows: 2A. System produces an Alert message that it can not show that
particular report.

UI Guideline
Format:

Developed By: GBL Fintech Ltd. Page 70 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Merchant wise Daily Transaction Report:


S/L: Report record auto number.

Amount: Transaction Amount.

TxnID: Transaction ID.

Transaction: Transaction Detail Description.

Order Details: Order Description.

Buyer Details: Buyer Description.

Date: Transaction Date.

Status: Transaction Status (e.g. successful).

Invoice: Invoice download option.

Developed By: GBL Fintech Ltd. Page 71 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Method Wise Daily Transaction Report Generation


Use Case ID: GBL-Fin-Rpt/uc/04
Use Case Name: Generate Method Wise Daily Transaction Report
Actors: Administrator, Merchant
Description: Authorized user can see the Method Wise Daily Transaction Report.

Preconditions: User must be logged into the system (Login/uc/01).


• Customer Information must be in the system (GBL-Fin-Cust)
• Merchant Information must be in the system (GBL-Fin-Mer_
• Transaction Information must be in the system (GBL-Fin-Trans).
Post conditions: Depending on the parameter(s), system will generate Invoice .

User provide following parameter(s)


o Date( Automatic system date).
o Customer Name (auto selection option).
o Merchant Selection (optional).

Normal Flow:

1. System Generates Invoice.

2. System have options to print the report in the printer OR export the report to MS Excel
form for further use.

Alternative Flows: 2A. System produces an Alert message that it can not show that
particular report.

UI Guideline
Format:

Developed By: GBL Fintech Ltd. Page 72 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Method wise Daily Transaction Report:


S/L: Report record auto number.

Amount: Transaction Amount.

TxnID: Transaction ID.

Transaction: Transaction Detail Description.

Order Details: Order Description.

Buyer Details: Buyer Description.

Date: Transaction Date.

Status: Transaction Status (e.g. successful).

Invoice: Invoice download option.

Developed By: GBL Fintech Ltd. Page 73 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

4. Non-Functional Requirements
A. System Requirements

Hardware
As shown in solution architecture GBL Fintech LTD Infrastructure consist of different hardware.
We will have following hardware in our DC and DR site.
• Server
• Firewall
• Router
• Network cable
• PC

Hardware Functionality:

Type of Device Role/Functionality

Controller + Management Operation


(Management Platform)

Server Software Define Network

Compute Node (Resource Pool)

Cloud Service

Storage Block Storage

Firewall Network Device (Firewall)

Network Device (TOR Switch)


Switch
Network Device (EOR Switch)

Access to cloud platform

Access to cloud platform


Workstation
Access to cloud platform

Access to cloud platform

Developed By: GBL Fintech Ltd. Page 74 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Software:
Following are the list of software items:

Name of Software Product Version or Release Role/Functionality

Windows Windows 10 Pro Operating system used in desktops/laptops

Linux Open Enterprise Euler OS release 2.0 SP3 Operating systems used in servers

SUSE Linux 12 Novell Enterprise Server 12 Operating system for e-sight platform

Backend database of Manage One cloud


MySQL 5.6 E
platform

PostgreSQL 9.2.3 Backend database for operational data

Fusion Cloud Deploy 6.3.0.2 Patch management tools

Huawei eSight V300R009C00SPC200 Log Management Solution

Fusion Guard 1.0.8 Antivirus in Firewall

IDS/IPS LIC-IPS-12-E1000E-N Intrusion prevention system

Manage One 6.3.0 Manage One O&M and operation system

Help Center 6.3.0 Documentation

Fusion Sphere OpenStack V100R006C30 Core cloud platform

Database service includes MySQL/SQL


Fusion Insight DBS V100R002C70SPC100
Server/PostgreSQL

APICombination 6.3.0 Provide API Combination capability for the UI

Provides the active-active capability and


ApiGateway 3.1.3.02
switching openstack version

HAProxy haproxy-2.1.0 Ensure high availability of cloud platform

Ngnix nginx-2.1.3 Used for reverse proxy

Developed By: GBL Fintech Ltd. Page 75 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Hardware Inventory
.

Following is the list of hardware items:

Type of Device Vendor (Make/Model) Count Role/Functionality

Controller + Management Operation


Huawei RH2288H V5 3
(Management Platform)

Server Huawei RH2288H V5 3 Software Define Network

Huawei RH2288H V5 8 Compute Node (Resource Pool)

Huawei RH2288H V5 2 Cloud Service

Storage Huawei OceanStor 5500 V5 2 Block Storage (VM Resource Pool)

Firewall Huawei (Eudemon1000E-N7E) 2 Network Device (Firewall)

Huawei CloudEngine 6851 6 Network Device (TOR Switch)


Switch
Huawei CloudEngine 6800 2 Network Device (EOR Switch)

DELL OPTIPLEX (Desktop) 4 Access to cloud platform

Lenovo Ideapad (Laptop) 4 Access to cloud platform


Workstation
HP Probook (Laptop) 2 Access to cloud platform

DELL VOSTRO (Laptop) 1 Access to cloud platform

Engineering Environment
• Development:
o Intel Core i5
o RAM 8 GB
o Windows 10
• Test Server:
o CPU 4 Core
o RAM 8 GB
o CentOS 7

Developed By: GBL Fintech Ltd. Page 76 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

B. External Interface
• SMS Integrations: Relations of SMS with the different modules of the system and external interfaces
(Security Tool) are provided in terms of data sharing, providing or exchanging by the scopes of SMS.POT
• OTP Integration: OTP integration with SMS.

C. SSL
Wildcard SSL certificate allows site administrators to secure an unlimited number of subdomains of a single
domain. It's a perfect solution for websites hosting a single domain with various subdomains, such as
mail.domain.com and products.domain.com. Wildcard is a full business-validated certificate, providing
validation of the organization behind the website, making it ideal for business sites that collect sensitive
customer data.

• Great for E-commerce, Corporate, NGO, or governmental websites


• Organization Validation
• Wildcard
• Encryption (up to 256-bit)

D. Data Specification
Application Name Type DC-DR Mode TPS (Data Transport per Second)/Sessions
GBL FinTech Application Active-Active TPS- 110+
GBL FinTech Database Active-Active
Sessions-80+

TPS:

No. of Users (Threads): 210

End to End Response Time (in seconds): 35

No. of Transactions in one iteration: 50

Pacing (in seconds): 40

Total Think Time (in seconds): 20

Transactions Per Second: 110+

Developed By: GBL Fintech Ltd. Page 77 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

E. Integration

Figure 13: Integration of GBL Fintech System

Integration:

• Payment Integration.
• Transaction Monitoring.
• eKYC

Payment Services Integration


Integration with

• Bank,
• MFS,
• Internet Banking,
• Merchant Payment System / Website (eCommerce, Bills Collection, Fees Collection etc.)
• Payment Network (VISA, Master Card, AMEX etc.)
• Wallets.

Developed By: GBL Fintech Ltd. Page 78 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Transaction Monitoring Systems


1.Automatic Data Analysis
Transaction monitoring software automatically analyses incoming and outgoing data. There’s no
need for anyone to do this manually (which, with today’s volume and speed of transactions, would
be impossible anyway). The software analyses all data across all the variables relevant to a
particular risk profile, and flags the transactions that cross a threshold, so it can do a little more
digging on those

2. Real-time Screening
The best transaction monitoring software will monitor data in real time, all the time. It does so not
just on websites, but also on mobile apps. The other option is to analyze transactions in batches,
e.g. at the end of the day, but it’s much harder to respond quickly to fraudulent transactions with
batch processing. It’d rather have real-time screening.

3. Risk Scoring
Transaction monitoring software makes risk assessments depending on the risk profile of a
customer. The software takes into account a large number of variables to create this number,
which it will then use as the threshold for what’s suspicious and what’s not. It’s easy to understand,
too, because it allows easily group customers into buckets of low-risk profiles and high-risk
profiles. When it's creating a fraud risk management strategy, such information can be invaluable.

4. AML regulations have to use transaction monitoring software to automatically monitor their
transactions, so it’s important to keep a close eye on transactions.
Transaction monitoring software helps to prevent fraud by monitoring all transactions, either in
real-time or periodically, and blocking the transactions it considers suspicious.
Transaction monitoring tools follow a common workflow: they inspect all transaction data, look for
suspicious activity in that data, and report anything suspicious to relevant stakeholders, who can
then investigate further.
First and foremost, transaction monitoring tools inspect incoming and outgoing transactions by
checking various variables per transaction. Such variables typically include a device’s fingerprints,
its IP quality, transaction velocity, source of funds, the size of transactions or withdrawals, et
cetera. Some tools can do so in real-time, while others do this periodically.

Developed By: GBL Fintech Ltd. Page 79 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

eKYC
GBL Fintech Merchant Registration Form

Type(s) of Service: VISA MasterCard AMEX Bkash


I/We am/are applying for the
e-Commerce Payment Nagad Upay Other
Gateway:

Merchant ID: Store ID:

MERCHANT INFORMATION

Merchant Name:

DBA Name:

Merchant Address:

Business Phone: Fax: Mobile:

Domain / DBA Name:


Merchant Web address:
Merchant URL:
Merchant Return URL:
Merchant Domain IP:
Merchant Business Type:
Monthly Projected No. of
Txn.:
Monthly Projected Sales
Volume:
Per Sale Trxn. Max. Limit :
Monthly Sale Trxn. Max.
Limit:

Sub-merchant’s Principal
Mobile:
Name:

Business Owners KYC:

Full Name:

Title/Designation:

Developed By: GBL Fintech Ltd. Page 80 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

Voter/National
ID/Passport No:

Contact No:

Email:

Merchant’s Declaration

I/We declare that the above information’s are true and correct and are given in support of my/our application for a Merchant facility
with United Commercial Bank Limited subject to the applicable Merchant Agreement and General Terms & Conditions for e-
Commerce Payment Gateway Services. I/We further authorize United Commercial Bank Limited to make enquiries about the
information included on my/our Merchant Application from any other source.

I/We, the undersigned, also hereby confirm that this Transaction Profile truly represents the expected transactional activities in my
account/ business of our organization. I/We also confirm to revise our Transaction Profile, if necessary, from time to time.

Name, Sign & Seal of GBL Name, Sign & Seal of the Merchant
Name:

Date: Date:

Developed By: GBL Fintech Ltd. Page 81 of 82


SRS of GBL Fintech
V0.0 SRS_GBL-Fin

5. Appendix
Glossary

Admin - Administrator

AML- Anti Money Laundering

API - Application Programming Interface

DFD - Data Flow Diagram

eKYC- Electronic Know Your Customer

EMI - Equated Monthly Instalment

Escrow - Process for Deferred Payment

Gateway - Payment Gateway to receive online payment

GBL FINTECH - Global Financial Technology for Payment Gateway

IEEE - Institute of Electrical and Electronics Engineers

IP - Internet Protocol

IPN - Instant Payment Notification

Merchant - GBL Client which use GBL Fintech in their website (e.g. eCommerce) or any other system to
receive online payment

MFS - Mobile Financial System

NGO - Non Government Organization

OTP - One Time Password

QR Code - Quick Response Code

SMS - Short Message Service

SRS - Software Requirements Specification

SMS - Short Message Service

SSL - Secure Sockets Layer

TCSA - Trust Cum Settlement Account

TPS -Data Transport per Second

UI - User Interface

URL - Uniform Resource Locator

Developed By: GBL Fintech Ltd. Page 82 of 82

You might also like