Customer refund process flowchart (request to money returned)

What the customer refund process flowchart (request to money returned) process is

A customer refund process is the money side of putting something right. A customer asks for their money back, someone decides whether the request meets the policy, someone else confirms the original payment is real and has not already been refunded, the refund is issued through the payment provider, the ledger is corrected, and the customer is told when to expect the funds. Five parties touch it and only the customer sees the whole thing, which is why refunds usually look fast from the inside and slow from the outside.

This is not the returns process, and the distinction matters when you are choosing which chart to work from. Returns settle where the goods end up: an RMA is issued, the parcel is booked in, the item is inspected and graded, and it is restocked, repaired or scrapped. That process hands over to this one at the moment a refund becomes the agreed remedy. This chart starts from the refund request itself and follows only the money, which is also why it applies where nothing is coming back at all: cancelled subscriptions, unused services, duplicate charges and digital purchases. It is not the complaint process either. A complaint asks whether the organisation got something wrong; a refund request asks for a specific sum returned.

The chart maps five lanes, Customer, Customer service, Finance, Manager and Payment provider, across five phases from request to confirmation and closure. It includes the three branches that refund procedures usually leave undocumented: an exception route where a request outside the policy goes to a manager for goodwill approval rather than being refused at the desk, a full-or-partial decision where the deduction is agreed with the customer before the refund is issued, and a chargeback branch, because a request from a customer who has already disputed the payment with their bank must not be refunded on the normal route.

What this flowchart covers

In this template

• Five lanes, Customer, Customer service, Finance, Manager and Payment provider, laid out across five phases: request, eligibility check, approval, refund payment, and confirmation and closure.
• Intake in the Customer service lane: the request is logged with a reason code from a fixed list, then a "Fraud flag or chargeback?" gate diverts flagged cases before any money moves.
• A policy and window check feeding an "Eligible under refund policy?" decision, whose exception branch sends the request to a manager to review and either approve a goodwill refund or decline it with a stated reason.
• Verification of the original payment in the Finance lane, which both the eligible route and the approved goodwill route pass through, so nothing is refunded against a payment that has not settled or has already been refunded once.
• A "Full or partial refund?" decision, where the partial branch goes back to customer service to agree the deduction with the customer before the refund is issued.
• Execution and closure: the refund is issued through the provider back to the original payment method, posted to the ledger and confirmed to the customer with an expected date, while the chargeback branch holds the refund, submits evidence and ends at a "Chargeback upheld?" outcome, with a withdrawn dispute rejoining the eligibility check.

When to use this template

• You are writing or reworking a refund policy and need to see who performs each step and who is authorised to approve an exception, rather than only what the policy promises.
• Refunds are taking too long and you need to separate the part you control, the decision and the issue, from the part the customer's bank controls, the settlement.
• Goodwill refunds are being given inconsistently, or agents are approving amounts against a limit nobody has written down.
• Chargebacks are rising and the same team handles both refunds and disputes with no rule about which takes precedence.
• You are configuring a helpdesk, billing or payment tool and want the customer service, finance and provider split agreed before anything is built.

How it works

1. Set the tests behind the eligibility decision

   Replace "Eligible under refund policy?" with your real tests: which date starts the refund window, purchase, delivery or end of service; the excluded items or plan types; and the evidence required. Record which version of the policy was applied to each case. Note the exception explicitly, because consumer cancellation rules and rights over faulty goods sit above your own policy and are not overridden by a shorter window.

2. Rename the lanes to your real roles

   Map Customer service, Finance and Manager onto the functions you actually have, and merge lanes rather than leaving an empty one if a single team both decides and pays. Keep the Payment provider lane even when the refund is one API call: it is a handover you do not control, and it is where the customer's waiting time is spent.

3. Set goodwill authority and limits

   Against "Approve goodwill refund?", record who may approve a refund outside policy and up to what value, and require a reason to be captured on the case. Then report the goodwill rate by product and by reason code. A rising goodwill rate is usually a signal that the written policy no longer matches what the business is prepared to do.

4. Define what a partial refund may deduct

   List the deductions that are allowed, for example service already consumed, outbound delivery or a restocking charge, and say who may apply each one. Decide whether the customer has to agree the amount before the refund is issued, as this chart assumes, or is told afterwards. Partial refunds generate most refund disputes, so the reasoning belongs on the record.

5. Point the ledger step at real accounts

   Say which account the refund posts against, how any tax is adjusted, and whether a credit note is raised, since in many jurisdictions the tax adjustment needs a document rather than a journal alone. Add how the provider's settlement report is reconciled, and note that provider fees on the original transaction are often not returned with the refund.

6. Walk the chargeback branch with your provider

   Confirm your provider's dispute process: what evidence is accepted, who assembles it, and the deadline you are given to respond. Write down the rule the chart enforces, that a payment already in dispute is held rather than refunded in parallel, and agree what happens to the case when the dispute is withdrawn and the request rejoins the normal route.

Frequently asked questions

What is the difference between a refund process and a returns process?

A returns process settles the goods: it issues an RMA, books the parcel in, inspects and grades the item, and decides whether it is restocked, repaired or scrapped. A refund process settles the money: eligibility, approval, payment verification, the refund itself, the ledger entry and the confirmation to the customer. They meet at one point, where a return is assessed and a refund becomes the agreed remedy. Keeping them as separate charts is deliberate, because plenty of refunds have no goods leg at all, such as cancelled subscriptions, unused services, duplicate charges and digital purchases.

Should a refund always go back to the original payment method?

As a default, yes, and this chart is drawn that way. Refunding to the original card or account is what card scheme rules generally expect, it is what consumer rules assume unless the customer agrees otherwise, and it removes an obvious fraud route, since redirecting a refund to a different destination is a well-known way to extract funds from a stolen card. Genuine exceptions exist, mainly closed or expired accounts, and they should be handled as a named exception with identity checks recorded, not as a favour done at the desk.

What should happen when the customer has already raised a chargeback?

Hold the refund. Do not refund and defend the dispute at the same time, or you can end up out both the refund and the disputed amount. Many providers will not permit a refund on a payment while a dispute is open, and where a refund can still be issued it does not automatically withdraw the chargeback. Answer through the provider's dispute process with the evidence it asks for and let the outcome settle. In this chart, an upheld chargeback closes the case with the funds returned through the scheme, and a withdrawn one rejoins the normal eligibility check.

Who should decide a partial refund rather than a full one?

In this chart the Finance lane owns the "Full or partial refund?" decision and customer service agrees the partial amount with the customer before it is issued, which keeps the calculation and the conversation with the person best placed to do each. What makes it work is a written list of permitted deductions with an owner for each, rather than a judgement made per case. Where the customer is entitled to a refund by law, for example on a faulty item or a cancellation within a statutory window, your ability to deduct is limited, so check the entitlement before treating the amount as negotiable.

How long should a customer refund take?

Split the answer in two, because only half of it is yours. The part you control runs from request to the refund being issued, and that is where a target belongs, for example a decision within a set number of working days and issue on the same day as approval. The part you do not control is settlement, the time the funds take to appear on the customer's statement, which is set by the issuer and typically runs to several working days. Statutory refund deadlines may apply to cancellations in your market, so check the rules that cover you. Using this template does not make a process compliant; it gives you a documented process description that you can hold under version control with a review and approval record.