Card Testing Attack Case Study: Stopped Before a Dollar Was Lost
The Short Version
- A store we manage started stacking up failed orders fast: over 100 in one week on a store that normally sees almost none.
- It was a card testing attack. Bots run stolen card numbers through a live checkout to find out which ones still work.
- Every attempt was declined. No chargebacks, no lost revenue, no frozen merchant account.
- The attack was hitting the server directly, so a firewall or CDN rule alone was never going to stop it. The fix had to live at the checkout.
- Bot verification, gateway fraud controls, and round the clock monitoring shut it down and keep it shut.
What’s In This Case Study
What happened
One of the online stores we manage started quietly piling up failed orders. Not one or two. Dozens, over the span of a few days.
If you’re running a store, a handful of failed orders barely registers. Expired card, wrong billing zip, somebody changed their mind at the last second. That’s a normal Tuesday.
Our monitoring flagged the pattern before anyone had a reason to go looking for it. And the shape of that pattern told the whole story.
What we found: a textbook card testing attack
Here’s how it works. Fraudsters get hold of a list of stolen credit card numbers. They have no idea which ones are still active, so they need somewhere to check. They find a real store with a working checkout and push the numbers through it, one after another, in rapid fire. The ones that go through are live and worth money. The ones that decline get thrown away.
They’re not trying to buy anything from you. To them, your checkout is nothing more than a free card validation tool that somebody else is paying to run.
The fingerprints were unmistakable:
- Over 100 failed orders in a single week, on a store that normally sees almost none
- The same small dollar amount, charged over and over and over
- Fake names paired with throwaway email addresses (think [email protected])
- Orders firing seconds apart, in machine gun bursts
Want the full breakdown of how these attacks work and what to watch for on your own store? We covered that here: Card Testing Attack? How to Spot and Stop It on Your Store.
The good news first
Every fraudulent attempt was declined. Not one stolen card was successfully charged, which meant no chargebacks and not a dollar out of our client’s pocket.
We confirmed that before we touched anything else, because when your store is under attack, that’s the only question that actually matters. Everything after it is cleanup.
Why a card testing attack still hurts when the charges fail
Here’s the part most store owners don’t know. Card testing isn’t harmless just because the cards get declined.
- Every single attempt can rack up payment processing fees, and those add up quickly at a hundred attempts a week
- A flood of declines can get your merchant account flagged, frozen, or shut down by your payment processor
- If even one live card slips through, that’s a real charge on a stolen card, and a real chargeback landing on you weeks later
Worth knowing
Your payment processor watches your decline rate. If a bot drives it high enough, you can lose the ability to take payments at all, and you didn’t do a single thing wrong to earn it.
What we did about it
One discovery shaped the entire fix: the attack was hitting the store’s server directly. That meant a firewall rule or a CDN filter was never going to catch it. The protection had to live where the checkout actually runs.
So we layered it.
- Human verification at checkout. We added a step that automated bots can’t pass, so orders stop getting submitted by scripts.
- Gateway fraud controls switched on. The payment gateway’s own tools now decline on address and security code mismatches, and throttle rapid repeat attempts from the same source.
- Ongoing automated monitoring. If another wave starts, we get an alert within the hour instead of hearing about it from the processor.
Where things stand now
The attack is shut down. The checkout is hardened against the next one. And the store has round the clock monitoring watching for a repeat performance.
All of it wrapped up before a single dollar was lost and before the merchant account was ever at risk. Our client’s job was to keep running their business. Our job was to make sure nothing on the website got in the way of that.
What this means for your store
Most store owners never find out they’re being used for card testing until the payment processor sends a warning letter, or freezes the account outright. By then you’re not fixing a website problem. You’re fighting to get your ability to take payments back.
Catching it early, and knowing exactly where the fix belongs, is the difference between a non event and an expensive mess.
That’s the kind of thing we watch for, so you don’t have to.
Is Anyone Watching Your Checkout?
If your store is running without monitoring, you wouldn’t know a card testing attack was happening until your processor told you. Our care plans include 24/7 monitoring, security hardening, and real people who pick up the phone. We manage 105+ active client sites, and this is exactly the kind of thing we watch for.