You may have had your merchant account open for some time, or maybe you are just starting out. In an effort to build your brand, capture more sales or donations, you work with your payment processor and a web developer to launch your eCommerce site and online payments. API credentials are plugged in, the transaction flow on your payment page is tested and works, and you go live. The next morning you see hundreds of emails of orders processed and think taking payments online was a huge success. Then you open up the payment gateway to see thousands of authorizations, but something doesn’t seem right; they are mostly declined, and then legitimate payers start calling you complaining they can’t submit their payment. Sounds familiar?
Your site has been the target of fraudulent credit card authorization testing. Auth testing is nothing new but is now gaining traction and the attention of merchants and service providers as we see a greater occurrence on a daily basis. The automation and sophistication in online fraud tactics turn it into a widespread problem for businesses taking payments online. Every shopping cart platform, fraud management software, payment processor; and really anyone that deals with setting up eCommerce has written about the topic of card testing fraud. Merchants are warned about the risks and costs, and given tips and tools to mitigate; but we continue to see these card testing attacks. It is the great dilemma of preventative measures against these attacks also preventing legitimate transactions and making the checkout more complex.
As a business you work hard to create a seamless and frictionless online checkout, where the cardholder can submit their payment / donation with fewer steps and hassle, but this very thing is what makes your site a target of card testing fraud.
The fraud continuum: Steal card data, test card data, use card data
There are different facets of online fraud, being the target of card testing through your website is just a part of this continuum. On the one end, are data breaches, in the middle is testing this data, and on the other side is where we see chargebacks and fraudulent transactions occur. Let’s start by breaking it down.
What is card testing fraud?
Credit card information can be stolen through various means such as theft, loss, data breaches, the use of skimming devices and phishing emails and calls. Card testing occurs when fraudsters make use of easy checkout page or open donation payment pages to test the validity of the stolen credit card numbers. Often using botnet technology and using scripts to run hundreds of thousands of small online transactions within minutes.
How do you identify auth testing?
Card testing fraud often occurs at odd times of the day to delay detection. For example, overnight, or weekends. To avoid drawing attention to charges on active credit cards, the perpetrators will attempt small dollar transaction amounts. Auth testing attacks will run a large number of these authorizations, most of which will end up declining. Often, many of these will have the same name, email address or billing address added to the transaction details and a higher number of transactions will share the same BIN (bank identification number), the first 6 digits of the card.
Why is authorization testing a problem?
We mentioned that eCommerce fraud is a continuum, and from the moment a merchant’s payment page is used for these authorization testing attacks, it quickly snowballs with potentially damaging financial repercussions for both this merchant, and later, inventory losses for other merchants. For the merchants hit with auth testing, every transaction, approved and declined, comes with an authorization and card brand cost, which includes Visa’s integrity fee for excessive reattempts. The approved transactions, if gone unnoticed and the batch settles, will also carry processing fees and result in chargebacks from the cardholder’s owner that dispute the fraudulent transactions with their card issuing bank. These chargebacks also result in a fee per dispute. On the other end of the continuum, once the perpetrator knows which cards are still valid and active, they then immediately make large purchases from merchants selling valuable goods online. These online retailers are now the subject of the attack. It usually only comes to light that the transaction was fraudulent after the real cardholder disputes the charge, often too late since inventory has already been shipped. This merchant is now not only carrying the cost of lost inventory, but the processing and chargeback related costs as well. Both targeted merchants can be out tens of thousands of dollars from a single authorization testing attack, and sully the reputation of their merchant account with their payment processor.
How can you protect your organization and merchant account from auth testing and fraud chargebacks?
It is quite the conundrum, you invest in your online site, its esthetics, the ease to complete a transaction, and in SEO to grow website traffic and the number of people you can reach, but then told to make your payment page harder to find, harder to target. Website safeguards and fraud security measures are essential to protect against unauthorized transactions, but the dilemma remains of unintentionally blocking legitimate transactions. So, what tools and technology do we currently have to work with?
When it comes to online payments, there are at least two parts, the website platform and the payment gateway that play a role in payment acceptance. Here are some steps that can be taken with each and some of their pitfalls:
1. Rule-based fraud detection filters:
Most common payment gateways, like Converge, USAePAY, Worldline, and Authorize.net, offer fraud prevention and detection rules that can be set.
These rules are classified in two groups and the type of rule will affect auth related expenses. Pre-processing, stops the authorization at the gateway level and avoids authorization costs; while post-processing rules stop the authorization at the card issuer level and still incurs authorization expense.
Pre-processing rules include setting velocity filters to limit the number of transactions you allow per hour, per day, and/or per IP address. Once a bot attack reaches and triggers these limits, the gateway will begin to prevent further authorizations. While mitigating the extent of the auth attack it however also begins to block out legitimate transactions from being approved until the velocity condition resets. A further limitation, is that to utilize the number of transactions per IP address filter, some payment gateways require the payment integration you use to pass the parameter ssl_cardholder_ip in the API call; which many integrations don’t do.
Post-processing rules include setting AVS (address verification) and CVV (card verification) rules to reduce the use of stolen cards where the values entered don’t match what the card issuer has on file for the card. You can customize the rule so that if a certain AVS or CVV response code is received, the transaction will automatically decline. While designed to detect suspicious activity, since this type of rule still calls out to the card issuer, even when declining the transaction, you would incur an authorization expense.
2. Set notifications
Payment gateways give you the ability to send out email notifications of approvals and/or declines. Setting these notifications can alert you to something being amiss when you begin receiving many notifications in a short timespan. While this can be helpful in keeping and eye on things, due to the attacks happening during off hours it may be too late to take any action by the time you see the notifications.
3. Set thresholds
Bot auth attacks try to run the minimal dollar amount possible to avoid detection by active cardholders. They look for the cheapest product on your site or donation pages that let the cardholder input any dollar value. If you know that the there is a minimum transaction amount you expect for your business, you can set custom threshold rules within the payment gateway to decline transactions under that dollar value. While this may be a deterrent, it in itself won’t prevent the attacks.
4. Enable CAPTCHA and reCAPTCHA
CAPTCHA, a type of test response to try to distinguish between human and bots, should be set in both the payment gateway and on your website’s payment page. While some CAPTCHA methods are more sophisticated than others, research shows that bots may still be able to bypass this measure.
5. Enable EMV 3D Secure
3D secure adds an additional security layer by prompting a verification step (i.e. code sent to mobile phone # on file with the card issuing bank) to verify that the person submitting the payment is the owner of the credit card and shifts a merchant’s liability in the event a verified transaction results in a fraud chargeback. While probably amongst the most advisable routes to take, and while Converge currently supports 3DS 2.1.0 & 2.2.0, some other payment gateways are not upgrading to version 2 and ending their support for 3DS version 1. Adding 3D Secure can also cause some friction to your checkout process for some legitimate customers by adding an extra step to the payment process. And since there is a call out to the card issuing bank during the authorization, even if verification fails and 3D Secure declines the transactions, the merchant will still carry an authorization cost along with a 3D Secure occurrence cost.
6. Secure your website’s payment page
Popular eCommerce platforms like WooCommerce and Magento offer built in tools to tackle online fraud, but it is important to work with your web developer or integrator to implement additional steps. This can be as simple as making sure source code is hidden, utilizing machine learning and bot management technology to detect the likelihood requests are coming from a bot, and utilizing advanced web application firewall (WAF).
If your payment page has been targeted by auth testing, there is a greater likelihood that fraudsters will keep returning. Once this happens, it would be a good idea to move your payment page link to a new URL, require more data fields at checkout, incorporating hidden fields, or start requiring a login. By requiring a login, you can limit the number of users that can register a day, the number of credit cards a single user can add, and set user session timeouts; as well as enable two factor authentication (2FA) or multi-factor authentication (MFA). While these options require the fraudster to run longer scripts, and perhaps avoid your payment page, it also prevents a seamless checkout experience for your customers.
7. Add fraud chargeback and dispute protection
Whenever running an eCommerce storefront and taking any kind of payments online, it is inevitable a business will need to have some form of damage control from the use of active stolen cards and the resulting fraud chargebacks. Cartis Payments works with software that is compatible with leading shopping carts (Shopify, WooCommerce, Magento, BigCommerce, and many others) to detect fraudulent orders before items are shipped, and insures and pays for verified orders should they result in a fraud chargeback. Supplementing this chargeback protection with Verifi by Visa and Ethoca by MasterCard post-purchase alerts to resolve fraud and non-fraud disputes before they become chargebacks, will help businesses avoid the processor’s chargeback related fees and merchant account closure when a website is experiencing excessive fraud or friendly fraud. While these services pay for themselves, any type of insurance or protection does come at a cost.
Sure, there is what can be done to protect online card acceptance, but not without shortcomings. Businesses can be busy, putting in the right measures, monitoring website traffic, reviewing their payment pages, and logs for modifications to injected code; but the reliance on existing measures is flawed. While these measures are essential, they sometimes lack sophistication to distinguish between fraud and genuine activity, all the while hampering the checkout experience for real purchasers.
Help us solve this quandary! We would like to hear from you. Has your website been victim of card testing fraud? What payment gateway do you use? What actions did you take? Does your payment gateway or website back-end have the tools to address the problem? Is there really a solution out there?