Unified Cluster & Corporate Portal

Product Documentation

Change Record

Date Author Version Comments

11.05.2020 Saqib Bashir 1.0 Initial BRD for sprint planning

Update Product Documentation including 2 additional use-cases

11.19.2020 Husnain Khatri 2.0 identified by development team during the sprint. Use-cases along with
Screens updated as per discussion with development team.

Updated with Shahsons invoice based payment use case along with
invoice breakup and consolidation.

Updated with employee creation, role creation and permission

assignment modules in unified corporate portal.

Updated with PSID creation module in unified corporate portal to handle

1.22.2021 Husnain Khatri 3.0 the use case “corporate creating pre-payment request on behalf of
distributors”

Updated with corporate portal independent invoice consolidation and

breakup modules.

Activity Log for activities performed in the system either by customer or

corporate

Excluded employee and rights management module from the unified

corporate portal.
1.28.2021 Husnain Khatri 3.1
Excluded the changes related to In-Application payment initiation
experience.

Sprint Sign-Off
MSM: <Insert Name> Development: <Insert Name> QA: <Insert Name>
<Insert Date when sign off <Insert Date when sign off was <Insert Date when sign off was
was given> given> given>
Activity

1. Introduction:
Blink Customers and Aggregators (Clusters) require transactions through APIs. Haball will extend
APIs to those customers who have provided satisfactory evidence with regards to compliance of
Data Security Standards. For customers not complying with Data Security Standards, Haball will
extend a single payment page, integrated with the customers’ existing system and/or application,
where customer would be redirected to Haball’s Payment Page to enable customers and corporates
to create PSIDs.

2. Transaction Types:
2.1. Initiator Creating PSIDs:
Customer would be redirected to Haball’s page, and would be able to create PSID
against the amount of their own choice.

Client͛s System

5.2. Haball¶s Admin

Portal updates Clients
system regarding the
1. Customer redirects
payment information 2. Customer creates a PSID, and
from Client¶s
it is displayed to both Customer
application to Haball¶s
and Haball¶s Admin Portal
Payment Page

Haball͛s Integrated
Haball͛s Corporate Portal
Payments Page

5.1. Haball¶s
4. Haball¶s Corporate Integrated 3. Customer makes
Portal is updated Payments page is the payment using
accordingly, with updated with the Blink Services
payment and Status
settlement advise
(when received)

Blink services

During the redirection, customer ID and additional parameters will be passed on to Haball by
Client, through which Haball will be able to show all the payment history of that particular
customer in the Payment Summary Grid.

Corporate existing system will only be sent PSID information once payment has been initiated
and/or settled. However, once the corporate ID has been generated, the PSID will be reflected
on Haball’s corporate portal.
 Section 3.1, 3.2 and 3.3 detail the scenarios for this particular use case.

2.2. Corporate Creating PSIDs:

In this scenario, Client’s system will pass on specific parameters via APIs which will
enable Haball’s system to generate PS-IDs based on the request.

Corporate System
5.2. Haball¶s
Corporate Portal
updates corporates
system regarding the 2. Customer is shown Payment
1. Customer redirects
payment and View screen with details of
from Corporate¶s
settlement / recon payments forwarded by Corp.
application to Haball¶s
Same is forwarded to Haball¶s
Payment Page
Corp Portal

Haball͛s Integrated
Haball͛s Corporate Portal Payments Page (Payment
Vew Screen)

5.1. Haball¶s
4. Haball¶s 3. Customer makes
Integrated
Corporate Portal is the payment using
Payments page is
updated Blink Services
updated with the
accordingly, with
Status
payment and
settlement advise
(when received)

Blink services

Additional parameters would be included in the APIs that would determine whether customer
would be redirect to Haball’s solution or not. In case customer has to be redirect to Haball’s
solution, they would be redirected to the Payment View page.

Only Client will be able to cancel PSIDs through APIs or Haball’s Corporate Portal..

Since payment information has been passed on by Client, they would be able to view the status
of every payment in their system through API integration as-well. Client can also view status of
every payment from Haball’s Corporate Portal.

Client may pass on Reference parameters, for example Order ID, Invoice ID etc. which is not
mandatory for creating PSID, but can facilitate reconciliation purposes.

Section 3.4 and 3.5 detail the scenarios for this particular use case.
3. Payment Scenarios:
There will be 7 primary payment scenarios:

3.1. Scenario 1: Initiator Creating PSIDs (Open Use Case):

3.1.1. Scenario 1 - Normal Flow:
 User will be redirected to Haball’s Payment Page
 User would be shown Company Name (which would include the name of the company user has
redirected from) and an Input Field.
 User would be required to enter the amount and click on the “Create” button to generate a PS-
ID against the amount and company.

3.1.2. Scenario 1 - Post Condition:

 Once user clicks on “Create” button, System will create a PS-ID with “Unpaid” status and notify
the user with success message.
 System will display the record in the payment summary section.
3.1.3. Scenario 1 – Alternative Flows

 If anywhere during the flow, user decides to navigate away from the payment creation screen
and has entered the amount in the amount field, a discard changes dialog popup would be
displayed to the user.
o If user clicks on Yes, the request is not saved and the
user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and
user will remain on the payment creation screen.
o If user clicks anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the payment creation
screen.

 If the user navigates away from the payment screen without entering the amount, user would
