8. Refunds

Refunds are essential part of online business… we cancel tickets, we return product. I think refunds played great role in growth of e-commerce as they installed confidence in users.

Refunds can be marked only against successful transactions. Merchant can either mark full or partial refunds.

Full Refund: Entire transaction amount is refunded

Partial Refund: Only part of transaction amount is refunded. It is possible that merchant can mark multiple partial refunds against the same transaction.

Merchant can mark refund multiple ways:

• Call refund API
• Mark refund in aggregator’s admin module
• File upload (mark multiple refunds in one go) in admin module

Refund processing has few checks:

1. Refund should be marked for successful transactions

2. Refund amount or sum of partial refunds should not be more than transaction amount

Example: Transaction Amount = 1000 then 1st partial refund = 500, 2nd Partial Refund = 300 and if merchant marks another refund for 300 then 3rd refund should fail

3. Duplicate refund should not be processes (cases where refund amount is less than transaction amount). To achieve this every refund done should have unique id with status checks

Example: Transaction Amount = 1000 then merchant marks refund for 500 and by mistake marks refund again for 500. The second (duplicate) one should be failed

4. Merchant should have sufficient settlement amount to adjust the refund amount

In general, refunds are cumbersome and costly… Read on to know why?

A. Refund Flow

During refund, the money traces back to its source through series of identifiers that were created during transaction leg and return to customer’s card/account.

Once merchant marks refund then aggregator processes it on next working day.

Note: Most of the aggregators do not support marking of refund through API/dashboard for the transaction that is older than 6 months. For such cases, merchant has communicate with aggregator directly

Refund Status:

Once aggregator processes the refunds then status will be ‘success’ or ‘failed’

But refund status success at aggregator end doesn’t mean the money has reached the customer but the process of refunds has just started successfully.

TAT:

As the money hops across different accounts so it takes time to reach the customer’s card or account. Typically 3–5 working days for card and 2–3 working days for other modes

Tracking:

A anxious customer wish to know the status of the refund. For such cases, merchant can share ARN (for cards, that is generated when acquiring bank processes refunds successfully) or bank reference id (for NB). These reference numbers can be used by customer to check the status with their respective banks

Can refunds be done faster?

IMPS, NEFT APIs can be used to push money to card/account. There are other services such as Visa Direct and MasterCard Money Send to push money to cards.

To implement these methods, one would need card/account number, involves cost and leaves an open room to raise chargeback.

So many merchants found simpler way, move the refund to its own closed loop wallet so it is faster and also, customer is forced to transact with same merchant.(let’s call it ‘stickiness’)

B. So refunds are cumbersome… but why costly?

Aggregator doesn’t charge any fee to process refunds. But merchant still loses money on these refunds

Example: Merchant is in upfront deduction model. Transaction Amount Rs.100, PG Charge: 1% so Settlement Amount = Rs.98.82

But merchant needs to return Rs.100.

That leaves Rs.1.18 hole in merchant’s account (Without considering TDS deduction)

Does merchant lose money in surcharge and invoice model?

In case of invoicing model, merchant loses money but in case of surcharge model, customer loses money

Example: In surcharge model, Transaction Amount = 100, PG Charge 1% so total amount will be 101.18. But merchant can mark only 100 as refund (any amount higher will be more than transaction amount) so customer receives only 100 and surcharge collected won’t be refunded (majority cases)

Interesting aspect of refunds, when aggregator loses money !!!

We spoke about auto-refunds in earlier chapter where merchant will ask aggregator to mark the transaction refund if transaction status is not finite within stipulated time period.

Let us take that airline company which wants to auto-refund configured post 15mins. Transaction status became successful after 30minsm but due to auto-refund configuration, aggregator marked it for refund.

But from acquiring bank’s view, the transaction was successful it will deduct charges. As there is no settlement so the aggregator cannot recover it from merchant/user. In this case the aggregator loses money. (This happens because acquiring bank to nett-settlement to aggregator)

Similar thing doesn’t apply for net-banking transaction as aggregators receives gross settlements. This arrangement not only has impact on auto-refund but help merchant to earn interest <<More on this in revenue models>>

Next Topic: Chargeback