TABLE OF CONTENTS



Setu provides access to refund functionality for UPI payments. Refunds can either be auto-initiated by Setu for pre-defined scenarios or can be voluntarily initiated by the merchant using APIs and through The Bridge


 Types of Refunds:

  • Merchant initiated refunds : Merchant can request a refund for one or more transactions. Reasons could include the return of goods and services and more.

  • Third-party verification (TPV) refunds : If the account used by the customer for making payment does not match what the merchant is expecting (for example a KYC specific source account in the case of financial services merchants), a refund can be initiated. TPV is enabled by Setu only upon request from the merchant.

  • Setu initiated refunds : Setu automatically refunds a transaction in cases where the transaction is not properly routed through the UPI eco-system and cannot be reconciled. Setu also initiates refunds automatically when amount exactness validation rules set for the payment link fail.


Various scenarios for Setu initiated refunds.

  • Missed notification from the bank: This occurs in case the bank doesn’t respond with a positive credit alert notification to Setu’s systems for a given transaction. Since this will fail reconciliation checks, the amount is refunded

  • Missing/Incorrect orderID: When there is an order ID mismatch for a payment made versus it’s designated orderID parameter for a given transaction 


Setu also initiates refunds in these situations—

  • Duplicate payment for the same bill: If more than one payment is detected for a given platformBillID, then to prevent multiple settlements, all subsequent payments (except the first) are refunded to the source account. It doesn’t matter whether the first payment was a failure or a success.

  • Expired bill: Whenever a platform bill Id has a given expiry date that is in the past, all payments tied to that platform bill Id will be refunded to the source account if paid past the expiry date. 


Setu initiated refunds occur on payments with the status `Payment Failed`. There are a few reasons a payment moves to this status: 


 Payment can fail for multiple reasons as explained below:

Reason

When does this happen?

Amount validation failed

If the payment amount does not satisfy the amountExactness condition specified during payment link creation.

The payment link has expired

If the payment was made after the expiryDate set during payment link creation.

Missed credit alert

In rare scenarios, the bank system does not send us a credit alert in real-time. But when we process all transactions in the following settlement cycle, and if the delayed processing configuration is disabled for the merchant, the bill is marked as PAYMENT_FAILED, and notifications are sent.

Payment address inactive

When a customer makes multiple payments using the same payment link, only the first one is honored. For all others, a failure notification is sent.

TPV check failed

If TPV check by Setu is enabled and account validation fails. Read more about TPV here.

For Setu to carry out TPV, merchant has to provide the ifsc and the account number when creating the payment link
.



 What are the different types of refund statuses?

  • Created : This is when the merchant initiates a refund request via APIs or through the The Bridge (Setu dashboard ). The refund or its processing has not taken place at this point. 

  • Initiated: This is when the refund request has been intimated to the banking partner and begins processing of the refund. The status remains in Initiated once a refund request is placed. 


  • Failed: This happens when the refund has failed for any given reason. (For example, a merchant does not have sufficient funds to make the refund transaction)


  • Marked for Refund- This status indicates that we have received money from the bank for the underlying transaction, but the refund is yet to be reconciled with the settlement calculation for the day.


  • Queued for Refund- This status indicates that we will be initiating the refund as part of the current clearing cycle. Clearing Cycle refers to T+1 working day.


  • Rejected- This status indicates that we have rejected the refund request (which, as of today (July 12, 2021), happens only when the refund was processed outside the system and asked by the settlement team to mark as so.


Are partial refunds possible?

  • Yes, partial refunds are possible. 


How to set up refunds on our accounts?

  • Refunds will be available for all merchants by default. You can integrate with the Refund API mentioned here


What is the timeline for a refund to be credited to the customers' accounts?

  • The timeline for a refund to be credited to a customer's bank account is 1-9 working days.


What happens if the sum total of the refund amount is greater than the settlement amount for a particular day? 

  • Let's work with an example. If the total refund amount for a day is 1000 rupees (consisting of ten 100 rupee refund requests each), and the total settlement amount for the day is 850 rupees. Then, The first 8 refunds that were registered will be processed in the current settlement cycle and a callback notification will be sent to the merchant with the payload containing the first 8 refunds in the `initiated` block and the remaining in the `pending` block.


If the merchant does not reach out to us for any manual processing after this, then these refunds will be attempted to be processed during the next clearing cycle.

If the merchant does reach out to process one of these refunds manually, outside the system, then we have a process in place with the settlement team to manually mark the status of these refunds processed outside the system as `REJECTED` in our DB.