Card testing is a type of fraudulent activity in which someone attempts to determine whether information from a stolen card can be used to make purchases.
This type of fraudulent activity is an unavoidable risk that is part of online commerce. Therefore, we are constantly improving our tools and systems to detect and reduce the risk of fraud; however, it is vital that you always remain vigilant.
Card testers use both authorizations and payments to determine whether the stolen or generated card information they have is valid.
Authorizations: this is the preferred method of checking cards, as authorizations do not usually appear on cardholder statements. This also makes it less likely that the cardholder will notice or report fraudulent activity.
Payments: Card testers prefer small payments, which are less likely to be noticed by cardholders and reported as fraudulent. This makes donation sites and businesses that facilitate low value purchases ideal targets for card testers.
Adverse effects
If your Stripe integration is being exploited by card testers, you should mitigate fraudulent activity as soon as possible. Card testing has many negative aspects, some of which worsen over time as card testing continues.
Disputes: Many types of card testing involve payments, some of which will be successful. Many of those successful payments will be noticed by the cardholder and disputed as fraudulent, resulting in disputes that cost you time and money.
Higher rejection rates: Card testing often results in many rejections associated with your business. A high rejection rate damages your business's reputation with issuers and card networks, making all your transactions appear riskier. This can result in an increased rejection rate for legitimate payments, even after card testing stops.
Additional fees: card testing activity can result in additional fees, such as authorization fees for customized pricing plans and dispute fees.
Infrastructure load: Card testing often results in numerous requests and transactions on the network. This additional traffic can overload your infrastructure and disrupt legitimate activity.
Damages the health of the ecosystem: card testing has a negative impact on the financial system, which is why both Stripe and our financial partners want to help you stop it.
What do we do to prevent card testing?
PagueloFacil has multiple automatic and manual controls dedicated to mitigating card testing. These measures cannot prevent card fully testing; but your attention to these types of situations can make fraud much more difficult for these people. Your API keys grant you access to PagueloFacil's financial system and network. This access is exactly what these "card testers" want to take advantage of, so it is extremely important that you keep your keys in a secure state to prevent fraud and other malicious activity.
What can you do at your merchant to 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 often not enough to prevent card testing alone.
Systems that lack security measures to prevent unrestricted access to certain Stripe functions can be vulnerable to card testing. The 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 and have little or no impact on your legitimate traffic.
The specific security measures you add to your integration will vary depending on your situation and business needs. Several common approaches are described below.
Add a captcha
Card testers often use automated scripts that can be blocked by a captcha.
Google's reCAPTCHA is often effective in blocking card tests. They offer options for visible and invisible captchas, depending on your needs.
If you have added a captcha to your integration, but the card test has not stopped, check the following:
Make sure the captcha requires validation on all requests that allow card validations or payments with PagueloFacil.
Check the captcha documentation to make sure it has been implemented correctly. If you use a captcha that provides a score, adjust the threshold above which it prevents requests from succeeding.
Try a different captcha solution, such as switching from an invisible to a visible captcha, or use a completely different captcha solution.
Add speed limits
In some cases, you can stop card testing by adding speed limits. Tailor these speed limits to stop the specific type of card testing you are 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 a single IP address can create in a day.
Requiring login or login validation
Card testing can often be avoided 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.
Detecting and preventing unusual behavior
As soon as you have identified card testing activity, you can compare it to typical legitimate traffic, and then create rules or filters that limit or prevent only card testing activity.
For example, you can make changes to your system that:
Limit the number of cards that can be attached to a single customer.
Limit the number of clients that can be created with a single IP address.
Filter requests with certain user agents or other parameters.
Use a combination of mitigations
It may make sense to combine several approaches to stop card testing to maximize the impact on fraudulent activity without having an adverse effect on legitimate traffic.
For example, you could combine captchas and speed limits so that the first payment attempt from an IP address succeeds without restriction, but subsequent requests made by that same IP address over the next several hours require captcha verification to succeed.