Chargeback Alerts Explained: Ethoca, Verifi CDRN, and RDR for High-Risk Merchants

Your acquirer's risk team sends the email every high-risk merchant eventually gets. Ratio is trending the wrong way, a remediation plan is due Friday, and step one is enrolling in chargeback alerts. A week later three vendors are quoting per-alert pricing and promising to halve your disputes. Nobody explains that "alerts" is really three products, owned by two card networks, behaving differently against the two ratios you are measured on. Merchants buy the wrong coverage, pay for refunds they never owed, and still trip the threshold. Here is what each does to your numbers, what the arithmetic looks like, how to audit a vendor's catch rate, and where alerts fail.

What an alert actually is

A chargeback normally starts with a phone call. The cardholder calls the issuing bank about a charge they do not recognize or no longer want, and the issuer opens a dispute that lands in the numerator of the ratio governing whether you keep processing.

An alert intercepts that call. Instead of filing immediately, the issuer publishes a notification into a network that resells it to you or your vendor. You get the card's last four digits, the amount, the date, an issuer-supplied reason, and a short window to act. Refund inside that window and the issuer generally closes the case, so no chargeback is filed.

That mechanic explains the appeal and the limit: you refund voluntarily instead of taking a chargeback involuntarily, and the money leaves either way. What you protect is the ratio, the per-chargeback fee, and the acquirer relationship.

The three products, and who owns what

Product	Owner	How it works	Merchant action
Ethoca Alerts	Mastercard	Issuer publishes a notification, you refund inside the window	Refund required, ideally automated
Verifi CDRN	Visa	Alert-based, same shape as Ethoca on the Visa side	Refund required, ideally automated
Verifi RDR	Visa	Rules-based auto-resolution before any alert reaches you	None, the refund fires on your rules

Ethoca and CDRN are the same idea run by the two networks that own them, and their coverage does not overlap. Ethoca reaches Mastercard-side issuers and CDRN reaches Visa-side issuers, so enrolling in only one leaves you uncovered on roughly half your card mix, which is why most buy both through a vendor that normalizes them into one feed.

RDR is a different animal and the one merchants misunderstand most often. You configure rules ahead of time, typically a dollar ceiling and a set of dispute conditions, and Visa refunds a qualifying pre-dispute on your behalf. Nothing depends on your team seeing a message in time, but you have pre-agreed to lose every case matching your rules, including ones you would have won at representment. RDR also sits earlier in the flow than CDRN, so it resolves a matching case before any alert reaches you, which is how merchants end up paying two vendors to catch one population. Keep the RDR ruleset narrow and let alerts cover what sits above it.

What each one does to the ratio

This is where the vendor deck and the rulebook diverge.

For Mastercard the accounting is clean. An Ethoca alert you refund in time generally never becomes a chargeback, so it never enters the Excessive Chargeback Merchant count. Because ECM is a two-part test needing both a count and a ratio breach, keeping cases out of the count protects you directly against the program that most often triggers a Mastercard-side termination.

For Visa it is less settled than it is usually sold. VAMP combines TC40 fraud reports and TC15 non-fraud disputes into one ratio, and resolving a case through CDRN or RDR addresses the dispute leg only, because the fraud-tagged transaction already generated a TC40 at the issuer that does not disappear when you refund. Visa has kept revising how VAMP counts resolved cases, so treat the exclusion as unconfirmed until your acquirer puts it in writing, and never build a remediation plan that only works if alerts scrub your Visa fraud numbers.

The translation nobody selling alerts leads with: they are strong medicine for friendly fraud, buyer's remorse, subscription surprise, and unrecognized descriptors, and weak medicine for true fraud, whose report is generated upstream of anything you can refund. If your problem is stolen cards and card testing, alerts will not save your VAMP number, and the work belongs at the authorization layer instead.

The arithmetic, honestly

Alerts are priced per case, generally in the mid-thirties per resolved alert, with RDR often lower because no human is in the loop. Rates move with volume and vendor, so treat that as market shape, not a quote.

