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 required, and step one is enrolling in chargeback alerts. A week later three vendors are quoting per-alert pricing, all promising to halve your disputes. Nobody explains that "alerts" is really three different products, owned by two different card networks, that behave differently against the two ratios you are actually measured on. Merchants buy the wrong coverage, pay for refunds they would not have owed, and still trip the threshold. Here is what each product does to your numbers, what the arithmetic really looks like, and where alerts stop working.

What an alert actually is

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

An alert intercepts that call. The issuer, instead of immediately filing, 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. If you refund inside that window, the issuer generally closes the case and no chargeback is ever filed.

That is the whole mechanic, and it explains both the appeal and the limit. You are buying the chance to refund voluntarily instead of receiving a chargeback involuntarily. 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 fraud or dispute notification, you refund inside the window	Manual or automated refund required
Verifi CDRN	Visa	Alert-based, same shape as Ethoca on the Visa side	Manual or automated refund required
Verifi RDR	Visa	Rules-based auto-resolution at the pre-dispute stage, before any alert reaches you	None, the refund fires on your pre-set rules

Ethoca and CDRN are the same idea run by the two networks that own them, which matters because coverage does not overlap. Ethoca reaches Mastercard-side issuers and CDRN reaches Visa-side issuers, so a merchant enrolled in only one is uncovered on roughly half its card mix. Most merchants buy both through a single vendor that normalizes them into one feed.

RDR is a different animal and the one merchants misunderstand most often. There is no notification and no decision to make. You configure rules ahead of time, typically a dollar ceiling and a set of dispute conditions, and when a qualifying pre-dispute arrives Visa refunds the cardholder automatically 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.

What each one does to the ratio

This is where the vendor deck and the network 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. Since ECM is a two-part test requiring both a chargeback count and a ratio breach, keeping cases out of the count is direct protection against the program that most often triggers a Mastercard-side termination.

For Visa, it is more complicated and less settled than it is usually sold. VAMP combines TC40 fraud reports and TC15 non-fraud disputes into a single ratio. Resolving a case through CDRN or RDR addresses the dispute leg, but a fraud-tagged transaction has already generated a TC40 at the issuer, and that report does not disappear because you refunded. Visa has continued to revise how VAMP counts resolved cases since the program consolidated, and merchants get told different things by different acquirers in the same quarter. Treat the exclusion as unconfirmed until your acquirer confirms it in writing for the current rules, and never build a remediation plan that only works if alerts scrub your Visa fraud numbers.

The practical translation is the one nobody selling alerts leads with. Alerts are strong medicine for friendly fraud, buyer's remorse, subscription surprise, and unrecognized descriptors. They are weak medicine for true fraud, because the fraud 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 you need authorization-level controls instead.

The arithmetic, honestly

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

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

So the honest framing is not that alerts save money per dispute. It is that they buy down ratio risk at a known price, and that price is worth paying precisely when you are near a threshold or under a remediation plan. A merchant sitting comfortably under both program lines who blankets every transaction in alerts is paying to refund customers who were never going to dispute.

Two cost traps to watch. The same case can surface through more than one channel and get invoiced twice, so require deduplication in the contract and audit against your own refund log monthly. And an RDR ceiling set too high hands away winnable high-ticket cases, so set the cap where representment stops being worth the effort, not at your average order value.

Building the operational side so they are not wasted

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

The refund is also not the whole job. Cancel the fulfillment if the order has not shipped, because otherwise you have refunded the money 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. Suppress the customer from remarketing, then reconcile alerts against your own refunds, because that is the only way to know whether your vendor's reporting is accurate.

Feed what you learn back upstream. Alerts arrive with an issuer-supplied reason, and reading them in bulk is the cheapest customer research in the business. 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 it is also the argument for containing that source on one MID rather than letting it contaminate your portfolio, which is what the MID load balancing guide is for.

Merchants on continuity billing get the most out of this loop, because their alert reasons map almost one to one onto fixable disclosure and cancellation friction. That vertical's version of the problem is covered on the subscription and continuity billing page, and the codes themselves in the chargeback code reference.

Where alerts fail

Coverage is partial. Not every issuer participates in either network, so a meaningful share of your disputes will never generate an alert at all. Vendor coverage percentages are rarely auditable, so measure your own catch rate after ninety days.

Timing is tight and unforgiving. Windows are short, often a day or three, and a case that expires unactioned becomes an ordinary chargeback plus the alert fee.

Alerts do not win anything. Every resolved alert is a refund, which means 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 when it is not.

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 is the profile that gets non-renewed at review even with a clean ratio, for the reasons in why processors shut down high-risk accounts.

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, no reconciliation, no subscription cancellation on refund, and a ratio held just 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, reconcile the invoice, 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 over time instead of rising. Alerts buy you 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.