Payment flows get attention because revenue depends on them. Refunds get a button and a hope. The result in most Indian products is that a refund is initiated, the customer sees nothing for several days, contacts support twice, and support cannot say where the money is — because the system recorded that a refund was requested and nothing about what happened next.
The core design point is that a refund is a process with its own state, not a flag on a payment. Requested, submitted to the provider, accepted by the provider, settled to the customer's bank, and visible on their statement are five distinct events separated by days. A customer asking where their money is wants to know which of those has happened, and a product that cannot say produces a support conversation that nobody can conclude.
Set expectations in the interface using the provider's actual timelines rather than a vague soon. Refund timing in India varies by instrument — card refunds move on a different cycle from UPI, and both depend on the receiving bank — so the honest message names a range and the method. Products that tell customers five to seven working days, and then show the status changing within that window, generate a fraction of the tickets of products that say nothing.
Partial refunds and multi-instrument payments are where the data model usually breaks. An order paid partly by wallet and partly by card, refunded partially, against an invoice that must remain GST-correct, is a genuinely awkward object. Getting this right means modelling the refund against specific payment components rather than against the order total, and it is very much easier to design in than to retrofit once a year of transactions exists.
Chargebacks are a different mechanism and need separate handling. The customer disputes with their bank rather than with you, the funds are pulled back, and you have a window to respond with evidence. That means your systems must be able to produce, quickly, proof of what was ordered, when it was delivered, what the customer agreed to, and any communication about it. Firms that cannot assemble that in a day lose disputes they should win, and repeated losses affect how their processor treats them.
Watch the ratios as operational metrics rather than accounting ones. Refund rate by product and by reason, time from request to settlement, chargeback rate, and win rate on disputes. A rising refund rate on one product line is product feedback arriving through the finance system, and it is usually noticed there months before anyone in product hears about it — which is a reporting failure rather than a payments one.
