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 your chargeback portal nor the alert vendors (Ethoca and Verifi) have any control over chargebacks that are issued.
However, we 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:
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.
SUGGESTION: If you are using the PreventFlow™ feature, you should refund the transaction as quickly as possible. (If you use chargeback portal's fully-automated prevention alert service, the technology will issue a refund on your behalf.)
Regardless of the workflow you use within the chargeback portal, you need to batch out your transactions quickly so the refund will be posted to the cardholder’s account within the time limit.
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.
SUGGESTION: If you use chargeback portal'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 the PreventFlow feature, you’ll need to respond to alerts manually. Be sure to resolve each alert within the chargeback portal as soon as you’ve issued a refund.
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.
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.
SUGGESTION: 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.
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.
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.
SUGGESTION: 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.
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.
SUGGESTION: 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.
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.
Comments
0 comments
Article is closed for comments.