Stolen card details are sold in bulk, and many of them no longer work: the card has been cancelled, the details were typed wrongly, or the bank has already spotted the leak. So before a fraudster spends a card, they test it. They make a very small payment somewhere that will not attract attention, and if it goes through, the card is "good".
The place they test is often a fintech, a small online shop or a donation page: anywhere that accepts card payments quickly and does not look closely at small amounts. If that is your checkout, you pay for it twice. You carry the fees and disputes on the test payments, and the card schemes and your payment partners notice the rise in declines and chargebacks.
What card testing looks like
The pattern is distinctive. A burst of very small payments arrives in a short window, many of them declined. Usually it is automated: a script trying card after card. The few that succeed are noted, and the real spending happens later, often somewhere else entirely.
The signals
- Many very small payments in a short time from the same customer, account or device.
- A high share of declines. Real customers occasionally mistype a card. Scripts testing stolen ones fail again and again.
- Amounts that make no sense for your product, such as payments far smaller than anything you normally sell.
- Activity at odd hours or at a speed no person typing by hand could manage.
Why simple fixes backfire
The obvious response is to block small payments, or add a hard limit on attempts. Both hurt real customers. Plenty of honest payments are small, and a customer whose card was declined for a good reason will try again. The aim is to stop the burst, not to make every small payment suspicious.
That means looking at velocity (how many payments in how short a time) and outcome (how many failed), together, for the same customer or device. One small payment is normal. Ten in a few minutes, most of them declined, is not.
Mistakes we see
- Reacting after the chargebacks arrive. By the time disputes come back, the testing happened weeks ago. Detection has to happen during the burst.
- Counting only successful payments. Declines are the clearest signal of testing. If your fraud checks never see them, they miss the attack.
- One global limit for everyone. A limit tight enough to stop scripts frustrates real customers. Limits work better tied to the behaviour of each account.
A checklist for your team
- Declined payments are sent to your fraud checks, not just approved ones.
- You can see payments per customer and per device over the last few minutes and the last hour.
- You know the smallest amount a real customer normally pays you.
- A burst of tiny payments raises one alert, not hundreds.
- Confirmed card-testing cases are recorded against the transactions.
Where ArcheaOne fits
Card testing is a race: the burst is over in minutes. ArcheaOne, a real-time fraud detection platform built for African fintechs, is designed to catch it while it is still happening.
- Attacks spotted during the burst, not weeks later in a chargeback report.
- The attacker stopped while your real customers keep paying.
- One alert with the full picture, so your analyst can act in seconds.
Want to see how it handles your traffic? Request access to ArcheaOne.