Setu provides access to refund functionality for UPI payments. Refunds can either be auto-initiated by Setu for pre-defined scenarios or 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 being unable to reconcile the transaction even though the payment was 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, all subsequent payments (except the first) are refunded to the source account. Whether the first payment was a failure or a success doesn't matter.
  • Expired bill: Whenever a link is created with an expiry date and payment is made after that time, the transaction will automatically be refunded.