GUEST BLOG, Part II: Reducing declines on the payment gateway side

Written by
Lacy Williams
Publication Date
May 15, 2014
Social Share
Don’t miss our latest news and updates
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

By David Goodale, Merchant 

In part I of this series, "Everything online merchants should know about credit card declines," we looked at the causes of declines and how to minimize them on the card issuer side. Unlike card-issuer side declines, as a merchant you should have a significant amount of control in terms of the anti-fraud settings within your payment gateway. 

Making certain that the anti-fraud rules are configured correctly for your type of business is important and can make a big impact on sales (as well as cut down on fraudulent orders significantly). 

may offer more or less functionality when it comes to the anti-fraud settings that are available in your control panel. You will have to explore to see what options are available with your chosen credit card processor. Ideally, you would like your payment gateway to be configurable to take the following actions when a potentially fraudulent order is detected:

  • Ignore: Do nothing.
  • Flag: Warn you when a suspicious order comes through, but take no action to decline.
  • Decline: Do not let the transaction be approved, and decline the order.

Every payment gateway will have its own set of anti-fraud rules. Some payment gateways have more advanced anti-fraud detection than others. It's also worth noting that some payment gateways may provide sophisticated fraud detection routines, but they may not be configurable by merchants. (For example, a velocity check filter may be supported, but it may not be adjustable on the number of hits within the elapsed period of time before a trigger is tripped.) 

You will have to contact your credit card processor to see what anti-fraud tools are supported within your payment gateway.

Below are some of the most common anti-fraud checks:

Velocity checks by card number: Will determine how many times a particular credit card has been processed within a certain window of time, for example, daily. If the same credit card number has been processed over and over again in a relatively small space of time, it can be an indicator of fraudulent activity. 

Velocity checks by IP address: Similar to the velocity checks on the card number, the velocity check on the IP address checks to see how many times a particular IP address has been used to perform a transaction within a certain window of time. If the same IP is used to submit three or four different credit cards within a short window of time, there is a high likelihood of fraudsters attempting to run transactions on stolen cards. However, IP checks are not perfect, because website visitors from some networks may share IP addresses, which could potentially cause false negatives. Unless you sell a particularly high risk product or service, you might want to set your velocity checks to flag but not decline. 

Geographic location transaction blocking: Some areas of the world have higher incidences of fraud than other territories. For example, some developing nations do not have significant enough police resources to be able to crack down on fraud. Transactions originating in these territories are far more likely to have a greater potential risk of fraud. 

Some payment gateways will enable you to decline an order if the CVV number (the three-digit code on the back of the card) does not match. In general, unless you have a particularly high risk product or service it is best to flag these orders for further investigation, but not decline them outright.

Similar to CVV-based declines, some payment gateways will enable you to decline orders in the case of mismatched AVS. I strongly recommend setting this to flag-only because of issues with international orders (where AVS may not be properly supported) resulting in false negatives.


How "air tight" should my anti-fraud rules be configured? 

As a merchant you must take responsibility for protecting your own best interests. In other words, do not ever process a suspect order and ship it while hoping for the best. At the same time, you do not want to be overly restrictive and inconvenience your customers when it is not necessary. 

Depending on the risk associated with your product or service you will want your anti-fraud settings to be more stringent, or a bit looser. For example, a merchant selling digital access to immediately download expensive software after payment (something like Adobe Photoshop) would have a much higher likelihood of attracting fraudsters than a merchant selling a physical product like knitting books. In fact, the knitting books example is less risky for two reasons: (i) it is a physical good that must be shipped and cannot provide the fraudster with immediate gratification; (ii) knitting books are likely to appeal to an older demographic that is less likely to commit online fraud. 

I cannot think of any cases off the top of my head where I have ever encouraged a merchant to disable the fraud rules entirely. Similarly, there are relatively few times when I have encouraged a merchant to set a fraud rule to automatically decline in the case of something mismatching, like AVS. In most cases, it is best to use anti-fraud rules to "flag" an order, so that it comes up on the radar and can be manually reviewed. An example of when you might set an anti-fraud filter to hard decline would be in the case of a product that can only ship within Canada. In that example, if the IP address showed the cardholder was located in Africa, it might make sense to automatically decline. However, situations like this are few and far between. It is better to let the order to through, at least as a pre-authorization, and give it the benefit of the doubt to at least allow for manual validation. Generally speaking, you do not want to lose sales unnecessarily because of an anti-fraud rule that is overly restrictive. 

In the next post in this series, we'll address reasons why card issuers decline transactions.

Download the Multiple Payment Gateways eBook Below

Related Articles

No items found.