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: The 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 the amount exactness validation rules set for the payment link fail.

Various scenarios for Setu initiated refunds.

  • Missed notification from the bank: Occasionally, our partner bank does not send us the platform bill ID correctly in their notification to Setu, resulting in us not being able to reconcile the transaction even though the payment is successfully done by the customer. In such cases, we refund the transaction.

  • Missing/Incorrect OrderIDThere are scenarios when the partner bank does not send us a payment notification in real-time. We end up reconciling such transactions the following day when we get an MIS file from the bank and refund them. But if the merchant wishes, we allow a configuration to process these transactions & settle instead as well.
  • Amount exactness validation failure: An amount exactness validation is when a given payment has a validation error - for example, payment has an exactness condition of ≥Rs 500 but the payment is for Rs. 400. In such cases it doesn’t meet the amount exactness validation and is refunded to the source account.

  • Duplicate payment for the same bill: Setu’s UPI DeepLinks supports only one payment per generated DeepLink. But if more than one payment is detected for a given link,  then 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 billWhenever a link is created with an expiry date and payment is made after that time, the transaction will automatically be refunded.

 What are the different types of refund statuses?

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

  • 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 are able to adjust the refund amount against the settlement amount.

  • Initiated: This is when the refund request has been intimated to the banking partner and begins processing of the refund. This is the terminal status of a refund, as NPCI does not share information about when a refund hits the customer’s bank account.

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-7 working days.

How do Merchant-Initiated refunds work?

  • Refunds can be initiated from the merchant side either via The Bridge or by integrating directly with the API. Refunds for UPI payments will always be adjusted against the total settlement amount to merchants’ settlement accounts on a given day.

Settlements from Setu are always done in batches on T+1 day for UPI, with the batches essentially being a combination of Merchant ID + Settlement Account. 

So, as an example, if 100 transactions of 10 rupees were made for Merchant A with settlement account S, a single settlement of 1000 rupees (minus Setu’s charges) would be made to account S.

Now, when the merchant initiates refunds, the refund amount will be adjusted against this batch amount. As an example, if the merchant wishes to refund 2 transactions (from the current day or from the past) worth 200 rupees each, then 400 rupees will be deducted from the 1000 rupee payout batch, and only  600 rupees will be settled to the merchant’s settlement account and the refunds worth 400 rupees will be initiated via our partner bank.

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.

Which roles have access to initiate refunds on the Bridge Dashboard?

  • Maintainer, developer & admin level access holders can initiate refunds on the Bridge Dashboard.