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.