A refund can be authorized in one system, initiated in another and settled later by a payment provider. Reconciliation prevents a successful button click from being treated as proof that the customer, order ledger and finance records all agree.
Define the refund lifecycle
Use distinct states: requested, approved, submitted, acknowledged, settled, failed, reversed and manually reviewed. The exact states depend on the channel and provider. Store the provider or channel reference, currency, amount, tax/shipping treatment, reason and timestamps.
Tie the refund to the original order and line where possible. Returns, appeasements, cancellations and shipping adjustments may use different accounting and inventory paths even when the customer sees a credit.
Reconcile in layers
- Authorization: Was the amount and reason approved by someone with the right authority?
- Submission: Did the channel or payment provider accept a unique request?
- Customer record: Does the order show the correct refunded amount without duplication?
- Settlement: Does the provider statement or channel payout reflect the credit and related fees?
- Return/inventory: If goods were expected, is their physical status recorded independently?
Do not delay every customer refund until warehouse receipt if policy does not require it; equally, do not mark an item restocked because a refund settled.
Detect duplicates and timing gaps
Use the provider’s unique refund identifier and an internal idempotency key where supported. Flag two credits against the same order line and amount, but review before declaring them duplicates: a split refund may be legitimate.
Hypothetical example: a $120 order receives an $80 product refund and later a $10 shipping adjustment. A simplistic “two refunds” alert creates noise. The useful control compares reason, line allocation and total refundable balance. Conversely, two $80 product credits with different references require investigation before any new submission.
Separate submitted-but-unsettled from failed. Payment timing varies by method and provider; customer communication should use the provider’s current guidance, not a guaranteed arrival date. Record the access date for changing rules.
Recover safely
If an API call times out, query by the original idempotency key or order before retrying. If the channel and internal ledger disagree, preserve both records, pause further automated refunding for that case and assign finance/channel ownership. Corrections should use supported adjustment paths, not deletion of audit history.
Review daily aged exceptions and reconcile payouts on the finance cadence. Measures may include settlement match rate, duplicate-prevention alerts, failed submissions and time from approval to acknowledgment, each with stated exclusions and time basis.
Pair this process with the returns triage workflow, returns exception playbook, and returns and CX hub. 1Commerce can coordinate configured order, return and customer-experience workflows; payment and marketplace behavior depends on provider and scope.