Kavra LabPOST /donate/chargeBlockedScript cycling cards on a $1 donation
- Same actor, 38 cards in 10 min
- Automation behind a real browser
- New proxy exit per attempt
Risk98
Solution
Card testing attack prevention that stops bots before authorization
A card testing attack is when bots run many small or zero-value payments on a merchant's site to learn which stolen card numbers are still valid, then use or sell the working ones elsewhere. Kavra recognizes the automation, proxies and repeated devices behind the attempts, so you stop them before they reach your payment processor.
- Who it hits
- Any site that takes cards, especially low-price ones
- What it costs
- Auth fees, disputes, processor penalties
- Tools used
- Checker scripts, headless browsers, proxy pools
- Where to stop it
- Before the authorization request is sent
What is card testing?
Card testing, also called card checking and closely tied to carding, is how criminals find out which stolen card numbers still work. A list of cards bought on a criminal marketplace contains many that are expired, blocked or already reported. Testing sorts them: each card is tried with a tiny payment or a zero-value check, and the ones that are approved become far more valuable, either for resale or for bigger payment fraud somewhere else.
The merchant used for testing is rarely the final target. It is chosen because its checkout is easy to automate and each attempt is cheap: a donation form, a low-price digital item, a free trial that asks for a card, or an "add payment method" page. The attacker does not care about what they buy. They care about the answer from the issuer.
How a card testing attack runs
- 01
Find a weak checkout
Attackers look for a payment step with no login, no rate limit and small amounts. Some skip the page entirely and call the payment endpoint the page uses.
- 02
Load the card list
A checker script takes a list of stolen cards, or generates candidates from one bank identification number in a BIN attack, cycling through card numbers, expiry dates and security codes.
- 03
Spread the attempts
Requests go out through residential proxies and fresh browser sessions, so no single IP address or cookie shows many tries.
- 04
Read the results
Approvals, and even specific decline reasons, tell the script which cards are live. Some attacks run for minutes, others trickle for days to stay under alert thresholds.
- 05
Cash in elsewhere
Validated cards are sold at a premium or used for high-value purchases on other sites, while the testing merchant deals with the fallout.
Card testing vs BIN attacks
Both hit your checkout the same way, but they start from different data. In classic card testing, the attacker already has full card records and only needs to know which ones are alive. In a BIN attack, the attacker has only the first digits that identify the issuing bank and guesses the rest, which produces huge volumes of declines with the occasional approval.
BIN attacks tend to be louder and more obviously scripted. Card testing with real card lists can look like a steady stream of normal small orders. Both are stopped the same way: by recognizing the actor and the automation, not by judging each card in isolation.
What card testing costs the merchant
The amounts are small. The consequences are not.
| Cost | What happens | Why it hurts |
|---|---|---|
| Authorization fees | Many processors charge per attempt, approved or declined | Thousands of attempts add up to a real bill |
| Disputes and refunds | Cardholders notice small unknown charges and dispute them | Each dispute adds a fee and raises your dispute ratio |
| Processor relationship | Spikes in declines and fraud trigger reviews | Higher fees, rolling reserves, or a closed merchant account |
| Network monitoring | Card networks track merchants with excess fraud and disputes | Fines and remediation plans passed down by the acquirer |
| Lower approval rates | Issuers start to distrust your merchant ID | Real customers see more declines on good cards |
| Team time | Refunds, reconciliation, support tickets | Hours spent cleaning up after a weekend attack |
Signs you are being used for card testing
Attacks often start at night or on weekends, when nobody is watching the payment dashboard.
A spike in declines
Decline rates jump, often with reasons like invalid number, wrong security code or expired card, outside your normal sales hours.
Many tiny payments
Clusters of the smallest donation amount, the cheapest item or zero-value card checks, with no other activity in the session.
Sequential or related cards
Card numbers that share the first digits, or the same card tried with different expiry dates and codes.
Throwaway identities
Random names, mismatched billing addresses and disposable emails, changing on every attempt.
Checkout with no shopping
Sessions go straight to payment, fill the form at machine speed and leave, or call the payment API with no page view.
One actor, rotating disguises
Each attempt arrives with a new IP and fingerprint, but the device underneath is the same.
Why common card testing defenses fail
Most merchants already run some of these checks. Each one covers a single layer, and checker scripts are tuned to slip between them.
| Defense | The gap attackers use |
|---|---|
| Per-IP rate limits | Residential proxy pools give every attempt a different home IP |
| Velocity rules per card | Each card is tried once or twice; the volume is across cards |
| CAPTCHA on checkout | Solving services pass it cheaply, and real buyers pay the friction |
| Minimum order amounts | Attackers move to zero-value checks or the add-card page |
| Processor fraud screening | It scores each card, but a clean stolen card still looks clean |
| Blocking by country | Proxies exit in your own market |
How to prevent card testing attacks
The cheapest place to stop card testing is before your server asks the processor anything. Every refused attempt then costs nothing and tells the attacker nothing.
- Assess every payment attempt, including zero-value checks, saved-card additions and trial signups that take a card.
- Require a fresh, single-use token from the page for each payment call, so scripts cannot hit the endpoint directly.
- Count attempts per actor, not per IP or per card: one device trying many cards is the core signal.
- Recognize proxy traffic and automation even when each request looks like a new visitor.
- Return the same generic message for every refused attempt, so the script cannot learn why it failed.
- Watch decline rates by hour and alert on spikes, and keep your processor informed during an attack.
- Mark confirmed attackers as bad, so their devices are recognized on the next wave.
Sources
How Kavra helps
How Kavra stops card testing
Kavra checks every payment attempt with 3,000+ data points and gives your backend a clear verdict before you call the processor.
Automation detected
Headless browsers, stealth plugins and HTTP clients imitating browsers are caught by contradictions between what they claim and how they behave.
One actor, many cards
Fingerprint rotation is treated as a signal, so a device cycling through cards and disguises stays one actor with many attempts.
Proxy intelligence
Kavra measures real exit IPs of commercial residential and mobile proxy networks, so rotating home IPs do not reset the count.
Tokens bound to the payment
Signed, single-use, short-lived tokens tie each assessment to one payment action. Replays are refused and reported.
Campaign detection
Surges of new devices, shared infrastructure and velocity anomalies reveal an attack in progress, even when it trickles slowly.
Act in real time
Refuse attempts before authorization, get webhooks during an attack, and start in observe-only mode to see it first.
FAQ
Frequently asked questions
Something else? Talk to our team.
Why do fraudsters make small charges with stolen cards?
Small charges are the cheapest way to confirm a card works without alerting the cardholder or the bank. A one-dollar donation or a zero-value card check rarely stands out on a statement. Once a card is confirmed live, it is sold at a higher price or used for large purchases on other sites.
Am I liable for card testing attacks?
For approved test charges that are later disputed, the merchant usually bears the chargeback and fee. Declined attempts can still cost authorization fees. Beyond direct costs, high decline and dispute rates can lead your processor to raise fees, hold funds or close the account, so the practical liability falls on the merchant.
Should I refund card testing charges?
Usually yes, and quickly. Refunding confirmed test charges before the cardholder disputes them avoids chargeback fees and keeps them out of your dispute ratio. Then stop the source, because refunds do not prevent the next wave. Check your processor's guidance, since some recommend specific steps during an active attack.
Why are donation pages targeted by card testers?
Donation forms let the payer choose a tiny amount, often need no account or shipping address, and are built to be as frictionless as possible. That makes them ideal for fast automated attempts. Nonprofits also tend to have fewer fraud tools than large retailers, which attackers know.
Can I detect card testing from payment data alone?
Only after the fact. Payment data shows spikes in declines and small approvals, but by then the fees and issuer damage have happened. Device and network evidence identifies the bot and the repeat actor before the authorization request, so refused attempts never reach the processor at all.
See who is really on your site.
Run Kavra on your own traffic in observe-only mode. No risk to your customers, and a clear report of the fraud it finds.