...IntegrationMerchant Presented QRDomestic QR

We've Launched a New Documentation Website (Beta Launch)

The documentation for DuitNow is now available on our newly launched documentation platform. This is an initial beta rollout of our new documentation site, designed to become the long-term home for all documentation moving forward.

You'll find the familiar content you're used to—now hosted on a new platform that will progressively receive updates and enhancements.

We encourage you to start accessing DuitNow materials there to explore the new experience and ensure you're viewing the latest documentation updates. If you have any feedback, please reach out to us.

Visit the New Documentation Website

Merchant Presented Mode: Domestic QR

Overview

DuitNow Merchant Presented QR is a service that allows customers to make a payment via their selected mobile banking or payment application by scanning the QR code generated by the merchant.

When a customer wants to make a payment, the merchant provides a QR code, either generated statically or dynamically, to be scanned by said customer. Then, the customer is able to scan the code on their chosen mobile banking or e-payment application and key in the required amount. Finally, the application notifies the customer that the transaction is successful.

DuitNow Domestic QR has two modes available; Merchant-Presented and Consumer-Presented. This page will focus on the Merchant-Presented QR Payment.

The figure below shows the end-to-end process of DuitNow Merchant-Presented QR.

Account Enquiry Flow (Steps 1-6)

Step	Sender	Receiver	Process
1	Customer	Issuer	Customer scans a merchant’s QR code via Issuer’s Mobile App and initiates a QR Payment request.
2	Issuer	RPP	Issuer performs the following: Authorize and validate the QR Payment request Parse the QR code to extract: Application Identifier (AID) Acquirer ID Merchant Name QR ID Transaction Amount For more details on how to parse the QR code, refer to DuitNow National Quick Response Code Standard (DuitNow QR) Merchant-Presented Mode guides. Any other validations If all validations are successful: If AID belongs to PayNet, Issuer will: For On-Us Merchant NOT route the request to RPP For Off-Us Merchant Send Account Enquiry request to RPP Transaction code: 520
3	RPP	Acquirer	RPP performs the following: Message Validation Business Validation If any Message Validation fails, RPP will send a REJECT response to Issuer. If any Business Validation fails, RPP will send a NEGATIVE response to Issuer. If all validations are successful, RPP will: Send the Account Enquiry request to Acquirer
4	Acquirer	RPP	Acquirer performs the following: Message Validation Business Validation If any Message Validation fails, Acquirer will send a REJECT response to RPP. If any Business Validation fails, Acquirer will send a NEGATIVE response to RPP. If all validations are successful, Acquirer will send a SUCCESSFUL response to RPP. Notes: Acquirer shall validate the QR string, validations can be done via: Hash validation Key fields comparison (i.e. Merchant Account Information, Merchant Category Code, Merchant Name, Transaction Amount, etc) Entire QR string comparison For Dynamic QR, Acquirer will need to check for validity period
5	RPP	Issuer	RPP performs the following: Message Validation If all validations are successful, RPP will: Send a SUCCESSFUL response to Issuer A SUCCESSFUL Account Enquiry response shall contain the following information for subsequent process/validation: Merchant Name Type of QR Payment Acceptable Source of Fund
6	Issuer	Customer	Issuer performs the following: Message Validation If all validations are successful, Issuer will: For SUCCESSFUL Account Enquiry response received: Display Merchant Name Identify Type of QR Payment and Acceptable Source of Fund For UNSUCCESSFUL Account Enquiry response received: Display an error message on the customer screen

Exception Handling

Step(s)	Event	Action
2	Timeout - No response from RPP	RPP: If RPP received the request and processed it but RPP's response failed to return to Issuer, then the transaction is logged. If RPP never received the request, no action on RPP's side Issuer: Stop the timer Display an error message on the customer screen Issuer may retry by sending a new request
2	Rejection - Rejected by RPP	RPP: Send the relevant Reject Response Code. Refer to the Response Codes Include a copy of the Request Message in FULL in the response message under the AddtlData field. This can be used by the Sender(Issuer) to investigate the issue with the message Issuer: Stop the timer Message Validation
3	Timeout - No response from Acquirer	Where no response is received from Acquirer after X period of time, the following steps should be taken: RPP performs the following: Timeout after not receiving any response from Acquirer after X period of time Send a NEGATIVE response to Issuer Issuer performs the following: Stop timer Message Validation If all validations are unsuccessful, Issuer will display an error message on the customer screen.
3	Rejection - Rejected by Acquirer	Acquirer: If Message Validation fails, send a REJECT response to RPP If Business Validation fails, send a NEGATIVE response to RPP Include the original Request message in FULL in the AddtlData field for the Sender to investigate the issue RPP: Stop timer Message Validation If all validations are unsuccessful, Issuer will display an error message on the customer screen.

Credit Transfer Flow (Steps 7-13)

