Card testing detection is the practice of identifying rapid runs of small, low-value payment attempts that attackers use to check whether stolen card numbers are still valid. It relies on velocity rules, authorization-response analysis, device and network signals, and behavioral checks, and it works best when an automated response blocks the source before chargebacks and fees pile up.
Why card testing is easy to miss
Test charges are usually tiny, often under a dollar, so they sit well below the ticket sizes your manual review team watches. Each attempt looks like a normal low-value purchase on its own. The pattern only appears when you look across many attempts in a short window, from the same address range, the same device fingerprint, or the same set of card BINs.
Many merchants notice card testing only after a processor warning, a spike in declines, or a wave of chargebacks. By then the attackers have already validated a batch of numbers and moved on. Catching it earlier requires watching the signals that surround the transaction, not just the transaction amount.
Signals to watch in your payment data
- Decline spikes. A sudden rise in declines across many different card numbers from one source signals a batch being tested.
- Repeat small amounts. Many attempts at the same low value, or a series of values under a dollar, is a common testing pattern.
- Card velocity. One device or IP address trying several distinct card numbers in minutes.
- BIN clustering. Attempts concentrated on a narrow set of issuing BINs or a single country that does not match your normal customer base.
- Mismatched data. Email addresses, billing details, and cardholder names that do not correlate with each other.
- Checkout speed. Form completion times far below human norms, or paths that skip fields real customers fill in.
- New account, immediate purchase. Accounts created and used within seconds, especially with disposable email domains.
- Response codes. Concentrations of specific decline reasons such as invalid card number or do-not-honor responses.
Detection layers that work together
Velocity and threshold rules
Rules remain the fastest layer to deploy. Count attempts per card, per device fingerprint, per IP address, per email, and per billing address over rolling windows of minutes and hours. Set thresholds from your own baseline traffic rather than copying numbers from another merchant, then tune them as false positives appear.
Authorization response analysis
Every authorization response carries information. A run of specific decline reasons from one source is more telling than a single decline. Track the distribution of response codes per IP address and per device, and alert when one source produces a wide spread of card numbers with mixed outcomes.
Device, network and behavioral signals
Device fingerprints, proxy and VPN indicators, datacenter IP ranges, and browser characteristics add context that raw payment data cannot supply. Behavioral signals such as typing cadence, paste events in card fields, and time on page help separate automated scripts from real shoppers.
Machine learning scoring
Supervised models trained on your own confirmed fraud cases can rank attempts by risk before authorization. Use them as a scoring layer alongside rules, not as a replacement, and review model decisions against confirmed chargebacks so the ranking stays accurate.
A response playbook for a suspected attack
- Confirm the pattern. Pull attempts from the last hour by IP, device, and BIN to see whether the activity is a test run or normal low-value trade.
- Throttle the source. Apply rate limits or temporary blocks at the edge so automated scripts cannot keep submitting.
- Raise friction. Trigger a challenge on checkout for the affected segment and require stronger verification for new accounts.
- Notify your processor. Tell your acquirer or payment provider early so they can flag the activity on their side.
- Review approvals. Void or refund approved test charges before they become chargebacks where your policy allows.
- Document and adjust. Record the signals that fired and update rules so the next attempt is caught sooner.
Hardening checkout against automated attempts
- Add a bot challenge to the payment step, and load it only when risk signals appear so genuine customers see no delay.
- Enable 3-D Secure or an equivalent authentication step for high-risk segments, which shifts liability and adds a barrier to bulk testing.
- Require address verification and card verification value checks, and decline mismatches on low-value orders that fit the testing profile.
- Limit the number of payment attempts allowed per session, account, and device before a cooldown applies.
- Block or challenge traffic from datacenter ranges and known proxy networks when they do not match your customer base.
- Keep authorization logging complete enough to reconstruct an attack after the fact.
Metrics that tell you detection is working
Track decline rate by source, the share of attempts blocked before authorization, chargebacks tagged as fraud, average time from first suspicious attempt to block, and the false-positive rate on challenged orders. A drop in blocked attempts combined with a rise in chargebacks usually means attackers found a path your rules do not cover.
Where card testing detection fits in your fraud stack
Detection is one layer of a wider fraud program that includes authentication, chargeback management, and dispute analysis. Feed confirmed cases back into your rules and models, review the alerts weekly, and treat every processor notification as a signal that a detection gap exists somewhere in the checkout flow.