...DuitNow RequestIntegrationOverview

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

Overview

DuitNow Request allow Merchant/Biller to send a payment request to Customer. Generally, the payment request will appear in the inbox of Customer’s e-banking channel (Internet Banking or Mobile Banking). Customer can then review the request and act accordingly.  Note that in DuitNow Request flow, the payment request does not require immediate attention (longer expiry period). 

Successful End-to-End Flow

Successful Proxy Enquiry Flow (Steps 1-4)

Pay by Proxy

Pay by Proxy allows customers to make payments using a registered Proxy ID, such as a mobile number, NRIC, passport number, army number, or business registration number.

Successful Account Enquiry Flow (Steps 1-4)

Pay by Account

The Account Resolution Enquiry API verifies the validity of a beneficiary account before processing a payment request, ensuring the account is ready to receive funds.

Successful Request-to-Pay DuitNow Request (Steps 5-8)

Step	Sender	Receiver	Process
5	Merchant	Acquirer	Merchant confirms proxy information and proceeds to send Request-to-Pay request via Acquirer’s Mobile App/Internet Banking portal.    Note: Merchants may include Consent Information in the request. Issuer may use this information to prompt Customer to register for Real-time Debit Consent with Merchant
6	Acquirer	RPP	Acquirer will perform the following:  If Merchant, Check if merchant wanted to prompt for consent by checking if request included Consent Information  Authorize and validate Request-to-Pay request  Send Request-to-Pay request to RPP  Start timer Note: Transaction Type: 851 or 853
6A	RPP	Acquirer	RPP performs the following Message Logging Message Validation Message Format Validation Digital Signature Validation Business Validation Timeout Validation Payment Validation Check Date Expiry Check If Acquirer Sent Registration ID, Lookup and populate Customer Account Info and Issuer based on Registration ID If Acquirer Prompted for Consent, Transaction Type Validation Date Expiry Check Allowed Max Amount Check If any Message Validation fails, RPP will Send a REJECT response to Acquirer If any Business Validation fails, RPP will Send a NEGATIVE response to Acquirer If all validations are successful, RPP will Send an ACCEPTED response back to Acquirer Note: Timeout is set at 20 seconds Transaction Type: 851 or 853
7	RPP	Issuer	RPP performs the following Store Request-to-Pay request in SAF and begins submitting request to Issuer 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 If retry is required, Send repeat Request-to-Pay Request to Issuer Start timer Note: SAF will automatically send requests to Issuer up to the number of maximums retry Once maximum retry has been exceeded with no response, Participant must check the Exceptional SAF Report Transaction Type: 851 or 853
7A	Issuer	RPP	Issuer performs the following Message Validation Message Format Validation Digital Signature Validation Business Validation Mandatory and conditional fields validation Customer Account Validation Any other validation If any Message Validation fails, Issuer will Send a REJECT response to RPP If any Business Validation fails, Issuer will Send a NEGATIVEresponse to RPP If all validations are successful, Issuer will Send a SUCCESSFUL response to RPP Note: If Issuer Rejects the Request-to-Pay request, the Acquirer must check the SAF Rejection Report as to the reject reason and proceed accordingly Transaction Type: 851 or 853
8	Issuer	Customer	Issuer sends notification and authorization request to Customer about Request-to-Pay request

Successful Credit Transfer Flow (Steps 9-12)

Step	Sender	Receiver	Process
9	Customer	Issuer	Customer receives notification of Request-to-Pay and authorization request. Customer confirms authorization If Consent Prompt was sent in the Request-to-Pay Prompt Customer for Consent Registration If Customer wants to proceed with consent registration, proceed with flow 4.6
10	Issuer	RPP	Issuer performs the following: Authorizes and validates the Credit Transfer request Check if customer has sufficient fund Expiry of RTP Request (851/853) Any other validations RPP will not validate on the 851/853 expiry during Credit Transfer Flow (060) initiate by DA  If all validations are successful, Issuer will  Send Credit Transfer request to RPP Start Timer Note: Transaction Type: 060
10A	RPP	Issuer	RPP performs the following: Message Logging Message Validation Message Format Validation Digital Signature Verification Business Validation 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 Timeout 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 Set Settlement Date and Cycle  Update liquidity positions of both Acquirer and Issuer Update settlement totals Send the ACCEPTED response to Issuer Note: Timeout is set at 20 seconds Transaction Type: 060
11	RPP	Acquirer	RPP performs the following Encrypt Customer Account with Business Message ID Store Credit Transfer request in SAF  Begin submitting Credit Transfer request to Acquirer 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 Note: SAF will automatically send requests to Acquirer up to the number of maximum retry  Once maximum retry has been exceeded with no response, Participant must check the Exceptional SAF Report Transaction Type: 060
11A	Acquirer	RPP	Acquirer performs the following: Message Validation Message Format Validation Digital Signature Verification 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 shall not reject transactions coming from the SAF queue Transaction Type: 060
12	Acquirer	Merchant	Acquirer informs Merchant of successful Credit Transfer

Successful Rejection Flow (Steps 9-12)

Step	Sender	Receiver	Process
9	Customer	Issuer	Customer receives notification of Request-to-Pay and authorization request.  Customer rejects the request. If Consent Prompt was sent in the Request-to-Pay Customer is not shown the consent registration request Note: Customer can also opt to block receiving any further Request-to-Pay requests from the Merchant. Issuer will manage list of blocked Merchants
10	Issuer	RPP	Issuer performs the following: Rejects the request Checks if customer would also like to block Any other validations If all validations are successful, Issuer will Send Reject request to RPP Start timer Note: If the customer has indicated to block the Merchant, Issuer shall monitor. Transaction Type: 852
10A	RPP	Issuer	RPP performs the following: Message Logging Message Validation Message Format Validation Digital Signature Verification Business Validation Mandatory and conditional fields validation  Business Message Identifier validation Issuer Check Acquirer Check  Repeat Check Date Tolerance Check Timeout 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 validation are successful, RPP will Send the ACCEPTED response to Issuer Note: Timeout is set at 20 seconds Transaction Type: 852
11	RPP	Acquirer	RPP performs the following Store Reject request in SAF Begin submitting Reject request to Acquirer 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 Reject request to Acquirer Start timer Note: SAF will automatically send requests to Acquirer up to the number of maximums retry Once maximum retry has been exceeded with no response, Participant must check the Exceptional SAF Report Transaction Type: 852
11A	Acquirer	RPP	Acquirer performs the following: Message Validation Message Format Validation Digital Signature Verification If any Message Validation fails, Crediting will Send a REJECT response to RPP If all validation is successful, Acquirer will Send a SUCCESSFUL response to RPP Note: Acquirer shall not reject transactions coming from the SAF queue If the customer has indicated to block the Merchant, Acquirer shall monitor. Transaction Type: 852
12	Acquirer	Merchant	Acquirer informs Merchant of the rejected Request-to-Pay.