Real-time Retail Payments Platform (RPP) - Request to pay (RTP)

 

Overview:

Payments Network Malaysia (PayNet) is Malaysia's payments central infrastructure for financial markets. Real-time Retail Payments Platform (RPP) is a framework introduced by PayNet and aimed to support Malaysian’s Retail e‐Payment services in real time.

Request to pay service is one of those initiatives of the RPP to modernize Malaysia’s retail payments which facilitates the customer to initiate a request, to pay cost-effective and efficient manner. 

You can also refer to my other post for RTP Generic flow:

https://paymentstech.blogspot.com/2022/06/pay-with-flexibility-request-to-pay.html 

“Request to pay” service from RPP:

PayNet has developed the Core RPP infrastructure “Request-to-Pay” to address the needs of customers to have more flexible payment options for business models like Person to Person (P2P), Business to Consumer (B2C), Business to Business (B2B) and e-commerce.

The service enables Payee to send a request for Payment from Payer. The PayNet (Marchant or individual) can initiate a request for payment via a mobile application and upon authorization of request from the payer (person), payment is made instantly, easily & securely via Payer bank.

RPP is based on ISO20022 messaging standard with a highly resilient architecture built to handle high-volume retail transactions, which is connected to a real-time clearing infrastructure aimed to support Malaysia’s current and future Retail e‐Payment.

Request to pay - Use-cases:

• Customers prefer to have bill details available online for their review on the Internet or mobile banking platform and make payments at the time when they have funds available.
• Customers (e.g., Landlord) can forward the payment request received from Biller (e.g., electricity bill) as that pertains to another customer (e.g., Tenant)
• Customers can purchase from an e/m-commerce site/application and Marchant will redirect with their choice of banks to authorize the transaction/request of payment.
• Customer (eg. Friend) can pay the bill for any purpose (e.g., Dine-in bill) and later sends a request to make payments from individuals (e.g., other friends).

How does Request-to-pay work in Malaysia?

The RPP infrastructure has many payments flows to support different use-cases as below.

However, we will discuss couple of them in detail in this article.

    1. Request to Pay - Decoupled flow:

Merchant/Customer1 (Creditor) will send a payment request to pay Customer2 (Debtor). Based on the Debtor’s acceptance, a credit transfer is initiated and the Creditor account gets credited. 

•   Request to Pay - Decoupled flow:

 

Steps-by-Step flow:

