If your website has just taken a burst of small card payments, most of them declined, from names you do not recognise, you are almost certainly looking at card testing. Someone is running stolen card numbers through your payment form to find out which ones still work. The fix is not complicated, but it needs doing quickly, and it involves both your website and your payment provider.
This week we dealt with it on a charity’s donation form. In one evening the form received several hundred £1 donations from hundreds of different internet addresses, using two made-up donor names. Most were declined, some went through, and every declined card sent the charity a failed payment email. The first anyone knew about it was an inbox full of those emails the next morning.
What card testing is
Criminals buy lists of stolen card details in bulk. Many of the cards on the list are already cancelled, so before using or reselling them they need to sort the live cards from the dead ones. The cheapest way to do that is to find a website with a payment or donation form and push the whole list through it with a script. Stripe describes it as trying to determine whether stolen card information is valid so it can be used for purchases, and notes that the amounts are kept small precisely so cardholders are less likely to notice.[1]
Your site is not being targeted because of who you are. It is being used because the form was reachable and did not push back. Donation forms are a favourite because any amount is accepted, there is no stock to check and nothing needs delivering.
Why it costs you even when the payments fail
It is tempting to treat a run of declined payments as noise. It is not, for four reasons Stripe sets out in its own guidance.[1]
The payments that succeed are on stolen cards. The real cardholders will spot them and dispute them, and each dispute costs you a fee and time, whatever the amount. A high decline rate also damages your reputation with the card networks, which can lead to more of your genuine customers being declined later. Some providers charge per authorisation attempt, so hundreds of failed attempts can cost money directly. And if the attack goes on long enough, the card networks can place your business on a monitoring programme.
There is a quieter cost too. Every attempt creates a record in your website, an email to your team and, for a charity, a fake donor in the database. Cleaning that up later takes longer than stopping it now.
How to tell it is happening
Look for a spike in failed or blocked payments in a short window, often overnight. The amounts will be small and identical, £1 or 50p is typical. The customer names and email addresses will look random or repeat across many attempts, and the attempts will come from many different internet addresses rather than one. If you use Stripe, the Dashboard home page and the payments list make this obvious, and the failed logs will show a run of generic declines.[1]
Stopping it: the website side
The form has to be able to tell a person from a script, and most payment plugins cannot do that on their own. The plugin on the charity’s site had a honeypot field, the usual trick of a hidden box that only bots fill in, and the attacker’s script sailed past it.
What stopped it was putting Cloudflare Turnstile in front of the donation request. Turnstile is a free bot check that runs in the background: a real donor sees nothing, or at most a brief tick box, while an automated script cannot get a valid token and its payment request is refused before the card is ever sent to the provider.[2] The important detail is where the check sits. It has to be verified on the server when the payment is submitted, not just drawn on the page, otherwise the script simply posts straight to the endpoint and skips it.
While you are there, turn off any email alert that fires on every failed payment. A notification that sends three hundred times in an evening is not telling you anything after the first one, and it buries the messages that matter.
Stopping it: the payment provider side
Whoever handles your card payments has fraud controls, and they are often switched off or left on defaults. In Stripe they live under Radar, and Stripe’s own advice for an active attack is to identify the activity, refund the fraudulent payments that got through so they do not become disputes, add mitigations, then keep monitoring to make sure they are working.[1] Other providers have equivalents. The two questions to ask are whether card testing protection is turned on, and whether you are alerted when the decline rate jumps.
Refunding the successful payments is the step people skip because the money looks like income. It is not. It is a stolen card, and a refund now is cheaper than a dispute in a month.
A short checklist
Check your payment dashboard for a spike in small failed payments. Put a server-verified bot check such as Turnstile in front of every payment and donation form. Turn on your provider’s card testing and fraud rules and make sure someone receives the alerts. Refund anything that got through. Then tidy up the fake records so your reporting stays honest.
If you are not sure whether your site’s forms are protected, or you have already had the flood of emails, get in touch with BMT. It is usually an afternoon’s work to close it off properly. The NCSC’s small business guide covers the wider basics of keeping a small organisation safe online and is a sensible next read.[3]
Sources
[1] Stripe: Protect yourself from card testing