DocsDuitNow Online BankingDuitNow Online Banking/Wallets

DuitNow Online Banking/Wallets

See also API reference for DuitNow Online Banking/Wallets

Check API

Introduction

DuitNow Online Banking/Wallets allow customer to make payment to Merchant from their preferred bank or wallet.

From Merchant portal or mobile apps, customer will choose their preferred bank or wallet. Customer will then get redirect to the bank or wallet they choose, approve the transaction, get redirect back to Merchant and the transaction is completed.

The figure below explains in detail the end-to-end process of DuitNow Online Banking/Wallets.

Request List of Banks Flow (Steps 1-4)

Step	Sender	Receiver	Process
1	Customer	Merchant	Customer selects to checkout with Request-to-Pay
2	Merchant	RPP	Merchant performs the following: Submit request for list of banks Start the timer
3	RPP	Merchant	RPP performs the following: Message Logging Message Validation Message Format validation Digital Signature verification If any of the Message Validation fails, RPP will Send a REJECT response to Merchant If all validations are successful, RPP will Send List of Banks response to Merchant
4	Merchant	Customer	Merchant performs the following: Stop the timer Message Validation Message Format Validation Digital Signature Verification If all validations are successful, Merchant will For successful List of Banks response received, Display list of banks For unsuccessful List of Banks response received, Display an error message on the customer screen

Exception Handling

Step	Event	Action
2, 3	Timeout (Merchant gets no response from RPP)	RPP: If RPP received the request and processed it, but RPP's response failed to return to Merchant at Step 3, then the transaction is logged. If RPP never received the request, no action on RPP side Merchant: Merchant may send the request again by sending a new request
2, 3	Rejection	RPP: RPP receives the request and rejected it due to validation error e.g. Merchant is not authorized to request List of Banks Merchant: -

Request-to-Pay Flow (Steps 5-8)

Step	Sender	Receiver	Process
1	Customer	Merchant	Customer selects a bank
2	Merchant	RPP	Merchant will perform the following: Authorize and validate Request-to-Pay request Send Request-to-Pay request to RPP Start the timer
3	RPP	Merchant	RPP performs the following Message Logging Digital Signature Validation Message Format Validation Message Validation Business Validation Timeout Validation Payment Validation Check Date Expiry Check Merchant ID Validation Merchant Product ID If any of the Message Validation fails, RPP will Send a REJECT response to Merchant If any of the Business Validation fails, RPP will Send a NEGATIVE response to Merchant If all validations are successful, RPP will Lookup and populate Creditor Account ID and Crediting Agent based on Merchant ID and Merchant Product ID Generate Signature with End-to-End ID Store Transaction Information in Request-to-Pay Staging Table Send an ACCEPTED response back to Merchant with End-to-End ID and Signature Note: Timeout is set at 20 seconds
4	Merchant / Biller	Debiting Agent	Merchant performs the following: Stop the timer Message Validation Message Format Validation Digital Signature Verification If all validations are successful, Merchant will: Redirect Customer to the selected bank Send Signature and End-to-End ID to Debiting Agent

Exception Handling

Step	Event	Action
2, 3	Timeout (Merchant gets no response from RPP)	RPP: If RPP received the request and processed it, but RPP's response failed to send to Merchant at Step 3, then the Request-to-Pay transaction is logged with PENDING status, but is orphaned in the table, as it cannot be referenced If RPP never received the request, no action on RPP side Merchant: Merchant shall not send a repeat or duplicate request Merchant can send an enquiry to check the status of the Request-to-Pay Merchant shall send a new request to re-initiate the transaction
2, 3	Rejection	RPP: RPP logs reject, returns reject status to Merchant. If RPP responds with reject after storing a pending Request-to-Pay record in table, the record will be orphaned, no reference to it will be sent back to Merchant in the rejection response Merchant: -

Retrieve Transaction Info Flow (Steps 9-12)