1. Merchant/Customer (customer) initiate Account inquiry with help of Crediting Agent. Bank sends a request with DuitNow id (prxy.003//Trnx type 510) or Account number (pacs.008/Trnx type 510) to PayNet.
2. Debtor bank receives requests from PayNet, validates messages and performs debtor account Enquiry and sends the response back with a positive response (pacs.002/Trnx type 510).
3. Creditor initiates RTP request (pain.013.001.07), Creditor agent sends to PayNet
4. Debiting agent sends the response as (pain.014) once debiting agent identifies the message is valid.
5. Debiting agent receives the request and forwards the request to Debtor.
6. Debtor Authorizes Request (via mobile/Net Banking application)
7. Debiting Agent debit the customer (debtor) account and initiates Credit Transfer (pacs.008) and sends to PayNet.
8. Crediting agent receives from the PayNet and post validation credit to the crediting party.

• Successful Rejection Flow

Refer above diagrammatic representation.

Step-by-step flow:

1. Debtor customer rejects the RTP request, which is forwarded from the Debiting Agent to RPP and then to Crediting Agent (steps 1 to 3).
2. Crediting Agent will notify the Creditor about RTP Reject (step 4).
3. Crediting Agent will send an acknowledgment response back to the Debiting Agent (steps 2A and 3A).

. 

       2. Request to Pay – Refund:

In case if Biller/Merchant wants to refund their customer then, Merchant will enquire about the transaction from PayNet and initiate a refund. The refund will be formatted as a request to pay and will be sent to Merchant’s Bank for approval. Once the Merchant authorizes then RTP-credit transfer flow will continue to credit back to the Customer.

Step-by-step flow:

1. In some circumstances when Biller/Merchant is required to refund their customer, Biller/Merchant can make use of Request-to-Pay Refund flow.
2. Biller/Merchant login to RPP Backoffice, search for the transaction and initiate refund request for the transaction.
3. The refund request will be formatted into a payment request and sent to Biller/Merchant's bank for approval.
4. Customer will get their money back upon Biller/Merchant approval of the payment request.

3. Request to pay – Redirect flow:

Once the customer is ready to make payment from Merchant’s/Biller’s site/application, The customer (Debtor) will be redirected to the bank of their choice to authorize the payment.

4. Request to Pay – Forward:

Some scenarios, the Merchant may send a request to pay, for a bill payment to the Customer (Debtor1) which is supposed to pay by another customer (Debtor2). So Debtor1 will forward the request to Debtor2 via PayNet.

    5. Request to Pay - Batch Processing:

Sometimes corporate/merchant (Creditor) instead of sending individual payment requests to multiple customers, can choose to upload the file containing all the requests they would like to send out via Merchant Bank (Crediting Agent). On receiving requests from Crediting agent, PayNet debulks and sends all the requests to respective customers via their participants.

Used message types for Request to pay:

RPP payment solution is based on the rules and constraints specified in the PayNet RPP Specifications and on the UNIFI (ISO20022) Payments as well as Industry Standard Messages for Request to pay. Specific messages and unique transaction types signify different payment flows as below.

Request to Pay	Transaction Type	Request messages	Response Messages
Request to Pay by Proxy Request	851	pain.013.001.07	pain.014.001.07
Request to Pay by Account Number	853	pain.013.001.07	pain.014.001.07
Request to Pay (Refund)	854	pain.013.001.07	pain.014.001.07
Request to Pay by Proxy (Forward)	855	pain.013.001.07	pain.014.001.07
Request to Pay by Account Number (Forward)	856	pain.013.001.07	pain.014.001.07
Credit Transfer (RTP Decoupled)	060	pain.013.001.07	pain.014.001.07
Credit Transfer (RTP Redirect)	070	pacs.008.001.06	pacs.002.001.08
Reject Request to pay (Decoupled)	852	camt.007.001.08	camt.025.001.05
Request to Pay (Refund)	854	pain.013.001.07	pain.014.001.07
Credit Transfer (Refund)	012	pacs.008.001.06	pacs.002.001.08
Request to Pay (Redirect)	861	pain.013.001.07	pain.014.001.07
Account enquiry	510	pacs.008.001.06	pacs.002.001.08

Conclusion:

Real-Time retail payment platform is an innovative resilient architecture, that supports high-volume transactions with ISO20022 XML standards, carrying extended data of payment and same time providing secured cost-effective real-time payment. 

The service Request to pay is already launched and is expected to transform the Malaysian retail payment landscape. Some financial institutions are already go-live with the Request to pay service and others are in different phases of implementation. Soon Malaysians will avail the benefit of Request to pay and be part of the modernized digital payment ecosystem.

 

Pay with DuitNow - Malaysian QR payment

Overview

Adoption of new technology, innovation and digitization, the payment ecosystem has forced financial institutions to provide cost-effective, faster, and more convenient services to improve customer experience. 

Payments Network Malaysia (PayNet), The national payments network introduces ‘DuitNow’ QR payment, under Malaysia’s Real-Time Payments Platform (RPP) to start building the foundation of a digital payment ecosystem in Malaysia.

Further to promote cashless real-time payment and encourage the use of digital fund transfer, RPP emphasizes the progressive introduction of multiple new payment products, for multiple payment purposes. Besides QR Payments, Request-to-Pay, e-Mandates, and Real-Time Debit are also launched and expected to transform the payments landscape in Malaysia. However, this document is restricted to ‘DuitNow’ QR service and will cover other services in the future.

What is “DuitNow” QR service?

‘DuitNow’ QR is an overlay service for Real-Time Retail Payments Platform (RPP) Participants. This Convenient, efficient and secured instant credit transfer service, enables the customer to scan a QR code to pay a merchant or to another person and  also customer is capable to receive funds by presenting their own DuitNow QR for scanning. Consumers can make payments from participating Banks or e-wallets mobile applications up to RM 50,000 per transaction and businesses may pay up to RM 10,000,000 per transaction at banks. The limit varies depending on the bank and eMoney providers will have lower limits.
DuitNow QR is Malaysia’s National Standard Quick Response (QR) which was established by PayNet under the Bank Negara Malaysia (BNM), Interoperable Credit Transfer Framework (ICTF).

How does it work? 

PayNet has onboarded banks and eWallet providers to enable customers to initiate payment by using the mobile app of their choice. Customers can download the Issuer bank or service provider’s mobile app on their mobile. The application is capable to scan merchant QR codes and initiate payment. QR code implementation follows the ISO 20022 messaging standard for core payment processing and communication in the financial ecosystem.

‘DuitNow’ QR business scenarios

The QR code can be presented by a Merchant or other user in Peer to Peer payment. 
To elaborate the business flow, consider a merchant presented QR Code payment, which enables the customer to make payment for their purchases. The customer scan ‘DuitNow’ QR code of the merchant, key all the required information and submit the request. On confirmation of the payment, the Credit transfer request directs the issuer bank that holds the debtor account and funds will be automatically debited from the Customer (Debtor) account. Bank then sends the credit transfer request to Creditor bank routing via PayNet. Post successful verification in Creditor bank, the funds will be credited instantly to the Merchant (Creditor) account. 

Model layout with simple steps in ‘DuitNow’ QR payment explained for below scenarios:

• Point-of-sales (POS) payments to Merchants
• Person-to-person (P2P) payments

Inquiry flow:

1. Customer scans a merchant’s QR code via the Mobile application and initiates a QR Payment request.
2. OFI receives the QR Account Enquiry Request (pacs.008) channel.
3. OFI validates the received pacs.008.
4. On successful processing, OFI sends the QR Account Enquiry Request (pacs.008) to PayNet.
5. On receiving pacs.008, PayNet performs validation of the transaction.
6. On successful processing, PayNet sends the QR Account Enquiry Request (pacs.008) to RFI.
7. RFI receives the QR Account Enquiry Request (pacs.008) from PayNet.
8. RFI performs validation on received pacs.008 and performs Account inquiry
9. On successful Account enquiry, RFI sends the QR Account Enquiry positive response (pacs.002) back to ‘PayNet’ with 
10. PayNet will validate the received positive response notification (pacs.002) and send to OFI bank.
11. OFI receives the response notification (pacs.002).
12. OFI validates the received pacs.002 and reconciled with original pacs.008
13. On successful processing of all the above checks, OFI sends back the response notification (pacs.002) to initiating Channel.

Credit Transfer flow:

1. Once Account Enquiry is completed then, the Customer is asked to follow a few details like 
2. Verify the merchant’s name (displayed on screen)
3. Enter Payment amount
4. Keep any other details like promo code or purpose etc.
5. Customer confirms the details in the mobile application.
6. Then OFI validates all the payment information and performs Debit Posting (Debit the customer account)
7. On successful Debit posting, OFI sends the QR Credit Transfer Request (pacs.008) to PayNet.
8. Once PayNet receives pacs.008 validates the message and sends it to RFI.
9. RFI receives the QR Credit Transfer Request (pacs.008) from PayNet.
10. RFI performs required validations and perform Credit Posting (Credit customer)
11. RFI generates the QR Credit Transfer Response (pacs.002) back to PayNet.
12. On successful credit posting, RFI may notify Merchant on successful QR Payment status via camt.054 (debit credit notification).
13. PayNet validates and sends the QR Credit Transfer Response (pacs.002) to OFI.
14. OFI receives the QR Request Notification (pacs.002).
15. OFI performs validation of the received pacs.002 and reconciles with received pacs.008
16. Post successful processing of pacs.002, OFI submits the QR Notification message (pacs.002) to Initiating Channel.

Message types for Merchant presented QR:

The Merchant Presented QR Payment solution is based on the rules and constraints specified in the PayNet RPP Specifications and on the UNIFI (ISO20022) Payments as well as Industry Standard Messages for Credit Transfers and network and system notification messages respectively. Specific messages and unique transaction types signify different services.

QR Code and QR ID

QR Code

A Quick Response Code is a popular type of two-dimensional barcode. This encrypted data is used in payment processing and can store around 5k alphanumeric characters. However, all QR codes generated should comply with PayNet. To read the QR Code, customers should use a scanning application on their smartphone.

Characteristics of QR Code

Types of QR codes used:

Dynamic QR:  

A QR Code that is generated by a Merchant or Recipient for every new transaction.

A Dynamic QR code has a short URL that can be automatically redirected at any time to any site.

Due to the above points metrics like location, used device type etc can be tracked.

Static QR:

QR code has fixed information encoded into the code itself. Data cannot be changed with this QR code.

Scan performance cannot be tracked, limiting scalability.

QR Identifier or QR ID

QR Identifier or QR ID: An alphanumeric code uniquely identifying either a merchant or recipient for the purpose of routing proceeds to the designated merchants or recipient’s Account.