SRS For PSO
SRS For PSO
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
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
List of Figures
List of Tables
Revision History
1 Introduction
Purpose
Document Conventions
Methods of defining an SRS are described by the IEEE (Institute of Electrical and Electronics
Engineers) specification 830-1998.
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,
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:
• Part 5 (Appendices) This part includes Glossary which may be helpful to readers
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 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
• 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
Merchant panel:
Dashboard
• Available Balance
• Total Paid Amount
• Total Transaction Amount
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.
• User Authentication
• 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:
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
ERD
ER Diagram (Conceptual) of Fintech System:
Process Flow
GBL Fintech Process Flow
• 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.
• 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.
Admin Process
Merchant Process
Merchant Management
Payment 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.
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.
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
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.
GBL Fintech application integrates different types and organization payment service. Some are as
follows:
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.
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
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.
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.
Use Cases
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.
Use Cases
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.
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.
UI
Use Cases
Add Transactions
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,
View Transactions
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:
UI
Use Cases
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:
• 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.
Use Cases
2a. In case of Administrator failed to login, system will go back to the login
screen.
Use Cases
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.
Use Cases
5a. In case mandatory field defined in attribute list is missing, system will
generate corresponding alert.
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
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.
Normal Flow:
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:
Invoice
Normal Flow:
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:
Normal Flow:
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:
Normal Flow:
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:
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:
Cloud Service
Software:
Following are the list of software items:
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
Hardware Inventory
.
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
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.
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:
E. Integration
Integration:
• Payment Integration.
• Transaction Monitoring.
• eKYC
• Bank,
• MFS,
• Internet Banking,
• Merchant Payment System / Website (eCommerce, Bills Collection, Fees Collection etc.)
• Payment Network (VISA, Master Card, AMEX etc.)
• Wallets.
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.
eKYC
GBL Fintech Merchant Registration Form
MERCHANT INFORMATION
Merchant Name:
DBA Name:
Merchant Address:
Sub-merchant’s Principal
Mobile:
Name:
Full Name:
Title/Designation:
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:
5. Appendix
Glossary
Admin - Administrator
IP - Internet Protocol
Merchant - GBL Client which use GBL Fintech in their website (e.g. eCommerce) or any other system to
receive online payment
UI - User Interface