Card Testing

How Card Testing Works

Card testing is a low-cost probing method for fraudsters. They submit many payment credentials in tiny or low-risk authorisations to separate active cards from declined, blocked, or already-cancelled ones, then keep only the cards that still appear usable.

The technique relies on the economics of scale rather than a single high-value purchase. Even a small success rate can be profitable if the attacker can automate attempts and reuse the valid credentials elsewhere.

Why Card Testing Matters to Merchants and Payment Flows

Card testing is dangerous because the visible transaction is often not the real objective. The immediate loss may be small, but successful validation can feed later fraud, increase chargeback exposure, and create operational noise in payment systems and fraud queues.

It also distorts normal payment signals. High attempt volumes, repeated failures, and short bursts of seemingly harmless authorisations can look like routine checkout traffic unless teams watch for velocity, repetition, and unusual acceptance patterns across the same entry point.

A practical defence is to understand the abuse path end to end, from form submission to authorisation decision. NHIMG’s Card Testing and Carding Attacks Defence Guide covers the checkout and form-defence signals that typically reveal this pattern.

Common Abuse Patterns and Detection Signals

Card testing often shows up as many small authorisations, repeated retries, or bursts from one account, device, IP range, or payment form. Attackers may rotate cards, spread attempts across bins, or move across merchants to avoid simple threshold rules.

Defenders usually look for failed-to-successful ratios, unusual velocity, synthetic or repetitive data entry, and low-value authorisation attempts that are inconsistent with normal shopping behaviour. Screening is stronger when these signals are correlated across device, network, and payment intelligence rather than judged in isolation.

Payment-fraud teams also benefit from treating card testing as part of a broader fraud ecosystem. NHIMG’s Payment Fraud Guide places card testing alongside card-not-present fraud, chargebacks, and BIN attacks, while Top 10 Online Fraud Attacks helps readers position it within the wider threat landscape.

Controls and Response When Card Testing Is Suspected

Effective response usually combines friction, filtering, and payment-path hardening. Controls such as velocity limits, bot detection, CAPTCHA or challenge steps, card verification logic, and risk-based payment decisions help reduce the attacker’s ability to validate cards at scale without creating excessive friction for legitimate customers.

Where the pattern is already visible, teams should investigate the traffic source, the affected checkout or donation path, and whether the same campaign is probing multiple payment endpoints. If testing is confirmed, the priority is to stop validation abuse quickly, preserve payment logs and fraud telemetry, and tune thresholds so the control response fits the attack volume without creating avoidable false declines.

Risk and Threat Considerations

Card testing is often a precursor activity, not the final crime. Once attackers know which cards still work, they can sell them, reuse them for card-not-present fraud, or broaden the campaign to other merchants and payment flows.

Failure mechanism: The attacker exploits low-friction authorisation paths and small-amount transactions to separate valid credentials from invalid ones while staying beneath weak velocity or fraud thresholds.

Impact: Organisations can see higher fraud losses later, more chargebacks, degraded payment trust signals, and a noisier detection environment that makes genuine abuse harder to distinguish from normal checkout traffic.

Practitioner Guidance

What to watch for: Treat repeated low-value approvals, bursts of near-identical payment attempts, and unusual failure-to-success patterns as a payment abuse problem, not just a checkout anomaly. The most useful operational question is whether the same behaviour would still look harmless if it were repeated at scale across several merchants or endpoints.

Governance implication: Ownership should sit with fraud, payments, and security together, because the right threshold or challenge step depends on both fraud economics and customer-experience impact. A control that is too loose invites validation abuse, while one that is too strict can suppress legitimate revenue.

Related resources from NHI Mgmt Group

• How should fraud teams distinguish card testing from account takeover?
• Why do payment workflows create special risk for automated card testing?
• What breaks when card testing controls are too focused on individual transactions?
• Why do bots make card testing harder to stop than manual fraud?