Card testing: the attacker and the customer out of money leave the same trace

How it attacks

An attacker buys a batch of stolen cards on a forum. The problem is that they have no idea which ones are still alive. The numbers may be cancelled, expired, or already reported by the cardholder.

So they test them. A charge for the smallest amount the merchant will take, anywhere it goes through without friction. The ones that approve are worth keeping. The ones that decline get dropped without a second thought. The whole batch runs in minutes, sometimes seconds, from a single device.

That minimum charge is the inventory phase. The real fraud arrives later, when the attacker comes back to the few survivors with amounts that matter.

That is why a burst of minimum amounts with many declines is the classic card testing signature.

Who looks the same and is honest

Three customers leave an almost identical trace.

The student. Everything they buy sits at the bottom of your catalogue, several times a day. They get declined often because the account is at zero.

The customer who ran out of money. Payday is still days away. They try the grocery run and get declined. They try again for less. Declined. They try once more for even less, hoping something goes through. Consecutive declines and falling amounts, which is exactly what an attacker does while discarding cards.

The new user. They make a small purchase first, to check the app really works. They misread the card, type the CVV wrong, get declined, and wait a while before retrying because it feels embarrassing.

All three produce exactly what the rule is looking for: minimum amounts, consecutive declines, retries.

Blocking that pattern blindly cuts off the student and the person waiting to get paid. In a credit business, those two are the ones who come back every month.

What actually separates them

• Number of cards. The attacker runs through a whole batch of different numbers. The three twins use one, two at most.
• Time between attempts. Seconds in the attack. Minutes or hours for everyone else, because there is a human reading an error on a screen.
• Decline reason. Insufficient funds for the customer with no money. Invalid data or a cancelled card in the attack.
• Prior history. The student has been buying the same things for months. The attacker's cards have not been with you for a single day.
• Why the amount drops. The customer lowers it because they are adjusting to what might go through. The attacker lowers it because they switched cards.

A new customer, with no history and a decline for mistyped data, shows up every day. Several of these signals have to land on the same case at once.

How it mutates once you detect it

This is where the rule ages. Every door you close, the attacker tries the next one.

1. You block on low amounts. The attacker raises the test into your normal range. Burning a card costs a bit more, and it still works.
2. You block on attempts per minute. They spread the batch across two days.
3. You block on device. They change device. Browser fingerprints are faked with tools built for it, and an emulator spins up a different machine on every attempt.

Every mutation makes them slower and more expensive. An attack that used to take ten minutes and now takes two days is an attack you can watch while it happens.

The rule that cuts almost all card testing today will cut half of it in a few months. On the other side there is someone measuring their own results just like you do.

Closing

The work is cutting card testing without sending the bill to the student. That depends on how much history you hold on each customer at the moment you decide.

So how do you solve it?

Tuning this by hand takes days, and every day costs chargebacks and good sales. That is what we are solving at Frauddi. We will show you on your own data.

Book a free demo

Next: velocity, the attacker draining a card before it gets reported, and the shop owner making fifteen purchases in two hours (2 of 9).