Refund process flowchart template
Refund process flowchart for eligibility, amount approval, idempotent submission, timeout status inquiry, duplicate prevention, controlled retry, settlement and reconciliation.
What the refund process flowchart process is
A refund process has to connect a customer-facing decision with the payment event that follows it. This template begins when a customer asks for a refund or the merchant initiates one, then records the reason, requested amount and transaction reference before attempting a match. Once the original transaction is found, merchant support reviews its status and the current refund policy. The chart keeps policy eligibility, exception review and amount calculation visible as separate steps so a team can explain why a refund proceeded, why it did not, and whether the amount represents the full transaction or only eligible items and adjustments.
Approval is conditional rather than universal. A routine amount can move directly to a recorded decision, while an amount or exception that needs another reviewer enters the Refund approver lane. Submission uses a stable refund reference and has three distinct results: accepted, definitively failed, or timeout and unknown. An unknown result is never treated as failure. Operations retrieves status with the original refund and transaction references to determine whether the refund is pending, completed, absent, failed or still unresolved.
A definitively failed or confirmed-absent refund can be corrected, but it cannot be resubmitted until the duplicate check proves that no refund exists and a controlled retry is safe. Accepted and pending refunds move to communication and settlement tracking; delayed outcomes return to status inquiry rather than submission. Completed refunds reconcile to settlement and the ledger, while an unresolved status is held for specialist review without another retry. Provider statuses, idempotency behavior and timing vary, so the configured API contract and incident runbook must supply the actual evidence and controls.
What this flowchart covers
In this template
- Customer request or merchant initiation, transaction reference capture, lookup and correction of unmatched details
- Policy eligibility review, exception handling and an explicit route for cases that remain unresolved
- Full versus partial amount calculation, conditional approval and a durable record of the decision basis
- Accepted, definitively failed, and timeout or unknown submission states, with original-reference status inquiry
- Duplicate prevention before controlled retry, followed by settlement tracking, reconciliation or unresolved-status review
When to use this template
- Customer support, payments and finance use different definitions of when a refund is complete
- Teams need to distinguish policy approval from successful submission and eventual settlement
- Partial refunds or exceptions are calculated inconsistently or reach approvers without enough context
- Failed, delayed or unknown refunds are retried before their original status and duplicate risk are resolved
- A merchant is defining refund ownership during payment client onboarding or an API implementation
How it works
Replace the policy gate with your rules
Define the transaction states, products, time windows and evidence that affect eligibility in your business. Keep exceptions separate from routine eligibility, name who may review them, and avoid presenting a provider-specific rule as if it applied to every payment route.
Define full and partial calculations
Document which items and adjustments can be refunded and how prior credits or refunds affect the remaining amount. Use the same calculation record in support, approval and finance so the value is not reinterpreted at each handoff.
Set conditional approval ownership
State which amounts or exception types need an additional approval and which role can give it. If routine refunds do not require approval, keep the direct branch and record the policy basis rather than adding a ceremonial review to every case.
Map submission status resolution
Map accepted, definitively failed, completed, pending and unknown provider states. Define how operations retrieves status with the original refund and transaction references, and never translate a timeout into a failed submission or a new request.
Guard every retry
Before resubmission, require evidence that the original refund is absent or definitively failed, run the duplicate check, and confirm the retry is idempotent and controlled. Test accepted, completed, pending and still-unknown outcomes through reconciliation or specialist review.
Frequently asked questions
What are the main steps in a refund process?
Record and match the original transaction, review eligibility, calculate the amount, obtain any required approval, and assign a stable refund reference. Submit once and distinguish accepted, definitively failed, and timeout or unknown states. Query unknown or delayed status with the original refund and transaction references. Retry only after confirming absence, preventing a duplicate and proving the controlled retry safe. Track accepted refunds to settlement and reconcile completion.
Is an accepted refund the same as a settled refund?
Not necessarily. Acceptance usually means the submitted request passed the next system or provider gate, while settlement or completion is confirmed later from the applicable payment and financial records. The exact statuses and timing depend on the route in use. Keeping those points separate prevents a customer-facing confirmation from being treated as proof that finance has reconciled the outcome.
When should a refund need approval?
Use the authority model and policy that apply to the merchant. Approval may be appropriate for certain amounts, exceptions or risk conditions, but it should not be shown as a universal payment rule. The chart therefore has both a direct path and an approval path. Define the threshold, approver, evidence and substitute owner during payment client onboarding or procedure design.
What should happen after a refund submission timeout?
Treat the refund as unknown, retain the original refund and transaction references, and use the supported status inquiry before any retry. If the provider confirms acceptance or completion, continue tracking or reconcile it. If it confirms failure or absence, correct the request and run duplicate and idempotency controls before a controlled retry. If status remains unknown, hold resubmission and route the case for investigation.
Where this process fits
In most operations this process hands off to Payment reconciliation process flowchart (records to settlement).
Comes after
- Payment reconciliation process flowchart (records to settlement) — Payment reconciliation process template for complete source capture, transaction and settlement matching, difference classification, controlled correction, rematch and audit evidence.