Chargeback alert automation, because response time is what you are really buying
An alert arrives at 6pm on a Friday. Ethoca's guidance targets a refund within about 24 hours. Nobody looks at the inbox until Monday morning.
You paid for that alert. You will also pay the chargeback fee, lose the order, and take the ratio entry. The fee bought you nothing, and the vendor did nothing wrong.
This is the part of alert economics that no rate card describes. The price is fixed. What you get for it is entirely a function of how fast you act.
Deflection rate is the multiplier on every fee you pay
Your real cost is not the alert fee. It is the fee divided by the share of alerts that actually stop a chargeback.
At a $24 Ethoca alert:
| Your deflection rate | Real cost per dispute stopped |
|---|---|
| 95% | $25.26 |
| 90% | $26.67 |
| 80% | $30.00 |
| 70% | $34.29 |
| 50% | $48.00 |
The gap between the best and worst published Ethoca rate in the market is about $5. The gap between a 90% and a 50% deflection rate on the same rate card is $21.33. Operational speed moves your cost per outcome roughly four times more than vendor selection does.
This is also what decides whether a per-alert rate card beats a per-deflection one. Against a vendor charging $29 only on success, a $24 alert billed on receipt wins only above an 83% deflection rate, which I worked through in per alert or per deflection. Below that line you are better off buying the other billing model.
The four things that eat the window
Delivery latency. The gap between the network firing and the signal reaching a system you watch. Email to a shared inbox is the slowest common arrangement and the most popular one.
Detection latency. How long before a human sees it. Overnight, weekends and holidays are where most of the loss sits, and they are roughly a third of the calendar.
Decision latency. Somebody has to decide whether to refund. If that requires a manager, or a look at the order history, the window is already half gone.
Execution latency. Issuing the refund and having it register. Usually fast, occasionally not if it routes through a separate system.
Only the first is the vendor's to fix. The other three are yours, and they are the reason two merchants on identical rate cards get different results.
Rules beat queues
The instinct is to build a good queue: alerts arrive, a person triages, refunds go out. That works during business hours and fails the rest of the time, which is most of the time.
The alternative is a rule set that refunds without waiting for a person, with a human reviewing only the exceptions.
Auto-refund below a value threshold
Auto-refund on reason codes you never win
Route high-value alerts to a human, with a deadline
Hold back the cases where refunding is wrong
Step one carries most of the benefit. It is also the step merchants resist hardest, because refunding without looking feels careless. The arithmetic says otherwise: on a low-value order, the time spent deciding is worth more than the amount in dispute.
What to build against
Whatever tooling you use, three capabilities determine whether the rules above are implementable at all.
Alerts have to arrive as data, not as email. A webhook or an API feed can trigger a rule. A message in an inbox cannot.
The alert has to resolve to a specific order automatically. If a person has to search for the order before anything can happen, you have not removed the human, you have just moved them.
The refund has to execute against the store without a second login. Every system boundary adds latency and a chance of the window closing.
Deflecting a dispute before it is filed is built around that shape: the signal lands in the same platform that already holds the order, returns and edit history, so a rule can act on it without a person assembling context first. The rates are published at $15 per Visa RDR or CDRN alert and $24 per Ethoca alert.
Worth being precise about why that matters commercially rather than as a feature: since every vendor resells the same network access, the signal is identical. What differs is how quickly it becomes a refund.
The honest part
Automatic refunding means refunding some customers who would never have escalated. Not every cardholder who calls their bank goes on to file, and you cannot tell which from the alert. Auto-refund rules will hand money back on disputes that would have evaporated, and that cost is real and unavoidable at any response speed.
The deflection rates in the table are illustrative, not benchmarks. I have not published a figure for what our customers achieve because it varies enormously with order value, category and how aggressively the rules are set, and a single number would be more misleading than useful.
And speed has a ceiling that automation cannot raise. If the alert reaches you after the chargeback has already been filed, no rule helps. That happens, it is a network timing property rather than a workflow failure, and it is part of why coverage and deflection are different measurements.
Frequently asked questions
How fast do I need to respond to a chargeback alert?
Ethoca's guidance targets a refund within about 24 hours, and Verifi's CDRN runs on a 72 hour clock. Because those windows include nights and weekends, any process that depends on someone checking an inbox during business hours will miss a meaningful share of them.
Should I auto-refund chargeback alerts?
Below a value threshold, almost always. The deliberation costs more than the order, and a rule works at 3am when a person does not. Above the threshold, route to a human with the network window attached as a deadline. Keep a hold-back list for cases where refunding is wrong, such as digital goods already consumed.
How much does response time actually cost me?
It is a multiplier on every fee you pay. At a $24 Ethoca alert, a 90% deflection rate costs $26.67 per dispute actually stopped while a 50% rate costs $48. The spread between the cheapest and most expensive Ethoca rate in the market is about $5, so operational speed moves your cost per outcome several times more than vendor choice.
What do I need for alert automation to work?
Alerts delivered as data rather than email, automatic resolution of the alert to a specific order, and the ability to refund against the store without a separate login. Missing any one of those puts a human back in the critical path and the window is too short to absorb that.
The measurement to take this month: timestamp every alert on arrival and on refund, then look at the distribution rather than the average. The average will look acceptable. The tail, the ones that arrived Friday evening, is where your deflection rate is actually being lost.