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: 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 made by the customer. In such cases, we refund the transaction.

  • Missing/Incorrect OrderID: There 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 bill: Whenever 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. 


  • Initiated: This is when the refund request has been intimated to the banking partner and begins processing 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.


  • Pending: This status is implied in case the refunds have not been processed due to a low balance or the merchant not transacting for a while. There are 2 reasons to elaborate on this status:


  • Insufficient funds: This status reason would appear if a merchant creates refunds and there is a low balance to refund all or any of the requests made. The merchant should have sufficient or more balance to avoid refunds getting delayed due to insufficient funds. 

Example: Merchant X created 10 refunds for Rs.1000, and only 8 got refunded since the clearing balance was insufficient for the refunds to get processed, consisting of 10, 100 rupee refund requests each, and the total settlement amount for the day is 850 rupees. These would be refunded once the merchant has sufficient balance. The first 8 refunds that were registered will be processed in the current settlement cycle. 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.


  • No Active Transactions: This status implies that when a merchant has not had transactions for a while and raises a refund, active transactions are required for this to move to initiated status. 

Example: Merchant Y has not transacted for 1 or more days and has created Refund requests. Since there are no active transactions, the refunds would remain in Pending status with the reason No Active Transactions


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.


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

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