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.
A refund can take 1 to 9 business days to reflect in the customer's account, once it is initiated. Refunds can be initiated within 170 days from the date of transaction.
Refunds are initiated in batch, along with bill settlements done to the merchant. If the amount to be refunded is already settled to the merchant in a previous settlement, it is adjusted in the present settlement.
Refunds are of three types, based on the reason for initiation—
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.
Merchant initiated refunds — Merchant can request for a refund for one or more transactions. Reasons could include 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, a refund can be initiated. TPV is enabled by Setu only upon request from the merchant.
When a transaction is processed through the UPI eco-system, data flows through many points. Any errors in this path can result in a situation where Setu cannot reconcile the transaction. Hence, Setu automatically refunds these transactions to the customer's source VPA. Some of these situations include—
For transactions that come under Setu initiated refunds, the bill fulfillment notification for that particular transaction will have PAYMENT_FAILED as the status.
Setu will later notify the merchant about the refund initiation, in the next settlement cycle. See refund notifications.
In cases where the orderID is missing or invalid, Setu cannot identify the merchant and hence will not provide any refund notification to the merchant. However, the refund will still be processed to the customer's VPA.
Setu initiated refunds are credited to the customer's source VPA in 1 to 9 business days — no intervention from the merchant is needed.
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 are awaiting to be reconciled or have completed reconciliation, yet not processed due to one of the following reasons:
Insufficient funds: Refunds requested by a merchant are adjusted from the settlement amount to the merchant's account. But if the amount for a particular refund request cannot be adjusted due to insufficient settlement amount, the refund remains in a Pending state.
Example: If the total settlement amount for the day for Merchant X is ₹850 and the merchant has created 10 refunds of ₹100 each totalling ₹1000 in the same duration, only the first 8 will get refunded and move to an initiated state. The callback notification sent to the merchant will contain the first 8 refunds in the initiated block and the remaining in the pending block.
No Active Transactions: A requested refund will remain in a Pending state if there are no active transactions (and thus settlements to the merchant's account) from which the refund amount can be deducted and sent back to the customer.
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
Rejected: This status is used only in the exceptional scenario where a merchant wants a previously requested refund not to be processed and requests the Setu team to reject the request. This request is currently to be raised offline.