Case 1: Refund issued by an online business on their customer’s request
The Situation: The customer transacts successfully on a website for purchase of certain goods or services. Due to some reason, like delivery of good not being made or quality of services being poor, the customer requests a refund from the business.
What Happens Next?: The online business now makes a refund request via their payment gateway. The payment gateway conveys this information to their acquiring bank (the bank with which they have an account) via APIs.
This acquiring bank has to communicate with the issuing bank (the bank in which the customer account/card is held) which was used for the payment and raise a refund request. Ideally, the refund request is accepted, filed and then processed by the issuing bank. On completion of this process, refunds are reflected in the customer’s account/card balance.
Why refunds take 5-10 days?: A refund thus involves an exchange of information between 3-4 different parties. Each of these parties have their own mechanisms to file the refund request, map it to their respective payments that were originally made and then process it forward.
Many of these processes in the banking ecosystem are not fully automated and require manual oversight. Given the number of parties involved and the variance in their processes to handle refunds, it takes 5-10 days for them to be credited back to the customer account.
When does it extend beyond 5-10 days?: There are about 5 major payment gateways working in the country, 5-6 major acquiring banks who help process payments and about 60 banks which allow for functionality of payments via netbanking or their card network.
Each refund has to go through at least these three parties and flow of communication for each refund varies as per the combination of these 3 parties. Sometimes a refund request gets dropped in the process due to system/network failures. Whenever this happens, the refund may stay in limbo, until the refund request is initiated again.
Case 2: Transaction fails but money is still deducted
The situation: A customer tries to complete a payment on a website but the payment shows up as failed. However, the customer is notified by his/her bank that money has been deducted already.
How are payments processed?: An online payment involves several steps involving multiple parties such as:
- 1.The online website the customer is transacting on,
- 2.The payment gateway helping collect sensitive details (like OTP or IPIN) and processing payments,
- 3.An acquiring bank which works with the payment gateway and helps route the payment and finally,
- 4.The customer’s own bank, popularly known as issuing bank
For the purpose of understanding the impact of failed payments on refunds, we will only look at the most relevant steps here. Once the 2FA (2-factor authentication) is complete a payment request is made to the issuing bank which accepts the payment request and debits the required amount from the customer’s account balance.
The issuing bank then confirms to the acquiring bank on the status of the payment (if it’s successful). This is then communicated to the end customer via the payment gateway. Here is the process for the communication of a successful payment once the money has been deducted from customer’s account.
Payment successful notification after customer A/C debit
How do payments fail? Why are refunds required?
If the communication fails at any step after the customer account has been charged, the payment fails and the customer has a legitimate case for seeking a refund.
There can be various reasons for either of steps 1,2 or 3 failing but the most prominent one in our experience is network connectivity. Until all steps are complete, the customer’s device needs to be connected to the internet for the customer to be notified.
Also, payments can show up as failed if the payment status is not updated either (Step 1) by issuing banks or the acquiring bank (Step 2) despite being collected. The payment gateway does not receive any notification in these cases just as the customers and the online business themselves.
Payments work on several technical infrastructures and all of them are not as optimized to solve such issues. As the classic adage goes – any chain is as strong as its weakest link. This could not be more true for online payments.
How does Trano handle refunds?
A payment gateway’s job doesn’t stop if they do not receive a successful payment status from the banks. There are a couple of things that it can do to retrieve a failed payment and check again for updates regarding its status.
Our Payment Gateway keeps polling acquiring banks periodically, to see if a payment that was called out as “failed” before has been updated to successful. If it has, we inform the business where the transaction was done and give them an option to collect the payment then. One of 2 things happen here –
- The online business accepts the change in payments status, agrees to collect the payment and provides the service/good that was promised earlier to the customer.
- The online business decides not to collect the payment as it is no longer in position to service the customer at the agreed terms (could be time of delivery, cost of purchase, inventory issues, etc). In this case, they have to refund the payment to the customer who gets the money in their account in a period of 5-10 working days.
At Trano, we have developed these monitoring systems so that the refunds are handled without impacting the end customers in such circumstances. In instances where payment/refund can still not tracked, we attempt to resolve issues further with the banks via manual intervention.
In case of payments failure due to a breakdown in communication between a payment gateway and the online website, a good payment gateway should have a fallback mechanism for reconciling payments for both parties and updating their correct status in near real-time.
At Trano, we encourage our client businesses to receive the status of each payment through both a website level integration and also on their servers through webhooks.
When a transaction is marked as failed, we give these online businesses an option to check via our Webhooks API if the transaction has genuinely failed or if its a false alarm. If found that the transaction is successful, the online business has the option to carry out the transaction as normal.
Our limitations as a Payment Gateway
The refunds problem is deep and reconciliation across all payment networks is a challenge. For a payment to be complete it has to go through several stages and becomes difficult to track. Say you are transacting on a website and what you see as a customer is an Order ID.
This Order ID is now communicated to a payment gateway which assigns a payment ID of its own and calls it Payment ID. The acquiring bank receives this payment ID from the payment gateway and forwards it to the issuing bank with its own term Transaction ID or yet another payment ID.
You can see where this is going. The same structure repeats itself when a refund request is made and a refund ID is generated by the merchant or the payments platform. As there is no universal tracking mechanism across the system, there are gaps through which the status of payments or refunds can sometimes be temporarily lost.
Another classic case is when the promised service/good has not been delivered by the online business to the customer, as promised. In this case, the payment gateway is also not in a position to influence the day to day workings of an online business. The best way to proceed is to communicate with the merchant themselves.
Although, in the case of fraud or repetitive failure to provide goods or services as promised, Trano does retain the right to intervene and assist end customers.
Keeping calm and setting realistic expectations
The entire money movement in online payments is via escrow accounts, which are jointly monitored by payment gateways and acquiring banks, which means payment gateways cannot make earnings from money they hold or move on behalf of their customers.
If it were solely up to us we’d have your refund processed instantly. But, refunds usually depend on the acquiring bank and issuing banks for processing the balance back into your account. The amount of time taken to process the refunds also depends on the mode of payment used to make the transaction.
The standard is 5-7 working days, something most of us are familiar with. Each mode of payment, however, has a different time frame for refunds which we have provided below. If it exceeds the following, it definitely merits a further inquiry.
|Credit / Debit Cards||NetBanking||Wallets||UPI|
|Min. refund time||3 days||2 days||Instant||2 days|
|Max. refund time||10 days||10 days||3 days||7 days|
Days here represents business days which means Saturdays, Sundays and bank holidays are excluded.
Keep in mind that refunds are always credited back to the source mode of payment. That means if you’ve made the transaction through a digital wallet your money cannot be credited to your bank account.
Imagine if your refund has been initiated but your account still hasn’t been credited even after 7 days! Don’t worry. Your money is still safe. There are slight chances that the refund processing has failed and will have to be reinitiated.
At Trano, we are truly devoted to providing the best payment experience not just for the businesses who work with us, but also for their end customers. We truly believe that if online payments has to replace cash, then it has to provide the same ease of use.
Unfortunately, we still see instances in which refunds are not issued on time because of the system failing overall, but the payments infrastructure in India is changing rapidly. The next 2-3 years will see millions of first-time internet users in India and it is our ambition to provide them a seamless online payments experience.