Step	Sender	Receiver	Process
1	Debiting Agent	RPP	Debiting Agent performs the following: Validate Signature sent by Merchant Send Retrieve Transaction Info Request based on End-to-End ID Start Timer
2	RPP	Debiting Agent	RPP performs the following Message Logging Message Validation Message Format Validation Digital Signature Validation Business Validation Timeout Validation Payment Validation Check Check Request-to-Pay Staging Status If any Message Validation fails, RPP will Send a REJECT response to Debiting Agent If any Business Validation fails, RPP will Send a NEGATIVE response to Debiting Agent If all validations are successful, RPP will Lookup Transaction Info based on End-to-End ID from Staging Table Return Retrieve Transaction Info Response
3	Customer	Debiting Agent	Customer login into their mobile/internet banking portal of Debiting Agent Customer allowed to retry if failed to login
4	Debiting Agent	Customer	Debiting Agent performs the following: Perform Login Validation If validation fails Debiting Agent will Display error code to customer Send a Cancel Request-to-Pay to RPP If validation is successful Display Transaction Information to customer

Exception Handling

Step	Event	Action
1, 2	Timeout (Debiting Agent gets no response from RPP)	RPP: If RPP received the request and processed it, but RPP's response failed to return to Debiting Agent at Step 2, then the transaction is logged, and the PENDING Request-to-Pay status may be updated to RETRIEVED If RPP never received the request, no action on RPP side Debiting Agent: Debiting Agent may re-request after a timeout. RPP shall return the transaction info if the transaction status still in PENDING or RETRIEVED state
1, 2	Rejection	RPP: RPP may reject based on parameter validation, in this case the PENDING status Request-to-Pay record remains at status PENDING Debiting Agent: -

Update Payment Status Flow (Steps 13-16)

Step	Sender	Receiver	Process
1	Customer	Debiting Agent	Customer performs the following Confirm transaction information Request update transaction status to Pending Authorisation
2	Debiting Agent	RPP	Debiting Agent performs the following Validate Customer response Any other validation Send an update payment status request to RPP Start the timer
3	RPP	Debiting Agent	RPP performs the following Message Logging Message Validation Message Format Validation Digital Signature Validation Business Validation Timeout Validation Payment Validation Check Check Request-to-Pay Staging Status If any Message Validation fails, RPP will Send a REJECT response to Debiting Agent If any Business Validation fails, RPP will Send a NEGATIVE response to Debiting Agent If all validations are successful, RPP will Update Request-to-Pay Staging table status to; PDAU – Pending Authorisation, OR RJCT – Rejected Return Transaction Status Response
4	RPP	Merchant	RPP performs the following: Notify Merchant of Update Payment Status via Merchant Notification API

Exception Handling

Step	Event	Action
2, 3	Timeout (Debiting Agent gets no response from RPP)	RPP: RPP may or may not have updated the RETRIEVED status of Request-to-Pay to COMPLETED Debiting Agent: Request may be sent again by Debiting Agent but may be rejected if Request-to-Pay status had been updated by previous timed-out request
2, 3	Rejection	RPP: If field validation error, RPP sends an error message to Debiting Agent (at Step 3) with details of field validation failure, and the request message is logged in the reject log If Session/Business Rule validation failure or other error within session: Transaction is logged, and RPP sends response with rejection status/reason code to Debiting Agent Debiting Agent: Debiting Agent has rejection information so can process accordingly

Credit Transfer Flow (Steps 13-18)

