BLOG · 2026-06-17
I got charged twice, the email went out three times
Few things look worse than charging a customer twice or sending them the same email three times in a row. And it's almost never malice or human carelessness: it's an automation that fired more times than it should. Let's look at why it happens and, above all, how to prevent it.
The problem with doing something "twice"
An automation is built to repeat tasks. The problem is when it repeats the exact same specific task it already did. Charging the same order twice. Sending the same reminder three times. Creating the same customer four times in your database.
For an email it's annoying. For a payment it's a real problem: refunds, complaints, a bad review, and if it keeps happening, even trouble with your payment provider.
Why it duplicates
- The notification arrived twice. Many services notify your automation when something happens (a payment, an order). To be safe, they sometimes notify more than once to make sure you got it. If your robot can't tell "I already processed this," it acts again.
- It retried after a half-finished failure. The automation charged, but right after, the connection dropped before it could note "already charged." On retry, it charges again. The action happened; the "recording it" didn't.
- Two processes at once. Two copies of the same robot start almost simultaneously and both think it's their turn.
The idea that fixes it: "do it only once"
The rule that solves almost all of these has an ugly name but a simple idea: every important action must be repeatable without causing harm. That is, if for whatever reason the automation tries to charge order 1234 again, the system should respond "this one's already charged, do nothing" instead of charging again.
Think of an elevator button. Press it once or five times, the elevator comes once. That's exactly what we want: pressing too many times does no harm.
How it's done in practice
- A unique tag per action. Each charge, email or record carries a unique tag (the order number, for example). Before acting, the system checks whether that tag was already processed.
- Record first, act second — and verify it. Order and verification matter so a mid-process drop doesn't leave things half-done.
- One process at a time for the critical stuff. For payments, it's worth ensuring two copies of the robot don't work on the same order simultaneously.
The payments case (Stripe and similar)
With payments this is especially delicate because money is involved and because gateways deliberately notify "extra." A duplicate charge isn't just a technical error: it's a refund, a complaint, and a customer who no longer trusts you. That's why payment flows must be built assuming from the start that the payment notification may arrive several times, and the system prepared to count it only once.
When we build automations that move money, this isn't an optional detail: it's the first thing designed. It's far cheaper to prevent the double charge than to refund it and win back the customer's trust.