Protect yourself from card testing
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 Stripe share responsibility to prevent it. At Stripe, 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.
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 Stripe 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 Payment Details on blocked transactions.
- The graphs under Developers in the Dashboard show recent activity on your Stripe account. Elevated decline rates caused by card testing will usually show up on these graphs.
- Specific card testing declines will be in your failed request logs as 402 errors.
Payment blocked due to suspected card testing
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 Stripe secret key to create charges and validations. Ensure that you’re keeping your keys safe and don’t publish your secret key publicly.
Not a developer? Using a plugin or platform? Preventing and mitigating card testing typically requires code-level changes, so you’ll need to show this documentation to the developer or vendor who wrote the code and work with them to prevent card testing.
Optimize your Stripe integration
Stripe 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 Stripe’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 Stripe’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.
Using one of our recommended payment integrations allows you to get the most out of Stripe’s card testing prevention. If you can’t use a recommended integration, include as much data as possible or implement your own controls.
|Integration type||Card testing integration quality|
|Stripe Payment Links Recommended|
|Stripe Checkout Recommended|
|Stripe Elements with Customer signals Recommended|
|Direct API integration with client and Customer signals|
|Direct API integration with client signals|
|Direct API integration with Customer signals|
|Direct API integration with no additional signals|
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 Highest impact
- IP address
- Customer email
- Customer name
- Billing address
Finally, your API keys give you access to Stripe’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.
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 endpoints 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 Stripe.
- 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.
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. Some of the safeguards that protect against Cross-Site Request Forgery (CSRF) attacks are also effective against some types of card testing, such as CSRF tokens.
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 Radar rules
If card testers are making payments with your integration you might be able to use custom Radar rules to mitigate the fraudulent activity. For example, the following rule could be effective to stop some instances of card testing.
Block if :declined_charges_per_ip_address_daily: > 3
Creating custom Radar rules requires the Radar product, and its rules only apply to payments. Radar can’t be used to stop card testers from performing card validations.
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.