...DuitNow ReversalIntegrationOverview

Overview

A DuitNow Reversal (previously known as credit transfer reversal) is triggered to return funds from a completed transaction to the original payer in the transaction’s original form of payment. This can happen for a multitude of reasons, including customer disputes, suspected fraud or merchant-initiated cancellations (e.g. pre-auth cancellations).

Understanding the Types of Reversals

There are many scenarios a merchant, an acquirer, an issuer or a payer might encounter when it comes to reversing transactions and returning funds, where they can be classified generally under one of the 4 types of reversals: pre-auth cancellation, refund, chargeback or reversal adjustment. DuitNow Reversal supports 2 of the 4 types of credit transfer reversals for all of the DuitNow services that we provide.

Types of Reversals

There are four main types of reversals, but DuitNow Reversal only supports two of them:

Refund

A refund is the process of a merchant or recipient returning funds to a payer (or originator) for a transaction that has already been completed (settled). The refunded amount is credited back to the original payment source used by the payer.

Examples of Refunds within DuitNow:

• Refunding a DuitNow QR POS transaction by the merchant.
• Refunding a DuitNow Online Banking/Wallet transaction by the merchant.
• Refunding a DuitNow Transfer transaction due to a SAF Rejected status.

How Refunds Work with DuitNow Reversal:

• DuitNow Reversal provides two transaction codes for issuing refunds:
• Code 011 - Credit Transfer Reversal (Clear)
• Code 012 - Credit Transfer Reversal (Masked)
• DuitNow Reversal provides a transaction code to initiate refund intent:
• Code 854 - Refund Intent Initiation

Other types of reversals that DuitNow does not support include:

• Chargeback
• Reversal Adjustment

How Refunds and Cancellations work via DuitNow Reversal

As an acquirer, the participant may receive the customer or debtor account number from the transaction that was initiated in clear or encrypted format. Acquirers may directly use the clear or encrypted account numbers to trigger a DuitNow Reversal. On the other hand, acquirers may also separately obtain the clear account numbers

for those encrypted ones in the Transaction Daily Report TAR02 or RPP Daily Itemised Report Coming Soon

The following table shows the DuitNow products and the following types of account number that is provided to the acquirer:

DuitNow Credit Transfer Transaction Codes

Credit Transfer Transaction Code	Credit Transfer Feature	Reversal Transaction Code	Encrypted or Clear Account Number
010	DuitNow Transfer Pay-to-Account	011	CLEAR
110	DuitNow Transfer Pay-by-Proxy	011	CLEAR
030	DuitNow QR MPM POS	011	CLEAR
040	DuitNow QR MPM P2P	011	CLEAR
031 Discovery & Future Planning	DuitNow Cross-Border QR MPM POS	011	CLEAR
032 Discovery & Future Planning	DuitNow QR Cash Out	011	CLEAR
240 Discovery & Future Planning	DuitNow QR CPM	011	CLEAR
250 Discovery & Future Planning	DuitNow QR CPM Post-Authorisation	011	CLEAR
060 Discovery & Future Planning	DuitNow Request	012	ENCRYPTED
070	DuitNow Online Banking/Wallet	012	ENCRYPTED
210 Discovery & Future Planning	DuitNow AutoDebit from Bank	012	ENCRYPTED
220 Discovery & Future Planning	DuitNow AutoDebit from Merchant	012	ENCRYPTED
210 Discovery & Future Planning	DuitNow AutoDebit Pre-Authorisation	012	ENCRYPTED

DuitNow Reversal for Refunds

Step	Sender	Receiver	Process
1-6			Credit Transfer process as established according to the DuitNow products.
7	Merchant	Acquirer	Merchant confirms result of dispute and initiates refund intent through their Acquirer.
8	Acquirer	RPP	Acquirer performs the following: Authorize and validate the DuitNow Reversal request Any Internal Validations Debit source account If all validations are successful: Send DuitNow Reversal request
9	RPP	Issuer	RPP performs the following: Message Validations Business Validations Liquidity Position Validations If any of the Message Validations fails: Send a REJECT response If any of the Business Validations fails: Send a NEGATIVE response If any of the Liquidity Position Validations fails: Send a NEGATIVE response If all validations are successful: Check if an Account Enquiry request has been made in prior within a stipulated time interval If Account Enquiry is NOT found: Send Account Enquiry by using the same message but changing the transaction code from Credit Transfer to Account Enquiry If Account Enquiry is found: Send Credit Transfer message request
10a	Issuer	RPP	Issuer performs the following: Message Validations Business Validations Beneficiary Account Validations If any of the Message Validations fails: Send a REJECT response If any of the Business Validations fails: Send a NEGATIVE response If any of the Beneficiary Account Validations fails: Send a NEGATIVE response If all validations are successful: Send SUCCESSFUL DuitNow Reversal response
10b	Issuer	Customer	Issuer informs the Customer on refund status from the Merchant If the Reversal is SUCCESSFUL: Display the SUCCESSFUL status to the Customer Credit the funds to the Customer If the Reversal is UNSUCCESSFUL: Display the UNSUCCESSFUL status to the Customer
11	RPP	Acquirer	RPP Return Response to the Acquirer RPP performs the following: Message Validations Business Validations If any of the Message Validations fails: Return a REJECT response to RFI If any of the Business Validations fails: Return a NEGATIVE response to RFI If all validations are successful: Update liquidity and settlement positions of both Issuer and Acquirer Send DuitNow Reversal message response Notes: If the signature received from Issuer could not be verified: RPP will send an ACCEPTED (signature error) response to the Acquirer if the Issuer responds with a SUCCESSFUL transaction status RPP will send an actual REJECT response to the Acquirer if Issuer responds with a REJECT transaction status This should take care of any message manipulation done within the data when a signature could not be verified
12	Acquirer	Merchant	Acquirer updates Merchant on refund status If the Reversal is SUCCESSFUL: Display the SUCCESSFUL status to the Merchant Credit the funds to the Merchant If the Reversal is UNSUCCESSFUL: Display the UNSUCCESSFUL status to the Merchant

