A repeated customer message or uncertain page result should not automatically trigger a second activation. Use a stable order reference and check the existing action’s state before repeating it. The supplied website is an enquiry flow, so do not assume it provides a transactional backend or automatic duplicate protection.
Separate request, payment and activation states
An enquiry received, a payment confirmed and an account activated are different events. Record each explicitly. Treating them as one checkbox can lead to duplicate work or an account being marked complete before access exists.
Use one reference per intended order
When a customer retries, connect the new message to the original reference. Ask what happened rather than creating another order by default. A duplicate payment needs its own accurate transaction record and the actual resolution process.
Verify before repeating a state-changing action
If an activation tool gives an uncertain result, inspect the account or ask the supplier before retrying. Do not invent a panel button sequence or assume a failed screen means no server-side action occurred.
A practical sequence
- Assign a stable order reference.
- Track enquiry, payment and activation separately.
- Check the prior action before repeating it.
An example
A customer sending “Did it go through?” should prompt a check of the original order state, not an automatic second credit deduction or second account creation.
Questions about this topic
Does a frozen screen prove nothing happened?
No. The server may have processed an action before the display failed.
Does this website implement automatic activation?
No such backend is established by the supplied project facts.
