How to Stop Card Testing on Magento 2

Card testing, also called carding, is fraud aimed at your checkout rather than your stock. Someone holding a list of stolen or guessed card details uses a script to try them against a real store, usually with small payments or card checks, to find out which cards are still live. The valid ones are then used elsewhere or sold on. Your store is simply a convenient testing ground, and a Magento checkout, like any online checkout, can be driven by a script.

The damage is not limited to the payments that succeed. Stripe's guidance on card testing lists the knock-on effects: disputes when cardholders notice the test payments that went through, a higher decline rate that can make card issuers treat all of your transactions as riskier, possible extra fees depending on your pricing plan, and extra load on your infrastructure from all the requests. Your order data suffers too, because a wave of fake guest orders looks like new customers until someone cleans it up.

Most attacks are obvious once you know where to look. The signs usually show up in three places.

• In your payment gateway: a sudden spike in failed or declined payments, often at low values, well above your normal decline rate.
• In Magento: bursts of guest checkouts with nonsensical names or email addresses and small totals. If your payment method reports failures back to Magento, you can have a copy of each payment failure email sent to your team under Stores > Settings > Configuration > Sales > Checkout > Payment Failed Emails, which makes a sudden burst hard to miss.
• In your server logs: the checkout's payment endpoints hit over and over, such as /rest/V1/guest-carts/{cartId}/payment-information or /graphql, sometimes from many different IP addresses. Scripts can call these endpoints directly without ever loading your checkout page, which is why the Magento protections below cover them too.

1. Turn on Google reCAPTCHA for checkout (Fix 1 below). It is the quickest Magento-side brake.
2. If you run Magento 2.4.7 or later, switch on rate limiting for placing orders (Fix 2).
3. Tighten your payment gateway's fraud rules: card verification (CVV) and address (AVS) checks, and any velocity limits your plan offers (Fix 3).
4. If the attempts all come through guest checkout, consider switching it off for now (Fix 4).
5. Refund any fraudulent payments that succeeded before the cardholders dispute them. Stripe recommends this to avoid disputes.
6. Tell your payment provider and whoever looks after your server, so they can check their side too.

Magento 2.4 includes Google reCAPTCHA. Get your keys free from Google's reCAPTCHA admin console, add them under Stores > Configuration > Security > Google reCAPTCHA Storefront, then choose where to use them. For card testing, the setting that matters is Enable for Checkout/Placing Order. Adobe recommends invisible reCAPTCHA v3, which scores each interaction in the background against a minimum score threshold that defaults to 0.5.

The important detail is that this one setting does not only protect the checkout page. According to Adobe's developer documentation, it also protects the guest REST endpoints that take payment information and the GraphQL mutations that set a payment method and place an order. Scripts that call those routes directly must then send a valid reCAPTCHA token in an X-ReCaptcha header.

Two cautions. If you run a headless or PWA storefront, it has to send that header too, or genuine customers will fail at checkout, so test a real order on staging before you switch it on in production. And if attempts keep getting through, Stripe's advice on CAPTCHA applies here as well: adjust the score threshold, or switch from an invisible check to a visible one.

While you are in that section, turn it on for Create New Customer Account and Customer Login too, which makes it harder to script fake accounts. If you take card payments through PayPal Payflow Pro, there is a separate Enable for PayPal PayflowPro payment form option in the same place.

Magento 2.4.7 added a rate limit on the payment information sent through REST and GraphQL, and Adobe's release notes say it is there to help prevent carding attacks that test many card numbers at once. It is off by default.

Find it at Stores > Configuration > Sales > Sales > Rate Limiting. Set Enable rate limiting for placing orders to Yes, then review the two limits: Requests limit per guest (default 50) and Requests limit per authenticated customer (default 10), counted over the period you choose in Counter resets in a (minute, hour or day). Think about how many order attempts a genuine customer of yours makes in a short period and set the guest limit with some headroom above that. A trade buyer placing lots of small orders is not a bot, so check against your own order history before tightening it.

If you are still on 2.4.6 or earlier, this setting does not exist. 2.4.6 is also out of support, so the rate limit is one more reason to plan the upgrade covered in our Magento 2.4.6 end of life guide.

Magento's settings slow the scripts down. Your payment gateway is where much of the card testing is actually caught, because it sees the card details and the card issuer's response. What to look at depends on your provider.

• Stripe: its card testing protections, including automated CAPTCHA and rate limits, work best with its recommended integrations, and Stripe says their success depends on the risk data your integration sends, such as the customer's IP address, email, name and billing address. Radar can block payments that fail CVC checks, and plans that support custom rules let you add velocity rules. Keep your Stripe extension up to date and ask your developer to confirm it sends that data.
• PayPal Braintree: the Basic Fraud Tools include AVS, CVV and risk threshold rules. Braintree says they are available at no extra cost to all merchants, need no developer work to set up and help protect against carding. Check they are switched on and set to reject payments when the CVV does not match.
• Other gateways: look for the same things: card verification (CVV) and address (AVS) checks, velocity or rate rules, and a way to challenge suspicious payments. PayPal's own guidance on carding attacks lists AVS and CVV checks, reCAPTCHA, velocity limits and hidden honeypot fields among the main checkout defences.

Stripe makes a point that applies to every provider: if you are not a developer or you use a plugin, most card testing fixes need code or configuration changes, so share your provider's guidance with whoever built or maintains your checkout.

The easier it is to reach your payment form, the easier it is to abuse. Stripe notes that guest checkout makes card testing easier, and that requiring a login or a validated session reduces your exposure. In Magento you can switch guest checkout off at Stores > Settings > Configuration > Sales > Checkout > Checkout Options by setting Allow Guest Checkout to No.

That has a real cost, because some genuine customers will not create an account to buy. Treat it as an emergency brake during an attack rather than a permanent setting, and pair it with reCAPTCHA on account creation so the scripts cannot simply register their way round it.

It is worth being clear about this. The Magento settings and your payment gateway do most of the work against card testing. Hosting helps around them in two ways.

First, an attack leaves tracks in the web server logs: the same payment endpoints hit over and over. On EveryHost plans, Sentinel security monitoring reads those logs and can automatically block abusive IP addresses at the server firewall, and our engineers review every block, so a genuine customer caught by mistake can be let back in. Second, the people looking at those logs are Magento engineers, so when the pattern appears they can help you switch on reCAPTCHA and rate limiting, check your Magento version supports them, and point you at the gateway settings above.

What hosting cannot do is stop card testing on its own. Stripe's guidance says plainly that filters based on a single signal such as IP address are usually not enough, because card testers use many techniques to get round them. Blocking abusive IPs raises the cost of an attack; it does not replace reCAPTCHA, rate limiting and your gateway's fraud rules. Sentinel cannot see inside your payment provider either, and it is no substitute for keeping Magento patched.

If you want those engineers watching your logs, and a stack kept current enough to use the protections above, our managed Magento VPS hosting includes Sentinel and a UK team who work only on Magento.