be allowed to navigate away from the screen without showing any popup message.
 Create button would remain disabled until user enters an amount above PKR 500.
 System will notify the user, if there is any error occurred
due to network failure or any other reasons during the
payment creation process. Refer the screenshot attached
below.

3.2. Scenario 2: Initiator Creating PSIDs (Fixed Un-editable Amount Use case):
3.2.1. Scenario 2 - Normal Flow:
 User will be redirected to Haball’s Integrated Payment Screen.
 Both Company dropdown and Amount field will be prepopulated. Amount field will remain un-
editable.
 User will be required to click on the Create button to generate PS-ID.

3.2.2. Scenario 2 - Post Condition:

 Once user clicks on “Create” button, system will generate PS-ID with unpaid status and notify
the customer with success message.
 System will display the record in the payment summary section.
 Once PS-ID has been successfully created:
o system would disable the Create button (in the Payment section) so that user can’t
create another PS-ID.
o company dropdown menu will reflect the Company Name (from where user has been
redirected from) and Amount field will become empty.
3.2.3. Scenario 2 - Alternative Flows:
 If the predetermined locked amount is less than 500, API will return an error and user will not be
redirected to Haball’s Integrated Payment Page.
 If anywhere during the flow, user decides to navigate away from the payment creation screen, a
discard changes dialog popup would be displayed to the user.
o If user clicks on Yes, the request will not be saved and
the user will be redirected accordingly.
o If user clicks on No, popup confirmation dialog will
close and user will remain on the payment creation
screen.
o If user clicks on anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the payment creation screen.
 System will notify the user, if there is any error occurred due to
network failure or any other reasons during the payment
creation process.

3.3. Scenario 3: Initiator Creating PSIDs (Fixed Editable Amount Use case):
3.3.1. Scenario 3 - Normal Flow:
 User will be redirected to Haball’s Integrated Payment Screen.
 Both Company dropdown and Amount field will be prepopulated. Amount field will remain
editable.
 User will be allowed to change the amount below the prepopulated amount.
 User will be required to click on the Create button to generate PS-ID.

3.3.2. Scenario 3 - Post Condition:

Same as Section 3.2.22.1.3.2. Scenario 2 – Post Condition

3.3.3. Scenario 3 - Alternative Flows:

Same as Section 3.2.3.2.1.3.3. Scenario 2 – Alternative Condition

3.4. Scenario 4 - Corporate Creating PSID Use Case:

3.4.1. Scenario 4 - Normal Flow:
 User will click on the “Pay” button on Client’s system
 Client system will call Haball’s PSID creation API and pass on the required parameters

3.4.2. Scenario 4 - Post Condition:

 System will create PSID with “Unpaid” Status and respond to Client’s System accordingly.
 Depending on the parameter passed on by Client system, User may be redirected to Payment
View screen.
 Please refer to Section 3.813 – Payment View Use Case for details related to data and options
shown to user in Payment View Screen.
3.4.3. Scenario 4 - Alternative Flows:
 User can click on “Back to Client” button in the Action Panel, and the payment view screen will
be closed. Session will be expired user will be redirected back to the Client’s application.
 Precondition: Only in case of User Redirection
o For Scenarios where PS-ID is already created, and Client’s System call’s “PS-ID Creation
API” with the same parameters, including
 PSID
 Reference ID
 Amount
o Haball’s system will first check whether PS-ID and Reference Match and whether
Amount is changed:
 If Amount is changed, and status of PS-ID is not “Unpaid”, System will return an
error
 If Amount is changed, and status of PS-ID is “Unpaid”, User will be redirected to
the specific Payment View Screen with updated Amount
 If Amount is not changed, User will be redirected to the Payment View Screen
and will be displayed fields according to the status of the PS-ID.
 If user clicks on “Payment History” button, user will be redirected to the payment summary
screen.
 System will notify the user, if there is any error occurred due to
network failure or any other reasons during the process.

3.5. Scenario 5 - Corporate PSID Update for Non-

Redirection Use Case:
3.5.1. Scenario 5 - Normal Flow:
 Client system can call PS-ID Update API pass on:
o PS-ID (if created previously and returned to Client),
o Reference No (against which PS-ID is already created)
o Amount
o Status – Only in the case of cancellation, Client would be required to pass on the status as
cancelled.
3.5.2. Scenario 5 - Post Condition:
 If Reference No and PS-ID passed on by Client System do not match, System will return an Error
 If Amount is changed, System will check whether Status of PS-ID is Unpaid. If true, Haball’s
system will update PS-ID amount and respond to Client System accordingly. Otherwise, Haball’s
system will return an error.
 If Status is sent by Client as Cancelled, System will first check whether Status of PS-ID is Unpaid.
If true, Haball’s system will change the status of the PS-ID to “Cancelled” and respond to Client
System accordingly. Otherwise, Haball’s system will return an error.
3.5.3. Scenario 5 - Alternative Condition:
 If PS-ID Amount is below PKR 500, Haball system will return an error.
 API will return error in-case of timeout or any other processing error.
3.6. Scenario 6 – Invoice Redirection Use Case:
3.6.1. Invoice Redirection – Normal Case:
 User clicks on the invoice payment option display in the client system.
