Card testing attacks: what small business websites should know

If your website takes card payments, there is a quiet kind of fraud that can hit you without a single real customer being involved. It is called card testing, or carding, and the first sign is often a pile of failed payments you do not recognise. This post explains what it is, what it can cost, and the sensible steps to take this week, most of which you can hand to whoever built or runs your site.

What card testing is

Stripe describes card testing as fraudulent activity where someone tries to find out whether stolen card details are valid so they can use them to make purchases. They run scripts that try huge numbers of card numbers at once and collect the responses to see which cards still work. Once they know which are valid, the cards can be used elsewhere or resold.

Your site is not the target because of who you are. It is a convenient place to check cards. Stripe says testers use two routes: saving a card (which often does not show on a cardholder's statement, so the real owner may not notice) and making small payments that cardholders are less likely to spot.

How common it is for UK small firms

Research commissioned by payments company Mollie, covering 2024, put the average loss at about £10,800 per UK small or medium business, across an estimated 5.5 million firms. In that research 23% of businesses said they had faced carding attacks, where stolen cards were tested at checkout and caused spikes in failed transactions. Another 26% had chargebacks on legitimate transactions, and businesses reported spending an average of 15 days a year dealing with fraud. Treat these as survey figures from a company that sells payment services, not as a precise measure: the page does not give the sample size or method.

Why it matters even if the fraud itself fails

You might think that if the payments fail, no harm is done. Stripe's guidance lists several consequences:

• Disputes. Some test payments succeed. Cardholders notice them and report fraud, which can mean early fraud warnings or disputes that cost you time and money.
• Higher decline rates. A large number of declines can damage your reputation with card issuers and networks, which can make genuine payments look riskier, even after the attack stops.
• Extra fees. Attacks can bring additional charges, such as authorisation fees on custom pricing plans and dispute fees.
• Strain on your site. Large numbers of automated requests can overburden your infrastructure and slow down your checkout for real customers.
• Muddy data. Test activity can look like new customers, so your figures stop reflecting real growth.

How to spot it

Stripe says most attacks are obvious in the dashboard. Look for:

• A sudden spike in failed or blocked payments.
• A spike in card errors and generic declines in your developer logs.
• Lots of low value payments with nonsensical customer names and email addresses.

These are Stripe's dashboard signs; if you use another provider, ask where to find the failed payment trend. Make a habit of checking it weekly, or ask your developer to set an alert.

What to do if you are being hit now

Stripe's active attack checklist has four steps:

• Identify the activity.
• Refund fraudulent payments that got through, to avoid disputes.
• Switch to a recommended integration or add controls to suppress the testing.
• Keep monitoring to make sure the controls work.

If you have done this and the attack continues, contact your payment provider's support. Do not keep retrying cards that were added by fraudulent customers, because Stripe warns that this repeats the original attack.

How to reduce the risk

Stripe is clear that simple filters, such as blocking one IP address, are usually not enough, because attackers vary their methods. It recommends layers:

• Use a recommended checkout. If you use Stripe's latest Payment Element or Checkout, it includes rate limiters, AI models and CAPTCHA triggers, though how well they work depends on the information your site passes along, such as IP address, email, name and billing address.
• Add a CAPTCHA. Automated scripts are often stopped by one, but it has to be checked on the server side and on every request that can validate a card or take a payment.
• Limit access to the payment form. The easier it is to reach, for example through guest checkout, the easier it is to attack. Requiring a login or session check can help.
• Add rate limits. For example, limiting how many new customers one IP address can create in a day.
• Set rules on unusual behaviour. Such as limiting cards per account or purchases of the same product, using tools like Radar if your plan includes custom rules.
• Combine them. For instance, let the first attempt from an address through, then require a CAPTCHA for later attempts for several hours.

Stripe also adds a caveat that matters: none of this guarantees no card testing will happen, and if you use a plugin or platform, prevention typically needs code level changes. Stripe's advice is to show its documentation to the developer or vendor who wrote the code. If you are on a hosted platform, ask the provider what protection is switched on and whether a checkout CAPTCHA is available.

Keep your keys private

There are two kinds of keys on a Stripe integration. The publishable key is designed to sit in a web page, and testers can use it to retry payments. The secret key is like a password: if it leaks, Stripe says unauthorised parties can make charges, access customer data or disrupt your integration. Its guidance is to keep secret keys out of source code and apps, store them in a secrets vault or environment variable, use restricted keys with limited permissions, rotate them periodically, and rotate immediately if one is exposed, even if you are not sure anyone saw it. Stripe also states that it never asks you for your secret key, so treat any such request as a scam.

A checklist for this week

• Open your payment dashboard and look at failed payments over the last month. Note what normal looks like.
• Ask your developer or platform which checkout protections are on, and whether a CAPTCHA and rate limits are in place.
• Ask who has access to your secret keys, and when they were last rotated.
• Decide who gets the alert if failed payments spike, and who will refund suspicious payments.
• Confirm that guest checkout is genuinely needed for every product.

If your checkout needs tightening, or you want payment monitoring set up properly, our ecommerce team can help. A few small checks now are far cheaper than clearing up a wave of disputes later.