Alert on payment failures in batches rather than individually, and treat a cluster within a short window as a possible gateway or configuration problem rather than a run of unrelated declines. Individual failures are usually recoverable revenue with a short half-life; a sudden cluster is an incident.
Why this one is worth an interruption
The single failure and the cluster need completely different responses, which is why alerting on each one individually is a mistake. One is a customer to help. Twenty in an hour is something broken on your side or your provider's.
Individual failures are also more recoverable than most stores assume. A card declined at checkout is frequently a limit, an expiry or an address mismatch, and a prompt, plain message recovers a meaningful share of them.
The threshold
The interesting signal is rate, not the individual event.
| Condition | Set it to | Why that number |
|---|---|---|
| Cluster trigger | failures above your normal rate within an hour | This is the incident case |
| Individual trigger | only above a value floor | Below it, recovery costs more than it returns |
| Baseline | establish your normal rate first | Every store has a nonzero failure rate |
| Repeat customer flag | existing customer fails | More likely a fixable card problem than fraud |
| Quiet hours | none for the cluster trigger | A broken gateway does not wait |
Who should receive it
Split by which case fired. They go to different people.
- Whoever handles payments or the storefront, for the cluster trigger.
- Whoever contacts customers, for individual high-value failures.
- Not everybody. A steady trickle of declines is normal and broadcasting it is noise.
What to do when it fires
- On a cluster, check your payment provider's status page before investigating your own store.
- Check whether anything changed recently: a theme deploy, an app install, a payment setting.
- On an individual high-value failure, contact the customer with a plain, non-accusatory message and an easy way to retry.
- Record the reason codes. A pattern in them usually points at one fixable configuration issue.
When not to set this alert
Do not alert on every individual failure. Every store has a background rate, and a notification per decline trains the team to ignore the channel within a week.
Do not set the cluster trigger before you know your normal rate. Without a baseline you cannot tell a spike from a busy afternoon.
Common questions
Why do payments fail at checkout?
Most commonly card limits, expiry, address verification mismatches or bank-side risk rules. Genuine fraud attempts are a smaller share than most stores assume.
Should I alert on every failed payment?
No. Every store has a background failure rate, and alerting on each one makes the channel unreadable. Alert on clusters above your normal rate, and individually only above a value floor.
What does a sudden spike in failures mean?
Usually a configuration or gateway problem rather than a run of bad luck. Check your payment provider's status and anything that changed on the storefront recently.