Set it against what a chargeback actually costs: the transaction amount, a per-chargeback fee typically in the fifteen to forty dollar range, the cost of goods you already shipped, and one unit in a numerator that carries program fines and eventually your merchant account. An alert takes the same amount and goods, plus the alert fee. The delta per case is small, and the delta on the ratio is the entire point.

So alerts do not save money per dispute; they buy down ratio risk at a known price, worth paying near a threshold or under a remediation plan and wasted otherwise, which is why a merchant comfortably under both program lines should not be blanketing every transaction. And because every RDR resolution is a case conceded, set that ceiling where representment stops paying rather than at your average order value.

Building the operational side so they are not wasted

An alert you do not action inside the window is money spent on a notification, so the refund has to fire fast, which means automated.

The refund is not the whole job either. Cancel the fulfillment if the order has not shipped, or you have paid the money back and sent the product. Cancel the underlying subscription, since a rebill program that keeps billing an alerted customer generates the same alert next cycle at full price, and suppress the customer from remarketing.

One case deserves its own rule: the alert for an order you already refunded. Your automation has to check refund state before issuing anything, or you will pay a fee to refund a customer twice, and no vendor screens for this because none sees your ledger.

Then feed what you learn upstream, because alerts carry an issuer-supplied reason and reading them in bulk is the cheapest customer research available. A cluster of unrecognized-transaction alerts is a descriptor problem, not a fraud problem. A cluster on day three of a trial is a terms-disclosure problem. A cluster from one traffic source is an affiliate problem, and the argument for isolating it on its own MID.

Auditing your own catch rate

Vendors quote coverage as a share of participating issuers, which you cannot verify and is not what matters. What matters is the share of your disputes that reached you as an alert first, and only your own data answers that.

Run it at ninety days, per network, from four counts: chargebacks received, alerts invoiced, alerts resolved inside the window, and chargebacks on a card that had already generated an alert. Catch rate is resolved alerts divided by resolved alerts plus uncaught chargebacks, telling you how much of your dispute population the program reaches at all. Resolution rate is resolved alerts divided by total alerts, measuring your operation rather than the vendor's.

A low catch rate with a high resolution rate is a coverage problem, fixed by the other network or a different vendor. A high catch rate with a low resolution rate is yours, fixed by automation and window monitoring, not a new contract. The same reconciliation catches double billing, since one case can surface through two channels.

Watch that fourth count most closely: a chargeback on a previously alerted card usually means the refund fired after the window closed, the most expensive outcome available, because you paid the fee, refunded, and took the chargeback anyway.

Where alerts fail

Coverage is partial and the windows are short, so some disputes never produce an alert and some expire before anyone acts.

Alerts also do not win anything, because every resolved alert is a refund, so a merchant with a strong evidence position gives up cases it would have won. That is a fair trade when the ratio is the binding constraint and a bad one otherwise.

Most importantly, alerts treat the symptom. They lower the number the network watches without changing why customers are calling their banks, and acquirers can tell the difference. A merchant whose ratio is only survivable because of heavy alert spend still has a product, disclosure, or service problem, and that profile gets non-renewed at review even with a clean ratio, for the reasons in why stores get shut down.

Practical takeaway

The path that fails is buying alerts as a substitute for fixing the business. One network's coverage, an inbox nobody watches, an RDR cap set too high, and a ratio held under the line by spend that grows every month until the acquirer exits anyway. The path that lasts treats alerts as one instrument in a portfolio: cover both networks, automate the refund and everything attached to it, cap RDR where representment stops paying, audit your catch rate at ninety days, and read the alert reasons as the diagnostic they are. Then fix the descriptor, the trial terms, the cancellation flow, and the traffic source, so your alert spend falls instead of rising. Alerts buy the months to make those fixes, and merchants who use them well end up with a durable account rather than a rented ratio. If you want a straight read on whether alerts are the right spend for your current numbers, apply for an architecture review.