Skip to main content

Merchant-Presented QR

See also API reference for DuitNow QR

Introduction

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.

Overview Flow of Domestic QR

Account Enquiry Flow (Steps 1-6)

Flow of Account Enquiry

StepSenderReceiverProcess
1CustomerIssuerCustomer scans a merchant’s QR code via Issuer’s Mobile App and initiates a QR Payment request.
2IssuerRPPIssuer 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
  • If AID does not belong to PayNet or QR code is not parse-able, Issuer will:
    • Send Account Enquiry request to RPP using transaction code 521
  • [Optional] DuitNow Reward: Issuer to send the Debtor ID for Acquirer to identify the customer
Transaction code: 520
3RPPAcquirerRPP performs the following:

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
4AcquirerRPPAcquirer performs the following:
  • Message Validations
  • Business Validations
  • [Optional] DuitNow Interoperable Reward: Acquirer will perform the necessary validations and include the reward information in the response to RPP
    • Acquirer may identify user's identity based on the Debtor ID Issuer provided and perform below:
      • New user: no reward* (*depends on Acquirer reward mechanism, acqurer may offer reward for new user)
      • Existing user: return user's entitled reward

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:
  1. 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
  2. For Dynamic QR, Acquirer will need to check for validity period
5RPPIssuerRPP performs the following: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
6IssuerCustomerIssuer performs the following: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
    • [Optional] DuitNow Reward: Display user’s entitled reward
  • For UNSUCCESSFUL Account Enquiry response received:
    • Display an error message on the customer screen

Exception Handling

Step(s)EventAction
2Timeout - 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
2Rejection - 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:

3Timeout - 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:

If all validations are unsuccessful, Issuer will display an error message on the customer screen.

3Rejection - 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)

Flow of Credit Transfer

StepSenderReceiverProcess
7CustomerIssuerCustomer confirms the QR Payment.
8IssuerRPPIssuer performs the following:
  • Authorize and validate the Credit Transfer request
  • Any other validations
  • [Optional] DuitNow Reward: Execute the reward entitled for user
If all validations are successful, Issuer will:
  • Send Credit Transfer request to RPP
Transaction code: 030
9RPPAcquirerRPP performs the following:

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
10AcquirerRPPAcquirer performs the following:

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
11AcquirerMerchantAcquirer notifies Merchant on successful QR Payment status.
12RPPIssuerRPP performs the following: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:
  1. 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.
13IssuerCustomerIssuer performs the following:If all validations are successful, Issuer will:
  • Display a successful message on the customer screen
  • [Optional] DuitNow Reward: Display user’s new reward entitlement (if any)
Notes:
  1. 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)EventAction
8Timeout - 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.
8Rejection - 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.

9Timeout - 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.

9Rejection - 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

Flow of SAF

StepSenderReceiverProcess
12RPPAcquirer

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.

13AcquirerRPP

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 CANNOT reject transactions coming from the SAF queue.

14AcquirerMerchantAcquirer notifies merchant on successful QR Payment status.

Validation Rules

Message ValidationBusiness 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