Step	Sender	Receiver	Process
1	Customer	Debiting Agent	Customer performs the following Confirm transaction information
2	Debiting Agent	RPP	Debiting Agent performs the following Validate Customer Response Any other validation Debit customer Send an update payment status request to RPP Start the timer
3	RPP	Debiting Agent	RPP performs the following Message Logging Message Validation Message Format Validation Digital Signature Validation Business Validation Timeout Validation Payment Validation Check Check Request to Pay Staging Status Minimum Amount Check Maximum Amount Check If any Message Validation fails, RPP will Send a REJECT response to Debiting Agent If any Business Validation fails, RPP will Send a NEGATIVE response to Debiting Agent If all validations are successful, RPP will Update liquidity positions of both Crediting Agent and Debiting Agent Update settlement totals Update Request-to-Pay Staging table status to SUCC (Successful) Return Payment Status Response with Merchant Redirect URL/App ID Encrypts Debtor Account Submits Credit Transfer Request to SAF Note: Timeout is set at 20 seconds
4	RPP	Crediting Agent	RPP performs the following Check for SAF 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, Sends a repeat Credit Transfer Request to Crediting Agent Starts the timer Note: SAF will automatically send requests to Debiting Agent up to the maximum number of retry Once maximum retry has been exceeded with no response, Participant must check the Exceptional SAF Report
5	Crediting Agent	RPP	Crediting Agent 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 validations are successful, Crediting Agent will Send a SUCCESSFUL response to RPP
6	RPP	Merchant	RPP performs the following: Notify Merchant of successful Payment via Merchant Notification API Note: Merchant required to determine the date/time. However, by default RET/B2C 15min and COR/B2B is 5 days

Exception Handling

Step	Event	Action
2, 3	Timeout (Debiting Agent gets no response from RPP)	RPP: RPP may or may not have updated the RETRIEVED status of the Request-to-Pay to COMPLETED Debiting Agent: Debiting Agent has already debited the debtor before attempting the send of Credit Request. Debiting Agent may also perform a status enquiry to get the transaction status. If no result is returned, then the request may be sent again by Debiting Agent
2, 3	Rejection	RPP: If field validation error, RPP sends an error message to Debiting Agent (at Step 3) with details of field validation failure, and the request message is logged in the reject log If Session/Business Rule validation failure or other error within session: Transaction is logged, and RPP sends response with rejection status/reason code to Debiting Agent. Payment status notification (Not Approved) is sent to Merchant Debiting Agent: Debiting Agent has already debited the debtor before attempting the send of Credit Request. Debiting Agent has rejection information so can process accordingly
4, 5	Timeout (RPP gets no response from Merchant/Biller)	RPP: Sent by SAF, SAF will continue to re-send while timeout occurs on send attempts Merchant/Biller: -
4, 5	Rejection	RPP: Sent by SAF, SAF will log the reject response received at 5 in SAF log and consider the request as sent Merchant/Biller: -

Merchant Initiated Cancellation (After Step 8, before step 14)

After Step 8, a Merchant may initiate a Cancellation Request of the Request-to-Pay in the Redirect Flow. However, this request must be initiated before Step 14 where the customer would have already approved the transaction.

Step	Sender	Receiver	Process
1	Merchant	RPP	Merchant will perform the following: Sends a Cancellation Request to RPP Starts the timer
2	RPP	Merchant	RPP performs the following Message Logging Message Validation Message Format Validation Digital Signature Validation Business Validation Timeout Validation Transaction Type Validation Date Expiry Check Check Request-to-Pay Staging Status If any Message Validation fails, RPP will Send a REJECT response to Merchant If any Business Validation fails, RPP will Send a NEGATIVE response to Merchant If all validations are successful, RPP will Inform DA to update the PDAU (Pending Authorisation) status to CANC (Cancel) and transaction updated to failed Change status of Request-to-Pay in staging table to CANC (Cancel) Send an ACCEPTED response back to Merchant/Biller

Exception Handling

Step	Event	Action
1, 2	Timeout(Merchant gets no response from RPP)	RPP: - Merchant: Merchant shall not send a repeat request after a timeout Merchant can perform enquiry to check the status of the Request-to-Pay in the staging table Merchant can send a new request
1, 2	Rejection	RPP: If field validation error, RPP sends an error message to Merchant at Step 2, with details of field validation failure, and the request message is logged in the reject log If Session/Business Rule validation failure or other error within session: Transaction is logged, and RPP sends response with rejection status/reason code to Merchant at Step 2 Merchant/Biller: Merchant has rejection information so can process accordingly