In this guide
Create the request before the actionUse a state that blocks guessingCoordinate staff handoversResolve duplicates transparentlyA repeated click, second staff member or unanswered message can create a duplicate recharge request. The operational goal is to know whether the original request exists and what is confirmed before starting another paid action. A lack of immediate reply is not evidence that the first request failed.
Create the request before the action
Assign an internal reference, target provider account, package and currency total. Record who owns the request and who may approve it. Keep the approval, payment evidence and provider confirmation attached to the same reference. If the tool does not support these fields, use an appropriately restricted record that does.
Use a state that blocks guessing
Mark the request as pending while its outcome is unknown. If a timeout or unclear response occurs, record the time and ask the provider about that reference. Do not relabel it failed solely because a screen stopped responding. A retry should follow a confirmed explanation of the first request, not a hope that only one will count.
| Observation | Operational response |
|---|---|
| No reply yet | Follow up on the existing reference |
| Payment appears pending | Check payment state with the responsible party |
| Unclear action result | Ask provider before repeating |
| Confirmed duplicate | Keep both references and request clarification |
Coordinate staff handovers
One person should own the next action until responsibility is explicitly handed over. A colleague can add evidence without submitting another request. At shift change, state whether payment was initiated and whether credits were confirmed. Avoid vague notes such as “please recharge” that could refer to either the original request or a new one.
Resolve duplicates transparently
If two actions were submitted, preserve both references and amounts. Ask the seller what actually completed and what correction process applies. Do not invent a reversal or credit-return guarantee. Close each record with the confirmed outcome so a later balance review does not remove one merely because it looked redundant.
Questions about this guide
Is this a claim that the provider supports idempotency keys?
No. The reference is an internal coordination control unless the provider explicitly supports a technical request identifier. Use the actual platform’s documented capabilities and ask support about an uncertain result. Do not assume a repeated request will be deduplicated automatically.