Project 3
Project 3
ABBREVIATIONS
CHAPTER 1
INTRODUCTION
The project was done to obtain better understanding of Raast is Pakistan’s first instant
payment system that will enable end-to-end digital payments among individuals, businesses
and government entities instantaneously. The state-of-the-art Pakistan’s Faster Payment
System will be used to settle small-value retail payments in real time while at the same time
provide a cheap and universal access to all players in the financial industry including
commercial banks, microfinance banks, government entities and fintech’s (EMIs & PSPs).
Pakistan has had low electronic transactions for a number of reasons including low banking
penetration, lack of trust and awareness of digital payment methods, limited interoperability,
difficult accessibility and high cost of transactions. The Real Time Gross Settlement System
(RTGS) of Pakistan provides instant payment settlements for large value and corporate
transactions only. Raast: Pakistan’s Instant Payment System will facilitate retail payment
settlements with much great efficiency.
1.1 Motivation
Consumers can benefit from the flexibility that faster payments offer, such as the ability to
complete last-minute or emergency payments. With this capability, consumers can avoid late
fees, the risk of account overdrafts, and damage to their credit scores.
Limited interoperability: Financial institutions (i.e. the providers of digital payment services) have
difficulty connecting to each other due to a lack of necessary central infrastructure.
High cost of digital payments to the end user: End users are charged high fees for transferring money
digitally, making digital payments inaccessible for a large portion of the population.
Poor user experience: End users must go through a complex process to make digital payments and there
are no digital modes of payment that are widely accepted by merchants.
2
Lack of security: Currently available digital payment types and infrastructure do not offer
sufficient/adequate data protection and authentication
CHAPTER 2
LITERATURE REVIEW
2.1 Introduction
This chapter is about the project's Existing Literature, which is conducted to learn about the
research effort based on our study. The review covers the process of functioning of
advanced analytical algorithms in some of the projects, as well as the difficulties that arise.
"What other people here think" is indeed valuable information for many of us while
making judgments. The Internet and the World Wide Web have suddenly made it possible
to learn about the viewpoints and experiences of individuals who are neither our close
friends nor well-known expert critics — in other words, people we have never heard of. On
the other hand, a large number of people are making their thoughts known to strangers over
the Internet. Individual customers' interest in online views regarding products and services,
as well as the potential effect such opinions may have, is a major driving force behind this
field of study. And there are numerous problems associated with this process that must be
overcome to get the desired results. In this study, we examined the fundamental approach
2
that is often used in this procedure as well as the steps which must be followed to
overcome the problems that are confronted.
2.2.2 Postman:
Ppostman is an application used for API testing. It is an HTTP client that tests
HTTP requests, utilizing a graphical user interface, through which we obtain different
types of responses that need to be subsequently validated.
2.2.3 SoapUI:
SoapUI is a tool for testing Web Services; these can be the SOAP Web
Services as well RESTful Web Services or HTTP based services. SoapUI is an Open
Source and completely free tool with a commercial companion -Ready API- that has
extra functionality for companies with mission critical Web Services.
CHAPTER 3
Figure 1
Figure 2
2
Figure 3
CHAPTER 4
Figure 4
Used Endpoint –
API Gateway 1. POST /instructions/validate – Initiating Institution calls method ‘Send
instructions’ (refer to 2.1.1 Method ‘Send instructions’ format) to call Receiving Bank and
send instructions for validation. API call contains instructions from one batch.
2.1. Authorize sender participant – API Gateway authorizes calling participant via MPG
database (participant’s user should be registered in MPG).
2.2. Search endpoint – API Gateway searches endpoint (URL) of the Receiving Bank
(Receiver-Participant-Code).
2.3. POST /instructions/validate – API Gateway calls Receiving Bank’s method ‘Send
instructions’ (refer to 2.1.1 Method ‘Send instructions’ format) using found endpoint to
instructions for validation to Receiving Bank.
3.1. Error reply – Receiving Bank replies to API Gateway with error in case of mistakes in
received data.
3.2. Error reply – API Gateway transmits error response to Initiating Institution.
2
4.1. Success reply – Receiving Bank replies to API Gateway with success that data was
accepted.
4.2. Success reply – API Gateway transmits success response to Initiating Institution.
5. Validate instructions – Receiving Bank checks possibility to process instructions, validate
Customers accounts.
6.1. POST /instructions/validate/status – Receiving Bank calls Method ‘Validation status’
format to send result of processing.
6.2. POST /instructions/validate/status – API Gateway transmits request.
7.1. Error reply – Initiating Institution replies to API Gateway with error in case of mistakes
in received data.
7.2. Error reply – API Gateway transmits error response to Receiving Bank.
8.1. Success reply – Initiating Institution replies to API Gateway with success that data was
accepted.
8.2. Success reply – API Gateway transmits success response to Receiving Bank.
Figure 5
CHAPTER 5
Figure 6
2
Figure 7
Figure 8
CHAPTER 6
6.1 Coding:
BROKER SCHEMA com.systemsltd.mpg.validationservice.esql
2
remoteAddress, 'TITLE_FETCH');
DECLARE instructionRef REFERENCE TO
transactionRef.instructions.Item;
CREATE FIELD OutputRoot.JSON.Data;
WHILE LASTMOVE(instructionRef) DO
DECLARE transactionPayload CHARACTER serializeData(instructionRef);
DECLARE transactionReferenceId CHARACTER instructionRef.instructionId;
DECLARE transactionDetailId INTEGER
saveTransactionDetail(transactionGroupId, hostReferenceId,
getTransactionStatusReceived(), transactionPayload, processingMode,
transactionReferenceId,senderParticipantCode,
COALESCE(instructionRef.amount.value, NULL), NULL, 'TF.PROCESSING');
MOVE instructionRef NEXTSIBLING REPEAT TYPE;
END WHILE;
DELETE FIELD OutputRoot.JSON;
SET payloadRef.statusCode = 0;
SET httpResponseCode = 200;
END IF;
DECLARE payloadSerialize CHARACTER
serializeMessage(payloadRow);
CALL createResponseHeader(header, OutputRoot,
httpResponseCode);
DECLARE jwsResponseHeaderSerialize CHARACTER
createJsonSignatureHeader('jose', 'RS256');
DECLARE privateKey BLOB getConfigPropertyBLOB('PRIVATE_KEY');
DECLARE keyAlgo CHARACTER getConfigProperty('KEY_ALGO');
DECLARE signatureAlgo CHARACTER
getGroupConfigProperty('JWS/JWT', '', 'SIGNATURE_ALGO');
DECLARE encodedResponse CHARACTER generateJWS(
jwsResponseHeaderSerialize, payloadSerialize,
signatureAlgo, privateKey , keyAlgo);
SET OutputRoot.BLOB.BLOB = CAST(encodedResponse AS BLOB CCSID
1208);
CALL logInfoDecoratedMessage('Validate Instructions Response Prepared',
OutputRoot);
RETURN TRUE;
END;
END MODULE;
CREATE FILTER MODULE ValidateStatusRequest
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL logInfoDecoratedMessage('GetStatus Request Received',
Root);
CREATE FIELD Environment.Variables.Transaction;
DECLARE envRef REFERENCE TO Environment.Variables.Transaction;
DECLARE queryParms REFERENCE TO
LocalEnvironment.HTTP.Input.QueryString;
CALL validateHeader(Root.HTTPInputHeader, envRef);
IF (NOT fieldAndValueExists(queryParms.instructionId,
'instructionId') AND NOT fieldAndValueExists(queryParms.batchId,
'batchId')) OR
NOT fieldAndValueExists(queryParms.valueDate,
'valueDate') THEN
SET envRef.errorCode = '101';
SET envRef.errorDesc = 'Invalid request';
END IF;
IF NOT EXISTS(Environment.Variables.Transaction.errorCode[])
THEN
IF NOT fieldAndValueExists(Root.HTTPInputHeader.Cryptogram,'Cryptogram')
THEN
SET envRef.errorCode = 305;
2
RETURN TRUE;
END;
END MODULE;
CREATE COMPUTE MODULE PrepareFailureResponse
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
SET OutputRoot.Properties = InputProperties;
DECLARE envRef REFERENCE TO Environment.Variables.Transaction.error;
DECLARE header REFERENCE TO InputRoot.HTTPInputHeader;
DECLARE payloadRow ROW;
CREATE LASTCHILD OF payloadRow DOMAIN('JSON');
CREATE LASTCHILD OF payloadRow.JSON NAME 'Data';
DECLARE payloadRef REFERENCE TO payloadRow.JSON.Data;
SET payloadRef.statusCode = envRef.errorCode;
SET payloadRef.description = envRef.errorDesc;
2
RETURN FALSE;
END IF;
ELSE
RETURN FALSE;
END IF;
RETURN TRUE;
END;
END MODULE;
CHAPTER 7
7.1 REFERENCE:
Internet : https://www.sbp.org.pk/dfs/Raast.html [Last access on December 13, 2022]
Internet : https://www.arcanainfo.com/ [Last access on December 12, 2022]
Internet : https://www.ibm.com/products/app-connect [Last access on December 02,
2022]