Card testing is when a bot pushes lots of stolen card numbers through a cheap checkout to see which ones work. Sites that sell low-priced digital products are a common target, because the purchase costs little and nothing has to be delivered for the bot to learn that a card is live. Your site has several protections against this, and they are always on. There is nothing to set up.
What your site does automatically
Limits on how fast one visitor can go
Loading the checkout page, adding to the cart, applying a coupon, starting a guest checkout, confirming a free order, searching and signing up all have a limit per visitor. A real person never notices the limits. A bot repeating the same action in a loop runs into them quickly.
Lockout after repeated failed payments
Each payment attempt records the visitor's IP address. When Stripe tells your site a payment failed, the failure is counted against that IP address and that email address. After 5 failures in an hour, that IP address or email cannot open checkout until the hour is up. The payment attempt they were using is also cancelled in Stripe, so it cannot be reused to try more cards.
A pause when many different visitors fail
Bots change IP addresses and emails, so failures from everyone are counted too. If 30 payments fail across the whole site within 15 minutes, checkout pauses for a few minutes and a warning is written to the site log. A normal site sees a couple of declined cards a day.
Checks on registration
Sign-up blocks disposable email addresses and uses a hidden field and a timer to catch bots. Login and password-reset attempts are limited as well. See the guide on anti spam on registration for the details.
If the protection cannot run
If the folder that holds the counters cannot be written, your site lets visitors through instead of showing an error. A broken cache never stops a real customer from buying.
Guest checkout stays on
Customers can buy with just an email address and first name, and an account is created for them after they pay. The protections above are what sit between guest checkout and a card-testing run.
One thing to check in Stripe
The lockout relies on Stripe telling your site about failed payments. In your Stripe dashboard, under Developers and Webhooks, open your site's endpoint and make sure payment_intent.payment_failed is ticked, along with payment_intent.succeeded and checkout.session.completed. Without the failed-payment event, failures are never counted.
If a real customer is locked out
They see a message asking them to wait an hour, and the lockout ends by itself. It can happen when a customer mistypes their card several times, or when several people share one internet connection, such as an office or a school. If someone contacts you, ask them to wait an hour and try again.
Extra protection in Stripe
Stripe Radar, in your Stripe dashboard, is a further layer. Its basic screening comes with normal card payments. Custom rules, such as blocking when the card's country differs from the buyer's country, belong to a paid plan, so check the current price in your Stripe dashboard. If you are ever hit by a card-testing attack, refund the suspicious payments straight away. A cardholder who notices a charge they did not make can dispute it, and a dispute carries a fee, so an early refund usually saves you that.