Prevention alerts are designed to help stop disputes from becoming chargebacks. But sometimes the process doesn’t work as expected, meaning a transaction will receive both an alert and a chargeback. This is referred to as “leakage”.
Alert leakage is usually the result of actions taken by the issuer (cardholder’s bank). Unfortunately, neither Midigator nor the alert vendors (Ethoca and Verifi) have any control over chargebacks that are issued.
However, Midigator can help you identify the reason for the leakage and offer suggestions on how to avoid future issues.
The following are the most common reasons why alerts turn into chargebacks:
1. The transaction was not refunded fast enough.
When you respond to an alert, the alert vendor (Ethoca or Verifi) will inform the issuing bank that you’ve refunded the transaction. However, the bank won’t consider the case closed until the refund is actually posted to the cardholder’s account.
Typically, if the issuer doesn’t see a refund within 24 hours of initiating the alert, the issuer will advance the case to a chargeback.
If you are using Midigator’s PreventFlow™ feature, you should refund the transaction as quickly as possible. (If you use Midigator’s fully-automated prevention alert service, the technology will issue a refund on your behalf.)
Regardless of the workflow you use within Midigator, you need to batch out your transactions quickly so the refund will be posted to the cardholder’s account within the time limit.
2. You didn’t respond to the alert or didn’t respond quick enough.
Again, the issuing bank will only consider a dispute to be resolved if a refund has been posted to the cardholder’s account. However, the bank relies on the alert response as an indicator of whether or not the cardholder’s account is ready to be reviewed.
Therefore, if the issuer doesn’t receive an alert response — or doesn’t receive one within the time limit — it usually won’t even look for a refund.
If you use Midigator’s fully-automated prevention alert service, the technology will respond on your behalf. This shouldn’t be one of the reasons you experience leakage.
However, if you are using Midigator’s PreventFlow feature, you’ll need to respond to alerts manually. Be sure to resolve each alert within Midigator as soon as you’ve issued a refund. Click here for a user tutorial that explains how to resolve alerts within PreventFlow.
3. The issuer didn’t wait the full 24 hours.
Sometimes, the issuer won’t let a full 24 hours pass before advancing the case to a chargeback.
This most commonly happens towards the end of the month. The issuer may want the chargeback to be included in the current month’s count rather than the following month’s.
4. You only issued a partial refund.
Due to regulatory guidelines, an issuer is required to ensure that the amount refunded to the cardholder matches the amount that the cardholder disputed.
Therefore, if you issue a refund for less than the alert amount, the issuer will likely initiate a chargeback for the remainder of the disputed amount.
If you are using prevention alerts to keep your chargeback counts low, we suggest you refund the full alert amount.
If threshold breaches aren’t a concern and you don’t feel the customer is entitled to a full refund, you may want to ignore the alert. This will likely result in a chargeback that you can fight so you can potentially retain the revenue.
5. The issuer made a mistake.
Unfortunately, many issuing banks still rely on manual processes. As a result, some chargebacks are caused by human error. For example, a new hire in training at the issuing bank may accidentally process a chargeback even though you’ve refunded the transaction.
6. The MID used for the refund was different than the MID used to process the transaction.
If the merchant account (MID) used to process the original transaction has been closed, you won’t be able to use it to process a refund. It may seem helpful to refund with an alternate MID, but this could make it difficult for the issuer to match the refund to the alert.
Be aware of potential drawbacks in this situation.
If the issuer does advance the case to a chargeback after you’ve refunded the alert, you’ll suffer a double loss. Under normal circumstances, you could easily overturn a chargeback by providing proof that a refund was issued before the chargeback was initiated. However, if the refund was made with an alternate merchant account, there is no guarantee that a response will be successful.
7. The issuer experienced technical difficulties.
Although rare, alert leakage may be due to system issues within the issuer’s environment. If the issuer is unable to properly use the alert platform, chargebacks may be filed even if you’ve already refunded the transaction.
Check the bank identification number (BIN) associated with the leakage. If the issuer is struggling to use the technology correctly, you will see a large batch of leaked chargebacks from the same BIN.
Please let us know if your data indicates an issuer is experiencing technical difficulties. We’ll work with Ethoca or Verifi to resolve the issue as quickly as possible. You can contact us via the chat feature or by emailing email@example.com.
Additional Things to Know
If an alert does turn into a chargeback, there are a few other things to keep in mind.
You can fight and win. If you refunded the transaction before the chargeback was issued, you can respond to the chargeback with proof the cardholder’s account has been credited. You should easily win the case and recover the funds lost to the chargeback.
You can block problematic BINs. Analyze the BINs (bank identification numbers) associated with the leaked alerts. If any BINs are consistently allowing alerts to become chargebacks, you may want to consider using a BIN blocker. This would prevent purchases from that particular BIN.
If you have additional questions about alert leakage, please contact our team. You can use the chat feature or email firstname.lastname@example.org.
If this feature isn’t visible in your Midigator account and you want to know why, read this article.