Handling SAF Rejected Transactions

When there’s a timeout at RPP (which can occur if the request wasn’t sent to the acquirer or if RPP didn’t receive a response from the acquirer), the transaction is saved in the Store and Forward (SAF) queue so that it can be sent to the acquirer again for completion. After resending, some transactions will succeed, while others may be rejected or still remain unknown if the timeouts persist and the maximum retry attempts has been reached. At T+1, the rejected transactions will be compiled into the SAF Rejected Transactions Reports (SRTR02 or RTPPR02 depending on the services) for participants to obtain via the FI server. After receiving these files, the acquirer should initiate a DuitNow Reversal transaction for each of the rejected transactions to return the funds back to the issuer.

On the other hand, when transactions encounter timeout issues at the acquirer and remain unknown even after reaching the maximum number of retries, they will be compiled into the SAF Exception Reports (SER02 or RTPPE02), where the issuer and acquirer will need to address them separately from RPP.

Step	Sender	Receiver	Process
1	PayNet	Acquirer	PayNet will provide Acquirer the SAF Rejected Transactions Reports (SRTR02 and RTPPR02) in the FI server where Acquirer can download and view the transactions that were rejected by them.
2	Acquirer	RPP	Acquirer performs the following: Authorize and validate the DuitNow Reversal request Any Internal Validations Debit source account If all validations are successful: Send DuitNow Reversal message request
3A,3B	RPP	Issuer	RPP performs the following: Message Validations Business Validations Liquidity Position Validations If any of the Message Validations fails: Send a REJECT response If any of the Business Validations fails: Send a NEGATIVE response If any of the Liquidity Position Validations fails: Send a NEGATIVE response If all validations are successful: Check if an Account Enquiry request has been made in prior within a stipulated time interval If Account Enquiry is NOT found: Send Account Enquiry by using the same message but changing the transaction code from Credit Transfer Reversal to Account Enquiry If Account Enquiry is found: Send DuitNow Reversal message request
4	Issuer	RPP	OFI performs the following: Message Validations Business Validations Beneficiary Account Validations If any of the Message Validations fails: Send a REJECT response If any of the Business Validations fails: Send a NEGATIVE response If any of the Beneficiary Account Validations fails: Send a NEGATIVE response If all validations are successful: Send Account Enquiry message response with the necessary beneficiary account information
5	Issuer	RPP	Issuer performs the following: Message Validations Business Validations Benificiary Account Validations If any of the Message Validations fails: Send a REJECT response If any of the Business Validations fails: Send a NEGATIVE response If any of the Beneficiary Account Validations fails: Send a NEGATIVE response If all validations are successful: Send SUCCESSFUL DuitNow Reversal Response
6	RPP	Acquirer	RPP Return Response to Acquirer RPP performs the following: Message Validations Business Validations If any of the Message Validations fails: Return a REJECT response to Acquirer If any of the Business Validations fails: Return a NEGATIVE response to Acquirer If all validations are successful: Update liquidity and settlement positions of both Issuer and Acquirer Send SUCCESSFUL DuitNow Reversal message response Notes: If the signature received from Issuer could not be verified: RPP will send an ACCEPTED (signature error) response to the Acquirer if the Issuer responds with a SUCCESSFUL transaction status RPP will send an actual REJECT response to the Acquirer if Issuer responds with a REJECT transaction status This should take care of any message manipulation done within the data when a signature could not be verified
7	Issuer	Customer	Issuer performs the following: If the Reversal is SUCCESSFUL: Display the SUCCESSFUL status to the Customer Credit the funds to the Customer If the Reversal is UNSUCCESSFUL: Display the UNSUCCESSFUL status to the Customer

Refund Intent Initiation

In specific scenarios where a Merchant Acquirer is required to process a refund for their customer, they may initiate the refund intent via DuitNow Pay (DuitNow Pay Refund) or directly to RPP. The refund Intent will be transmitted to PayNet, which will then relay the Refund Intend to the Acquirer. Upon receipt, the Acquirer is required to acknowledge the request and proceed with the refund process by invoking the relevant API call to PayNet (DuitNow Reversal for Refund Intent).

Step	Sender	Receiver	Process
1	Merchant/Biller	Merchant Acquirer	Merchant/Biller performs the following: Initiate refund intent
2	Merchant Acquirer	DuitNow Pay	Merchant Acquirer performs the following: Initiate refund intent via DuitNow Pay
3A	DuitNow Pay	Merchant Acquirer	Initiate refund via DuitNow Pay performs the following: DuitNow Pay will send REFUND_PENDING response while processing the request.
4	DuitNow Pay	RPP	DuitNow Pay performs the following: Initiate Refund Request to RPP
5	RPP	Acquirer	RPP initiate Request to Pay to Acquirer Note: Transaction Type: 854
6	Acquirer	RPP	Acquirer shall provide an acknowledgement back to RPP
7	RPP	DuitNow Pay	RPP shall provide an acknowledgement back to DuitNow Pay
8	DuitNow Pay	Merchant Acquirer	DuitNow Pay performs the following: DuitNow Pay will send Refund request status via webhook to Acquirer

Pre-Auth Cancellation Coming Soon