The rule for investigating an unfamiliar duplicate payment: decide from the provider reference, the receipt and the status — three checks together; never blind-retry the payment and never blind-claim a refund. The two biggest mistakes in duplicate incidents: panic-repaying, and claiming a refund without verification.
What to verify: provider reference, receipt and status; blind retry is not allowed
The decision table:
| Situation | Evidence | Decision |
|---|---|---|
| First payment succeeded; the second was the guardian’s mistake | two TrxIDs, both successful | refund or keep the second as advance — with a written note |
| First showed failed but money was cut | the first TrxID’s status | written claim to the provider — do not send a new payment before verification |
| Both show the same TrxID (system glitch) | compare record counts | a written incident to software support |
Core principle: in a duplicate, the biggest risk is the guardian’s money — so do nothing before the three proofs (TrxID, receipt, status).
A usable sample: the duplicate review decision table
Fictional incident: the guardian says “money was cut twice”:
- TrxID-1: successful, ৳500, receipt #2031 created.
- TrxID-2: successful, ৳500, no receipt — an unknown deposit in the system.
- Steps: verify TrxID-2 actually happened in the bank/app → yes → entry note “probable duplicate deposit, refund in process” → a written note to the guardian.
- Refund application to the provider → on receipt, note “returned received, dated”.
With these fields filled, the incident is “settled” — left open, it becomes a year-end mismatch.
Duplicate-payment review: workflow steps and limitations
- Keep the incident note on the student file — a next-month mismatch finds its answer in that note.
- Offer the guardian a choice: refund, or adjustment against next month’s fee — their preference in writing.
- Limitation: refund timing belongs to the provider — 7–10 days is common [VERIFY: provider terms]; so tell the guardian the expected time.
Duplicate review: questions to ask before your demo
- Does the system warn automatically on duplicate deposits?
- Can a reversal entry be made — instead of deleting?
- Does the incident note stay attached to the receipt?
See the payment-verification structure in fee management and the fee documentation; gateways on the integrations page.
Duplicate review FAQ
The guardian lost the TrxID?
The TrxID exists in the system record — retrieve it from the office; the process should not run on guardian memory.
What entry does a refund get in the ledger?
A separate “reversal/refund” entry — do not delete the original deposit; keep the whole cycle visible.
What should guardians be told to prevent duplicates?
“Do not pay the same invoice twice; if a payment seems failed, ask the office first” — kept in the general instructions.