The retry that billed the customer twice
Your customer gets charged twice, and nothing in your system thinks anything went wrong. Both runs succeeded, because both runs really did succeed.
How it actually happens
Your automation sends a charge. The network stalls for a moment and the acknowledgement never comes back. The platform does the sensible thing and retries. The second attempt goes through. So did the first one. Two charges, two success messages, no error anywhere.
Why nothing catches it
A retry is not a failure. It is the recovery behavior you want in almost every other situation. Your logs record two successful runs, because that is exactly what happened. There is no rule anywhere that says this customer should only have been charged once, so nothing has an opinion about it.
What it costs
A refund, an apology, and a customer who now wonders what else you are getting wrong. The refund is the cheap part.
How we test for it
We build a scenario where the same operation is deliberately submitted twice, the way a retry would. The correct result is written down before the test runs: one charge, one record, one message. Your team runs it in your own sandbox with invented orders. If your workflow produces two, we can show you exactly where.
Find out whether this one applies to you
The fit check is free and written. Four short answers, no call, no files, no credentials. A person reads it and tells you straight whether this is worth checking in your setup.
Request a fit check or call (832) 966-3895
The other patterns
The update that landed on the near twin · The stale update that reversed a correct state · The discount typed as 100 instead of 10 · The job marked complete when a step silently failed
All scenarios and amounts on this page are fictional teaching examples, not customer incidents.