Card testing is a type of fraudulent activity where someone tries to determine whether stolen card information is valid so that they can use it to make purchases. A fraudster may do this by purchasing stolen credit card information, and then attempting to validate or make purchases with those cards to determine which cards are still valid. Other common terms for card testing are “carding”, “account testing”, and “card checking.”
Fraudulent activity such as card testing is an unavoidable part of online commerce. Card testing, however, has consequences for the entire payments ecosystem, so merchants, card networks, and Omnibasis share responsibility to prevent it. At Omnibasis, we’re constantly improving our tools and systems to detect and reduce fraud, but you must remain vigilant with respect to fraud.
How card testing works
Card testers use both authorizations and payments to determine whether the stolen or generated card information they have is valid or not.
- Authorizations—This is the recommended method to test cards, as authorizations don’t typically show up on cardholder statements. This also makes it less likely the cardholder will notice or report the fraudulent activity.
- Payments—Card testers prefer smaller payments, which are less likely to be noticed by cardholders and reported as fraudulent. This makes donation pages and businesses that facilitate small-value purchases ideal targets for card testers.
Consequences
Card testing has many negative outcomes, some of which get worse over time as card testing continues:
- Disputes — Many types of card testing involve payments, some of which succeed. Customers notice successful payments and report them as fraud, which will result in disputes that cost you time and money.
- Higher decline rates — Card testing usually causes a large number of declines to be associated with your business. A high decline rate damages the reputation of your business with card issuers and card networks, which makes all of your transactions appear riskier. This can result in an increased decline rate for legitimate payments, even after card testing stops.
- Additional fees — Card testing activity can result in additional fees, such as authorization fees for custom pricing plans, and dispute fees.
- Infrastructure strain — Card testing usually results in numerous network requests and operations. This additional traffic can overburden your infrastructure and disrupt legitimate activity.
- Damages ecosystem health — Card testing has negative impacts on the financial system as a whole, so both Omnibasis and our financial partners want to help you stop it.
Active card testing checklist
If your integration is being exploited by card testers, we recommend that you take the following actions immediately:
- Identify the card testing activity.
- Refund fraudulent payments to avoid disputes.
- Add one or more mitigations to your integration to stop the card testing.
- Monitor your integration to ensure your mitigations are effective.
Identify card testing
You can identify most card testing activity by a significant increase in declines. When investigating card testing, you can view declines in three places in the Dashboard. These sections of the Dashboard give you both a high-level and detailed view of card testing activity:
- Payments that were blocked due to card testing will be indicated as such when you view details on blocked transactions.
- The graphs under omniPay Dashboard show recent payment activity on your account. Elevated decline rates caused by card testing will usually show up on these graphs.
- Specific card testing declines will be in your request logs as failed errors.
Prevent card testing
Card testers employ a wide variety of techniques to make their fraudulent activity difficult to block. As a result, simple firewall rules or filters based on things like user agent strings are usually not sufficient to prevent card testing on their own.
One of the most popular ways a card tester will attack you is by using your omniPay secret key to create charges and validations. Ensure that you’re keeping your keys safe and don’t publish your secret key publicly.
Optimize your omniPay integration
Omnibasis has many automated and manual controls in place to mitigate card testing, including rate limiters, alerts, machine learning models, ongoing reviews, and more. When we first detect that you’re under a card testing attack, we’ll apply as many controls as we can to mitigate the attack.
However, the success of Omnibasis’s controls depends on your integration and what signals you send to us. We use many signals to distinguish between card testing and legitimate payments. While we compute some of these signals automatically, many of them depend on the information that your integration provides. In general, the more data your integration provides, the more successful card testing prevention can be.
Furthermore, integrating with Omnibasis’s recommended integration enables us to run CAPTCHA automatically on suspected card testing charges. CAPTCHA is an effective challenge that stops fraudsters but is still low friction enough to allow your good users to use your service.
Out default payment integration allows you to get the most out of Omnibasis’s card testing prevention. If you can’t use a default integration, include as much data as possible or implement your own controls.
Including the following information with your payments can have a significant impact on the performance of card testing models. Our recommended integrations enable you to collect this information, while direct integrations might need to explicitly include this data.
- Advanced fraud detection provides for highest impact
- IP address
- Customer email
- Customer name
- Billing address
Finally, your API keys give you access to Omnibasis’s systems and a global financial network. That access is what card testers want to exploit, so it’s important to keep your keys safe and put safeguards around the functionality those keys provide to prevent fraud and other malicious activity.
Control implementation
Endpoints targeted by card testers typically allow them to do one of the following:
- Attach a card to a customer.
- Make a payment.
Adding security restrictions to API or user interfaces that expose this functionality will help you prevent or mitigate card testing. The restrictions you implement should make card testing impractical while having little to no impact on your legitimate traffic.
The specific security measures you add to your integration will vary depending on your situation and the needs of your business. Several common approaches are described below.
Add a CAPTCHA
Card testers often use automated scripts that can be blocked using a CAPTCHA. Google’s reCAPTCHA is often effective for blocking card testing. They provide options for both visible and invisible CAPTCHAS, depending on your needs. If you’ve added a CAPTCHA to your integration but card testing hasn’t stopped, check the following:
- Make sure the CAPTCHA requires validation on all requests that enable card validations or payments with omniPay.
- Review the CAPTCHA documentation to make sure it has been implemented properly.
- If you’re using a CAPTCHA that provides a score, adjust the threshold at which you prevent requests from succeeding.
- Try a different CAPTCHA solution, such as switching from an invisible CAPTCHA to a visible one, or using a different CAPTCHA solution entirely.
Add rate limits
In some cases, you can stop card testing by adding rate limits. Tailor these rate limits to stop the specific kind of card testing you’re experiencing. For example, if card testers use your integration to validate cards by attaching them to new customers, an effective deterrent might be to limit the number of new customers that can be created by a single IP address in one day. With Omnibasis, you can set this feature in User Security section of settings.
Require login or session validation
Card testing can often be prevented by requiring login or session validation when performing certain actions, such as creating an account or making a payment. You can turn off guest checkout, thus requiring you customers to create and validate an account.
Detect and prevent unusual behavior
As soon as you’ve identified card testing activity, you can compare it to typical legitimate traffic, then build rules or filters that limit or prevent only the card testing activity. For example, you might make changes to your system that:
- Limit the number of cards that can be attached to a single customer
- Limit the number of customers that can be created with a single IP address
- Filter out requests with certain user agents or other parameters
Use custom omniPay fraud prevention rules
If card testers are making payments with your integration you might be able to use custom fraud prevention rules to mitigate the fraudulent activity. For example, the following rule could be effective to stop some instances of card testing.
Use a combination of mitigations
It might make sense to combine multiple approaches to stop card testing in order to maximize the impact on fraudulent activity without having an adverse effect on legitimate traffic. For example, you might combine CAPTCHAS and rate limits so the first payment attempt from an IP address succeeds without restriction, but subsequent requests made by that same IP address for the next several hours require a captcha verification to succeed.