Important Notes

• While transacting if there is “Proxy Error” Page, Then there are chances that the payment has been processed. So, before initiating second request just check once with the sender bank if the payment is credited back or not. Also report similar cases via email or call.
• The MPIN entry dynamically changes based on bank MPIN format. For e.g. If Axis bank supports 6 digit MPIN format then on time of registration it accepts the 6 digit MPIN and at the time of payment it accepts the same 6 digit MPIN and like Vijaya Bank supports 4 digits MPIN then it accepts the same at the time of Registration and Payment Process Special characters are not used in Merchant Trnx ID, Payee Name etc.
• No Response from SDK: In case of no response from the SDK, then it is recommended to use the Transaction Status Enquiry API or check the final status of the transaction in the Merchant Portal. Pl note that the Merchant Trnx ID/Order ID will be the identifier in this case. This ID can be used for both transaction enquiry service and for checking the final status in Merchant Portal.
• Time-Out Response from SDK: In case of transaction where the status is TIME-OUT, then such transactions are in pending state where the status is unknown even to NPCI. For such transactions, banks may take 3-5 business days to reconcile offline. The timelines vary across the banks. Such scenarios bear either of the two consequences:
• Remitter Account is refunded after the bank reconciliation. Such transactions should be considered as “FAILED” transactions, but it will always show “TIMED-OUT” status as the reconciliation was done offline.
• Beneficiary Account is credited after the bank reconciliation. Such transactions should be considered as “SUCCESS/APPROVED” transactions, but it will always show “TIMED-OUT” status as the reconciliation was done offline.

In case a transaction has failed, but the refund has not been processed online to the remitter account, then the refund will be processed on T+1 post the bank reconciliation

In both the above scenarios, if YES BANK is neither the remitter nor the beneficiary bank, then the customer should take up such requests with their banks respectively. The customer should quote the CustRefID in this case.

Similarly, for merchant transactions, which are there in time-out state, YES BANK follows the below process:

• In case the transaction was credited online to the Merchant, but response was not recorded in the system (NPCI, YES BANK, REMITETR BANK), then for such transactions, YBL confirms success status to NPCI. In case Merchant wants to provide refund to such customers (as credit was received, but goods/services not delivered because of unavailability of a confirmed success response), then it can either do NEFT/IMPS (customer account details are available in the Merchant Portal) or use Refund API to initiate a fresh transaction to the user
• In case the transaction was not credited online to the Merchant, then for such transactions, YBL returns the funds to the Remitter Bank. Remitter Bank ideally takes a day to return the funds to the end customer. Such transactions are declined transactions.

It is completely at the discretion of the Merchants on how they want to handle timed-out transactions, whether they want to deliver the goods/services or not. However, it is recommended that for timed-out transactions, goods/services should not be delivered. In case the amount is received online, then customer should be refunded using NEFT/IMPS/Refund/Pay API.

• Success Response from SDK: In case of transactions which were successful, but the user is claiming that the beneficiary has not yet received the funds, then Raise Dispute API has to be used by sending the code “U010 (for P2P transactions)”
• Failed Response from SDK: In case of transactions which were failed, but the user is claiming that the remitter has not been refunded yet, and then Raise Dispute API has to be used by sending the code “U005 (for P2P transactions) and U009 (for P2M transactions)”