3.6.2. Invoice Redirection – Post Condition:
 User will be redirected to Haball’s Payment Page.
 User would be shown payment Grid (which would include the Payment ID, Reference, Created
Date, Amount and Status, along with options to break and consolidate the invoice. Refer the
screenshot attached below.
o Only active payment records will be displayed in the payment summary grid.

3.6.3. Invoice Redirection – Alternative Condition:

 API will return error in-case of timeout or any other processing error.
3.7. Scenario 7 – Invoice Breakup Use Case:
3.7.1. Invoice Breakup – Normal Case:
 User can click on the “Action Dropdown Menu” against a Payment Record and click on “Break”
from the available options to break the PSID into multiple payments.
 Break Payment popup will be shown. Refer the screenshot attached below.
o PSID and Invoice Amount would also be displayed in the header.

 User would be required to enter the amount and click on the “Confirm” icon to break the
invoice with the entered amount.
 System will return an error if:
o Entered amount is equal or greater than the original PSID amount.
o Remaining amount is less than PKR 500. However, system will not return an error if remaining
amount is 0.
o Once user clicks on the tick icon, entered amount and remaining amount fields would be
displayed on screen. PSID will not be created until the user clicks on the “Confirm”
button below. Refer the screenshot attached below.
 User would be required to click on “Confirm” button to complete the payment breakup process
successfully.
3.7.2. Invoice Breakup – Pre Condition:
 Breakup option is enabled for the corporate customer, else breakup option will not be shown to
the user
 User can “Break” all active payment records with the unpaid status. Consolidated payments
cannot be broken.

3.7.3. Invoice Breakup – Post Condition:

 Once user clicks on “Confirm” button, System will create PS-IDs with “Unpaid” status against
each specified breakup field.
 System will deactivate the primary PSID
 Primary payment record will be removed from the payment summary grid.
 System will notify the user with success message. Refer the screenshot attached below.
 Newly created PSIDs will be displayed on the payment summary grid with Payment Reference
“Broken”.
3.7.4. Invoice Breakup – Alternative Condition:
 If anywhere during the flow, user decides to navigate away from the breakup payment popup
screen and has entered the amount in the amount field or edited any of the fields while editing
the record, a discard changes dialog popup would be displayed to the user.
o If user clicks on Yes, the request is not saved and the
user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and
user will remain on the break payment popup
screen.
o If user clicks anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the break payment popup screen.
 User can remove the broken records that he has created by clicking on the delete icon. System
will prompt a confirmation popup.
o If user selects “Yes”
 If only a single payment record exists, which is being deleted, pop-up screen
would return to it’s original state, please refer to Screen in section 3.7.1XX
 If there are multiple payment records, system would delete the selected record
and add the deleted amount to the remaining amount filed.
o If user says “No” then system will close the confirmation alert popup window with no
changes made.
 User can update a created record by clicking on the edit icon.
o Once user clicks on the editable icon, the field would become editable and user would
be able to change the amount. Same rules would apply for entering amount as
mentioned in the normal case.
o Once user changes the amount and clicks on tick icon., system will update the record
with the updated amount and adjust the remaining amount accordingly.
 User can further breakdown the remaining amount of the invoice until the amount has reached
the minimum threshold of PKR 500 or PKR 0, as the case maybe.
o To further break the amount, user can click on the edit icon next to the remaining
amount field.
o Once user clicks on the editable icon, the field would become editable and user would
be able to change the amount.
o System will return an error if:
 Amount entered cannot be greater than the original remaining amount
 Remaining amount is less than PKR 500. However, system will not return an
error if remaining amount is 0.
o User can click on the “tick” icon to create another record with the entered amount.
After that, the remaining amount will be adjusted accordingly.
 Confirm button would remain disable, until user has not broken any payment.
o Confirm button would also be disabled if the user is editing any record in the pop up
window.
 System will notify the user, if there is any error due to
network failure or any other reasons during the payment
creation process. Refer the screenshot.

3.8. Scenario 8 – Invoice Breakup Update Use

Case:
3.8.1. Invoice Breakup Update – Normal Case:
 User can click on the “Action Dropdown Menu” against a Payment Record with Payment
Reference “Broken” and click on “Break” option from the available options to update the
payment breakup structure.
 Break Payment popup will be shown, where user will be displayed the list of already created
broken up PSIDs against the primary invoice. Refer the screenshot attached below.

 User would be required to click on the edit icon appears next to the amount field against each
breakup record.
 Payment records with status “Paid” would appear disabled with no editing options being
displayed next to the record
 User would be able to add, edit, update and delete records as mentioned in section 3.7
 User can edit existing broken PSID by changing the amount. In that case, the PSID will be
updated with the new amount.
3.8.2. Invoice Breakup Update – Pre Condition:
 Payment records must be with “Unpaid” status and reference with “Broken”.

3.8.3. Invoice Breakup Update – Post Condition:

 Once user clicks on “Confirm” button, System will update or create new PS-IDs, as the case
maybe, with “Unpaid” status against the updated record.
 System will notify the user with success message.
 PS-ID records with updated status will be displayed in the Payment Summary section.
3.8.4. Invoice Breakup – Alternative Condition:
 If anywhere during the flow, user decides to navigate away from the breakup payment popup
screen and has updated or deleted the records, a discard changes dialog popup would be
displayed to the user.
o If user clicks on Yes, the request is not saved and the
user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and
user will remain on the break payment popup
screen.
o If user clicks anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the break payment popup screen.
 User will be able to delete already created PSID. Once confirmed, PSID would be deactivated
and removed from the Payments Summary
 Any time before updating or deleting the record, the user can revert the payment breakup.
o User require to click on the “Revert All” button.
o A dialog box would appear, asking confirmation from the user.
 If user selects “Yes” then system will deactivate all broken up PSIDs and activate
the primary PSID.
 Deactivated broken PSIDs will be removed from the Payments Summary
Grid and display are the original PSID
 If user says “No” then system will close the confirmation box.
 Revert button would remain disabled, if any of the corresponding broken PSID is Paid.
 System will notify the user, if there is any error occurred
due to network failure or any other reasons during the
payment creation process. Refer the screenshot attached
below.
3.9. Scenario 9 – Invoice Consolidation Use case
3.9.1. Invoice Consolidation – Normal Flow:
 User can click on the “Consolidation” button to consolidate multiple payment records into the
single PSID.
 Consolidate Payment popup will be shown, where user will be displayed the following Gird:

 User would be required to select at least two payment records (by clicking on the checkbox
appearing before the PSID) displayed in the grid and click on the “Confirm” button to
consolidate the PSIDs.
 Once user clicks on “Confirm” button, popup notification would be displayed asking for
confirming regarding consolidation of payment records. Refer the screenshot attached below.

 User would be required to click on “Yes” to complete the invoice consolidation process.
3.9.2. Invoice Consolidation – Pre Conditions:
4. Consolidation option is enabled for the corporate customer, else consolidation option will not
be shown to the user
 User can “consolidate” all the active payment displayed in the payment summary grid. PSIDs
with Payment Reference “Broken” or “Consolidated” cannot be consolidated.

4.1.1. Invoice Consolidation Post Condition:

 Once user clicks on “Yes” button, System will create a PS-ID with “Unpaid” status for the
selected payment records.
 System will deactivate the primary PSIDs.
 System will notify the user with success message.
 Consolidated PSID with updated status will be displayed in the Payment Summary Grid while
original deactivated PSIDs will be removed.
4.1.2. Invoice Consolidation Alternative Condition:
 If anywhere during the flow, user decides to navigate away from the consolidate payment
popup screen and has selected the records in the grid, a discard changes dialog popup would be
displayed to the user.
o If user clicks on Yes, the request is not saved and the
user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and
user will remain on the consolidate payment popup
screen.
o If user clicks anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the consolidate payment popup screen.
 If the user navigates away from the consolidate payment popup screen without selecting the
record, user would be allowed to navigate away from the screen without showing any popup
message.
 At the confirmation popup screen, the user can select “No”, and the dialog box will close. User
will remain on the consolidated payment popup screen.
 Consolidate button would be disabled until user has selected at least two payment records in
the grid.
 System will notify the user, if there is any error occurred
due to network failure or any other reasons during the
payment creation process. Refer the screenshot attached
below.
3.10. Scenario 10 – Invoice Consolidation Update Use case
3.10.1. Invoice Consolidation Update – Normal Flow:
 User can click on the “Action Dropdown Menu” against a Payment Record with Payment
Reference “Consolidated” and click on “Update” from the available options to update the
consolidated payment record.
 Consolidate payment popup will be appear, showing the consolidated PSIDs in grid format.
 User will be able to unselect PSIDs from the grid and updated the consolidated PSID.
 Revert button would appear, that would deactivate the consolidated PSID and activate all
original PSIDs
 User can click on the confirm button to complete the payment consolidation update process
successfully.
3.10.2. Invoice Consolidation Update – Pre Conditions:
 Payment records must be with “Unpaid” status and reference should be “Consolidated”.
3.10.3. Invoice Consolidation Update – Post Condition:
 Once user clicks on “Confirm” button, System will update the consolidated payment record with
the selected corresponding primary payments.
o PSID would remain the same for that consolidated payment record.
 System will activate all the payment records, which were un-selected at the time of updating
consolidated payment.
 System will notify the user with success message.
 All activated primary payment records (unselected) with updated status will be displayed in the
Payment Summary section.
3.10.4. Invoice Consolidation Alternative Condition:
 If anywhere during the flow, user decides to navigate away from the consolidate payment
popup screen and has selected or un-selected the records in the grid, a discard changes dialog
popup would be displayed to the user.
o If user clicks on Yes, the request is not saved and the
user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and
user will remain on the consolidate payment popup
screen.
o If user clicks anywhere else on the screen, except
the popup window, popup confirmation dialog will
close and user will remain on the consolidate payment popup screen.
 If the user navigates away from the consolidate payment popup screen without updating the
records, user would be allowed to navigate away from the screen without showing any popup
message.
 At the confirmation pop-up window, user can click on “No”, and the dialog will close. User will
remain on the consolidate payment popup screen.
 Confirm button would remain disabled if no changes are made.
 Any time before updating the record, the user can revert the consolidated payment.
 o User can click on the “Revert” button.
o S popup confirmation dialog would be displayed, asking for confirmation.
 If user selects “Yes” then system will close the confirmation alert popup window
and revert the consolidated payment.
 System will activate all the primary payment records, displayed it in the
payment summary grid and deactivate the consolidated payment
record.
 System will remove consolidated payment record from the payment
summary grid.
 If user says “No” then system will close the confirmation alert popup window.
 System will notify the user, if there is any error occurred
due to network failure or any other reasons during the
payment creation process. Refer the screenshot attached
below.
3.11. Payment Initiation Use Case:
3.11.1. Payment Initiation - Normal Flow:
 Payment can be initiated through:
o Action Drop Down menu in Main Screen grid
o Payment View Screen (Please refer to section 3.8)
 U s e r c a n c l i c k
PS-ID

3.11.2. Payment Initiation - Post Conditions:

 User would be redirected according to the selected payment option.
 Once payment has been successfully processed, System will
change the status of PSID to “Paid” and notify the user with
success message.
 User will be redirected to the Payment view screen (Paid
Version), where additional transactional reference details
would be displayed. Please refer to section 3.138.2 for details
regarding.

3.11.3. Payment Initiation - Alternative Flow:

 If System receives an error, PS-ID status will not be updated. Popup error notification would be
displayed to user.
 User would remain on Unpaid Payment View Screen.

3.12. Cancel payment Use Case:

3.12.1. Cancel Payment - Normal Flow:
 Precondition: User can only Cancel a PS-ID for Scenario 1, 2 and 3.
 User can open the “Action Dropdown Menu” and select “cancel” option to deactivate the
PS-ID generated.
 Popup notification would be displayed asking user for confirming regarding cancellation of
payment.
 User would be required to click on “Yes” to complete the payment cancellation process.

3.12.2. Cancel Payment - Post Condition:

 Once user has confirmed cancellation, system will update the PS-ID status as “Cancelled”.
 System would display on-screen success message.
 PS-ID record with updated status will be displayed in the Payment Summary section.
 User can view Cancelled Payment from “Action Dropdown Menu”.
3.12.3. Cancel Payment - Alternative Flows:
 At any time before clicking cancel, the user can click no button. The payment request will
not be cancelled and user will remain on the payment screen.
 System will notify the user, if there is any error occurred due to network failure or any other
reasons during the process.

3.13. Payment View Use Case:

3.13.1. Payment View - Normal Flow:
 User can click on the “Action Dropdown Menu” against a Payment Record and click on
“View” from the available options.
3.13.2. Payment View - Post Condition:
 User would be redirected to the payment view screen of that specific payment record.
 Based on the status of the PS-ID, the payment view page would be displayed
o If PS-ID status is unpaid, both Payment Details and Payment Option sections would be
displayed. For field description, please refer to Section 3.150.4.
o If PS-ID status is cancelled or in-process then only Payment Detail would be displayed.
For field description, please refer to section 3.15.4

o If payment status is paid , in process or cancelled, Payment Details section would only
be displayed. For field description, please refer to Section 3.150.4.
3.14. Payment Edit Use Case:
3.14.1. Payment Edit - Normal Flow:
 Precondition: User can only Edit a PS-ID if the status is Unpaid.
 Precondition: User can only Edit a PS-ID in Scenario 1 and 3 only.
 User can click on the “Action Dropdown
Menu” against a Payment Record and
click on “Edit” from the available options.
 The Edit pop-up window will appear
where User can change the amount of
PS-ID only
 Once user has changed the amount, they
can click on the Update Button.

3.14.2. Payment Edit - Post Condition:

 Once Update button is clicked, System will update amount against PS-ID and show user
success message.

3.14.3. Payment Edit - Alternative Flows:

 If amount is not changed, Update button would remain disabled.
 If amount is not updated in System, due to any reason whatsoever, user will be shown an
error message.

3.15. Payment Scenarios – Interface Details:

3.15.1. Main Page - Field Display
Fields in the payment screen would be displayed as per the following:
 Fields Type Mandatory Detail Description
Alpha Numeric
Company Y Un-editable.
Field
9-digit value numeric only input. 18,2 decimal value.
Amount Numeric Field y
Editable or Un-editable based on Scenario 1, 2 and 3.

This section would only be displayed for Scenario 1, 2 and 3.

3.15.2. Main Page - Grid Display:

Column headers, column sequence and data pattern will be according to the table below:

Payment ID Reference No Amount Created Date Status Action

Reference No Payment creation Unpaid,
13 to 20 – digit passed on by Client date will be Paid, Partially Paid, In Dropdown
unique ID PKR 0.00
during PS-ID displayed in DD- Process and Menu
creation. MM-YY format Cancelled
Pagination would only be displayed if records are greater than 10.

Reference No column would only be displayed in-case of Scenario 4,5,6,7 and 9.

Reference No Column would displayed the “State” of the invoice (which would include Break and
Consolidated) instead of the “Reference ID” in case of Scenario 7 and 9.

3.15.3. Main Page - Action Dropdown Menu:

Action dropdown would be following values as an option:

Options Detail Description

This option will always be displayed. Clicking on it would redirect user the payment view screen
View
for that particular PS-ID.
Option would be displayed in Scenario 1 and 3. Only available is status of PS-ID is Unpaid. This
Edit option will enable user to edit PS-ID amount. This option would only be displayed for PS-IDs
created in Scenario 1 – Initiator Creating PS-ID (Open Use Case)
Option would be displayed in Scenario 1, 2 and 3. Only available is status of PS-ID is Unpaid. This
Cancel
option will enable user to cancel the PS-ID.
Option would be displayed in Scenario 6 and 7. Only available if status of PSID is Unpaid. This
Break
option will enable user to break the PSID.
Option would be displayed in Scenario 8 and 10. Only available is status of PSID is Unpaid. This
Edit
option will enable user to update split and consolidated payments.
Only available is status of PS-ID is Unpaid. This option will open payment banking channel popup
PSID
screen.
Payment Only available is status of PS-ID is Unpaid. All available banks enabled in Live Environment would
Options be displayed, for example Meezan Bank Ltd.

3.15.4. Payment View - Field Display

Fields in the payment screen would be displayed as per the following:

Fields Type Detail Description

Payment ID Read only Payment ID generated at the time of request creation would be displayed
 here in read only mode
Company Read only Name of the Beneficiary Company the PSID is generated against.
Name
Created Read only Date when payment request is created would be displayed here in read
Date only mode
Transaction Read only Date when payment request is paid would be displayed here in read only
Date mode. Only to be displayed in case status is Paid
Payment Read only Name of the Bank from where transaction initiated would be displayed
Channel here. Only to be displayed in case status is Paid
Transaction Read only Number generated from the bank against the initiated transaction would
Auth ID be displayed here. Only to be displayed in case status is Paid
Status Read only Current status of the payment request would be displayed here in read
only mode
Amount Read only Entered amount at the time of payment creation would be displayed here
in read only mode
Transaction Read only Disclaimer would be displayed that “Transaction charges will be applied
Charges on top of the amount”. Only to displayed in case status is Unpaid.
Disclaimer
Transaction Read only Transaction charges applied to the entered amount would be displayed
Charges here in read only mode. Only to be displayed in case status is Paid
Total Read Only Total Amount including transaction charges would be displayed in here.
Amount Only to be displayed in case status is Paid
Reference Read Only Reference No provided in the time of PS-ID creation by Client system. Only
No to be displayed if reference no is passed as a parameter by Client. Only to
be displayed in case of Scenario 4, 5, 7 and 9.

Reference would be clickable in case of Scenario 7 and 9. Clicking on it would display payment detail
grid (which would include the payment ID, Payment Reference No, Created Date and Amount). This
section would be displayed only in those payments, which have been inactive against the breakup or
consolidated PSID. Refer the screenshot attached below.

3.15.5. Payment Breakup - Field Display

Fields in the payment breakup screen would be displayed as per the following:

Fields Type Mandatory Detail Description

Amount Numeric Field y 9-digit value numeric only input. 18,2 decimal
 value. This field will perform the following action
in Scenario no 7 and 8:
1. It would enable user to input the amount
to break the payment with.
2. It would enable user to view the amount
of the broken payment record.
3. It would enable the user to update the
amount of broken payment record.
9-digit value numeric only input. 18,2 decimal
value. This field will perform the following action
in Scenario no 7 and 8:
1. It would enable user to input the amount
Remaining Amount Numeric Field Y to break the payment into another
segment.
2. It would enable user to view the remaining
amount of the invoice, which has been
calculated after breaking the payment.

3.15.6. Payment Consolidation - Grid Display:

Column headers, column sequence and data pattern will be according to the table below:

Payment ID Reference No Amount Created Date

13 to 20 – digit Reference No passed on by Payment creation date will be
PKR 0.00
unique ID Client during PS-ID creation. displayed in DD-MM-YY format
Pagination would only be displayed if records are greater than 10.
4. Unified Corporate Portal
4.1. Background and Introduction:
Current NHS Corporate Portal Build will be utilized for making a unified corporate portal

User Management will be utilized to create profiles of multiple corporates and/or clusters that
will be given access to the Corporate Portal.

Admin user can be created from the backend by Haball internal team, and accordingly provide
access to each and every corporate and/or cluster.

Options available on the Corporate Portal:

Dashboard Section 4.2

Transaction Management
Sub Menu: Advance Payment
Sub Menu: Invoice Payment
Settlement Report
Will act as the main menu only when consolidation/breakup
option is enabled. In that case, clicking on it will open sub
menu.
Only available when consolidation/breakup option is enabled
Only available when consolidation/breakup option is enabled
Section 4.5

4.2. Corporate Portal Dashboard

Corporate Portal Dashboard will show the following data:

Recent Transactions:
Recent Transactions Grid will display both advance and invoice payment records.

Haball Customer
Created Date Amount Status
ID Name
Date when transaction was
created (for Prepaid ID,
Payment would consist following
13 – 20- Transaction created date will be when
statuses (Paid, Unpaid, In
digit Initiator’s Name Prepayment was created). For
PKR 0.00 Process, Partially Paid, Cancelled
Unique passed on by Fixed and invoice Payment,
(only in the case of Fixed
PSID Client System transaction would be when
Payment)
payment was forwarded to
Haball by Corporate.

Clicking on Haball ID will open up the respective transaction view screen.

4.3. Transaction Management

Corporate portal would show Advance and Invoice Payments separately under the Transaction
Management section.
4.3.1. Advance Payment:
This section would display the payment grid, which shows the list of prepayments which have
been either created by the customer or by the corporate themselves.

4.3.1.1. Advance Payment Grid Display:

Haball ID Customer Name Created Date Amount Status Action
13 – 20 digit Transaction Date when PKR 0.00 Payment would consist Following options
Unique PSID Initiator’s Name transaction was following statuses Paid, will be displayed in
would be displayed. created (for Prepaid Unpaid, In Process, dropdown menu:
ID, created date will Cancelled, Partially View, Edit and Cancel
be when Paid, Cancelled (only in (only available in the
Prepayment was the case of Corporate case of Corporate
created. Creating PSID) Creating PSID
4.3.1.2. Advance Payment Buttons:
Section Logic
Filter Results Button will only be displayed if 1 record (at the minimum) is available in the grid.
Clicking on this button would enable the search row below the Grid Heading – allowing
customer to search filters according to each column in the grid
Export Button will only be displayed if 1 record (at the minimum) is available in the grid. Data
which is available will be exported in CSV format. If user has not filtered data then all
data should be exported – otherwise only the filtered date being shown in the grid will
be exported.
Create Button would only be displayed if option is enabled for the Corporate. This button
would remain enabled. Clicking on it would redirect user to Create Payment popup
screen, where user would be able to create payment on behalf of customer.
4.3.1.3. Advance Payment – Corporate Creating PSID Use Case:
4.3.1.3.1. Corporate Creating PSID – Normal Flow:
 User shall login into the portal with the valid user credentials.
 User would be required to move to the Advance Payment screen under the Transaction
Management section, where Create button would be displayed along with the payment records
in the grid.
 User clicks on Create button and the Create Payment popup screen will open. User would be
required to fill in the following input fields:
 Customer Name
 Customer Code
 Amount
 All above mentioned fields are mandatory.
 User would be required to click on the Create button to generate a PS-ID against the amount
and customer.
4.3.1.3.2. Corporate Creating PSID – Post Condition:
 Once user clicks on “Create” button, System will create a PS-ID with “Unpaid” status and notify
the user with success message.
 System will display the record in the payment summary section on both customer page and
unified corporate portal.
4.3.1.3.3. Corporate Creating PSID – Alternative Flows
 If anywhere during the flow, user decides to navigate away from the payment creation popup
screen and has entered the amount and customer code, a discard changes dialog popup would
be displayed to the user.
o If user clicks on Yes, the request is not saved and the user will be redirected accordingly.
o If user clicks on No, popup dialog box will close and user will remain on the payment
creation popup screen.
o If user clicks anywhere else on the screen, except the popup window, popup
confirmation dialog will close and user will remain on the payment creation popup
screen.
 If the user navigates away from the payment popup screen without entering the amount, user
would be allowed to navigate away from the screen without showing any popup message.
 Create button would remain disabled until user enters an amount above PKR 500.
 System will notify the user, if there is any error occurred due to network failure or any other
reasons during the payment creation process.
4.3.2. Invoice Payment:
This section would display the payment grid, which shows the list of invoices which have been
created in Haball’s system against data sent through client’s system via Direct Payment Creation
API.

4.3.2.1. Invoice Payment Grid Display:

Haball ID Customer Name Created Date Amount Status Action
13 – 20 digit Transaction Date when invoice PKR 0.00 Payment would Following options will
Unique PSID Initiator’s Name was created in the consist following be displayed in
passed on by Haball system. statuses (Paid, dropdown menu:
Corporate’s System Unpaid, In Process, View,
Cancelled, Partially Cancel (only available
Paid, Cancelled if payment records is
unpaid, this option will
not be shown to the
user in case of broken
or consolidated PSID).
Edit (only available in
case of update
breakup and
consolidation
payment scenarios).

4.3.2.2. Invoice Payment Buttons:

Section Logic
Filter Results Button will only be displayed if 1 record (at the minimum) is available in the grid.
Clicking on this button would enable the search row below the Grid Heading – allowing
customer to search filters according to each column in the grid
Export Button will only be displayed if 1 record (at the minimum) is available in the grid. Data
which is available will be exported in CSV format. If user has not filtered data then all
data should be exported – otherwise only the filtered date being shown in the grid will
 be exported.

4.3.2.3. Invoice Payment Breakup – Create and Update Use case:

Breakup payment module would be enabled for the client to break the payment into multiple
segments on the behalf of their customers. For detail scenario, refer the section 3.7 and 3.8.
This module would only be available if option is enabled for the corporate customer.

For Consolidating Record on Behalf of Customer: User would require to select a customer
through (Customer Searchable dropdown). Once user is selected, system will display all
unpaid invoice of that selected customer. Refer the Screenshot attached below.

4.4. Transaction Management - Scenario 2

Transaction Management would display the following data in the grid:

Haball ID Customer Name Created Date Amount Status Action

13 – 20 digit Transaction Date when PKR 0.00 Payment would Following options will
Unique PSID Initiator’s Name transaction was consist following be displayed in
passed on by created (for Prepaid statuses (Paid, dropdown menu:
Corporate’s System ID, created date will Unpaid, In Process, View
be when Cancelled, Partially Cancel (only available
Prepayment was Paid, Cancelled in the case of Scenario
created. For Fixed (only in the case of 4 and 5)
Payment, Fixed Payment)
transaction would
be when payment
was forward to
Haball by
Corporate.
Transaction Management Main Grid:

From the action dropdown menu, user can view the transaction screen as well.
4.5. Payment View Screen:
Fields in the Advance and Invoice Payment view screen would be displayed as per the following:

Paid Payment View

Fields Type Detail Description
Payment ID Read only Payment ID generated at the time of request creation would be
displayed here in read only mode
Customer Read only Name of the Customer the PSID is generated against.
Name
Customer Read only Customer Code passed on by Corporate/Cluster
Code
Created Date Read only Date when payment request is created would be displayed here in
read only mode
Transaction Read only Date when payment request is paid would be displayed here in read
Date only mode. Only to be displayed in case status is Paid
Bank Read only Bank name from where transaction initiated would be displayed here.
Only to be displayed in case status is Paid
Transaction Read only Number generated from the bank against the initiated transaction
Auth ID would be displayed here. Only to be displayed in case status is Paid
Settlement ID Read only Number generated at the time of settlement would be displayed here.
Settlement ID field would only be displayed once the data is made
available. Only to be displayed in case status is Paid
Status Read only Current status of the payment request would be displayed here in
read only mode
Amount Read only Enter amount at the time of payment creation would be displayed
here in read only mode
Transaction Read only Transaction charges applied to the entered amount would be
Charges displayed here in read only mode. Only to be displayed in case status
is Paid
Total Amount Read Only Total Amount including transaction charges would be displayed in
here. Only to be displayed in case status is Paid
Reference No. Read Only Reference No provided in the time of PS-ID creation by Client system.
Only to be displayed if reference no is passed as a parameter by
Client. Only to be displayed in case of Scenario 4, 5, 7 and 9.
Above fields will be displayed according to the status of the Payment. If transaction is unpaid, for
example, Transaction Date, Bank, Transaction Auth ID, Settlement ID, Transaction Charges and Total
Amount will not be displayed.

Transaction Cancel Scenario (Only Available for Scenario 4, and 5, 4.4.1 and 4.4.2):

Corporates can cancel a fixed PSID that they have created, based on the following cases:

1. Through APIs: Corporate will consume Payment Update API, which will update status of PSID to
“Cancelled” on Corporate Portal and Payments Page
2. Through Cancel option, being shown in the Actions dropdown menu of the corporate portal.
4.6. Settlement Reports
As currently developed in the NHS build, the settlement grid will show Settlement ID, Date/Time and
Total Settled Amount. Each Settlement can be expanded to provide data of each transaction that
was settled in the batch.

 Settlement ID of the Batch

 Settlement Date Time of the Batch
 Total Settled Amount of the Batch
 Transactional Breakup:
o Customer Code
o Customer Name
o Haball PS ID
o Transaction Date Time
o Transaction Amount
o Payment Reference Number
o Bank Mnemonic

4.7. Audit Log

Audit log will capture the transaction data, which has been created against the following activities
performed in the Haball’s system.

 Payment consolidated either by the customer or by the corporate themselves.

 Payment split either by the customer or by the corporate themselves.
 PSID created either by the customer or by the corporate themselves.
 PSID cancelled either by the customer or by the corporate themselves.
 PSID edit either by the customer or by the corporate themselves.
 PSID paid by the customer
 PSID settled in the system.

Following Data need to be capture in the Audit Log:

Column Description
Activity Name of the activity would be displayed. For Example Split or Consolidation
Name of the activity type would be displayed. For Example Create or
Activity Type
Update
Name of the portal would be displayed. For Example Customer or
Portal
Corporate
Name of the module would be displayed. For Example Split or
Module
Consolidation or PSID Creation
User Code Code of the user would be displayed. For Example 849494
User Name Name of the user would be displayed. For Example Hussan Khalid
Activity Date Date of the activity would be displayed. For Example 25-01-2021
Activity Time Time of the activity would be displayed. For Example 05:30:25
PSID PSID generated against the consolidation or split would be displayed.
Amount of the split or consolidated PSID would be displayed. For Example
Amount
20,000.00
 PSID Status Status of the consolidated or split PSID would be displayed.
Date of the payment is marked paid would be displayed. For Example 25-
Payment Date
01-2021
Settlement ID Settlement ID received the paid payment would be displayed
Date of the payment is marked settled would be displayed. For Example 25-
Settlement Date
01-2021
PSID of the payment record (Primary Payment) through which payment is
Reference PSID
split or consolidated would be displayed
Amount of the payment record (Primary Payment) through which payment
Reference PSID Amount
is split or consolidated would be displayed
4.8. Audit Log Dashboard
For the bird eye view, system will capture the following data:

 Total Number of Consolidated Payment.

 Total Number of Split Payment.
 Total Number of Unpaid Consolidated Payment.
 Total Number of Unpaid Spilt Payment.
 Total Number of Paid Consolidated Payment.
 Total Number of Paid Split Payment.

4.9. Corporate Portal APIs

Accordingly, standard APIs will be created that will utilize Company Code and/or PSID (as the
case may be) to send transactional data of the specific corporate:

 PSID Creation – For PS-ID creation and update (only in-case of Redirection Use-case)
scenarios
 Voucher Generation – Generating PS-ID Voucher PDF File
 Status Inquiry – Returning current Status of PS-ID
 Payment Advise – sending transaction reference parameters once payment is successfully
processed.
 Settlement Advise – Sending settlement parameters
 Payment update – payment cancellation and amount update (only in-case of non-
redirection use-case) scenarios

4.10. Section to be removed from Current Build:

Following sections to be removed from current build:

 Resident Management