Gift cards and store credit can look simple to customers but often depend on several connected records: the original issue, later redemptions, refunds, manual adjustments and the balance shown by the storefront or back-office system. When those records disagree, the fastest-looking fix is often to add credit manually. That can turn an unclear balance into a genuine duplicate-credit problem. A small e-commerce team needs a process that reconstructs what happened before changing the customer's available value.
Start with the specific card or credit account
Use the system's appropriate identifier and the customer's relevant order context rather than relying on a name or email search alone. The objective is to isolate one balance history and avoid mixing transactions from separate cards, vouchers or customer accounts.
Reconstruct the balance from recorded events
Review the events that should have changed the balance: initial issue, redemption, refund, cancellation, expiry where applicable under the business's established terms, and any authorised manual adjustment. A displayed balance is useful evidence, but the event history helps explain whether that figure is complete or whether a transaction failed to post correctly.
Separate pending activity from completed activity
A customer may have an order in progress that reserved value without producing the final balance state yet. Check whether an incomplete checkout, cancelled order or delayed integration is still affecting the apparent balance. Staff should avoid issuing replacement credit while an original transaction is still capable of completing or reversing.
Treat manual adjustments as controlled financial actions
If the evidence shows that a manual correction is genuinely required, record the reason, amount and authorising basis through the business's normal process. A correction should not simply overwrite history. Future staff need to see that the adjustment was deliberate and understand which discrepancy it resolved.
Keep customer communication factual
Tell the customer what has been verified and what remains under investigation without making unsupported promises about the outcome. If an adjustment has been completed, explain the current available balance using the authoritative system record. If the case depends on another payment or platform process, avoid presenting an estimate as a confirmed result.
Check connected systems for stale balance data
Where the storefront, loyalty platform or order system holds replicated balance information, verify whether the discrepancy is caused by delayed or failed synchronisation. Correcting only the visible front-end value may hide the underlying integration fault and allow the inconsistency to return.
Close the case with one recognised source of truth
Once the balance is reconciled, ensure the operational record shows the final confirmed state and any required correction reference. Temporary notes or investigation flags should be cleared or superseded so another colleague does not reopen the same discrepancy from outdated information.
Use repeated discrepancies as evidence of a process defect
If similar cases recur, review where the event chain is breaking: refund handling, order cancellation, integration timing or manual adjustment practice. This topic is distinct from refund-status reconciliation because the focus is the stored-value ledger itself and the need to preserve a traceable balance history before changing customer credit.