Step	Sender	Receiver	Process
7	Customer	Issuer	Customer confirms the QR Payment.
8	Issuer	RPP	Issuer performs the following: Authorize and validate the Credit Transfer request Any other validations If all validations are successful, Issuer will: Send Credit Transfer request to RPP Transaction code: 030
9	RPP	Acquirer	RPP performs the following: Message Validation Business Validation If any Message Validation fails, RPP will send a REJECT response to Issuer. If any Business Validation fails, RPP will send a NEGATIVE response to Issuer. If all validations are successful, RPP will proceed to: Send the Credit Transfer request to Acquirer Transaction code: 030
10	Acquirer	RPP	Acquirer performs the following: Message Validation Business Validation If any Message Validation fails, Acquirer will send a REJECT response to RPP. If any Business Validation fails, Acquirer will send a NEGATIVE response to RPP. If all validations are successful, Acquirer will: Send SUCCESSFUL response to RPP
11	Acquirer	Merchant	Acquirer notifies Merchant on successful QR Payment status.
12	RPP	Issuer	RPP performs the following: Message Validation If all validations are successful, RPP will: Set Settlement Date and Cycle Update liquidity positions of both Issuer and Acquirer Update settlement totals Send SUCCESSFUL response to Issuer Notes: If the signature received from Acquirer could not be verified, RPP will send an ACCEPTED (Signature error) response to the Issuer regardless of transaction response from Acquirer. This should take care of any message manipulation done within the data when a signature cannot be verified.
13	Issuer	Customer	Issuer performs the following: Message Validation If all validations are successful, Issuer will: Display a successful message on the customer screen Notes: If the signature received from RPP could not be verified, Issuer will refer to the status of the transaction on the actual transaction status received from RPP.

Exception Handling

Step(s)	Event	Action
8	Timeout - No response from RPP	When no response is received from RPP after X period of time, the following steps should be taken: Issuer (Step 9): Send a Single Transaction Enquiry request to RPP Start timer RPP (Step 10): Transaction Logging Message Validation If any Message Validation fails, RPP will send a REJECT Response to Issuer. If all validations are successful, RPP will send the Transaction Enquiry Response to Issuer. Issuer (Step 11): Stop timer Message Validation If all validations are successful, Issuer will display the transaction status on the customer screen.
8	Rejection - Rejected by RPP	RPP: Send the relevant Reject Response Code. Refer to the Response Codes Include a copy of the Request Message in FULL in the response message under the AddtlData field. This can be used by the Sender(Issuer) to investigate the issue with the message Issuer Stop the timer Message Validation If all validations are unsuccessful, Issuer will display an error message on the customer screen.
9	Timeout - No response from Acquirer	When no response is received from Acquirer after x period of time, the following actions will be taken: RPP: Timeout Store the Credit Transfer Transaction in SAF Set Settlement Date and Cycle Update liquidity positions of both Issuer and Acquirer Update settlement totals Send an ACCEPTED (Stored in SAF) response back to Issuer Issuer: Stop timer Message Validation If all validations are successful, Issuer will display a successful message on the customer screen. NOTE: If the signature received from RPP could not be verified, Issuer will base the status of the transaction on the actual transaction status received from RPP.
9	Rejection - Rejected by Acquirer	Acquirer: If Message Validation fails, send a REJECT response to RPP If Business Validation fails, send a NEGATIVE response to RPP Include the original Request message in FULL in the AddtlData field for the Sender to investigate the issue RPP: Stop timer Message Validation If all validations are unsuccessful, Issuer will display an error message on the customer screen.

SAF Processing Flow

Step	Sender	Receiver	Process
12	RPP	Acquirer	For SAF transactions, RPP will: Check for retry necessity base on the following parameters:- SAF Maximum Distribution Rate (msg/sec) aka TPS SAF Message Response Timer (sec) SAF Message Retry Limit SAF Open Session Limit SAF Timeout Count SAF Pause Period (sec) after consecutive timeouts SAF Out Payment Tolerance Period If retry is required: Send repeat Credit Transfer Request to Acquirer Start timer If retry is not required: Mark SAF transaction as timeout Manual handling is required Note: Reconciliation base on SAF report might be required.
13	Acquirer	RPP	Acquirer performs: Message Validation If any Message Validation fails, Acquirer will send a REJECT response to RPP. If all validations are successful, Acquirer will send a SUCCESSFUL response to RPP. *Note: Acquirer is expected to successfully authorize an ACTC transaction and credit the funds to the Merchant, aside from exceptional cases like fraudulent accounts or closed accounts
14	Acquirer	Merchant	Acquirer notifies merchant on successful QR Payment status.

Validation Rules

Message Validation

Business Validation

Message Format Validation Digital Signature Verification

RPP: Mandatory and conditional fields validation Business Message Identifier validation Issuer Check Acquirer Check Repeat Check Date Tolerance Check Minimum & Maximum Amount Check Liquidity Position Check Account Enquiry Exist Check (only in Step 9) Acquirer: Mandatory and conditional fields validation QR Validation (Only in Step 4) Beneficiary Account Validation (Only in Step 4) Any other validations