Card Testing

TL;DR

• Card testing (carding) = Small transactions to verify stolen card credentials
• Targets: donation pages, subscription services, digital goods, small merchants
• Detect via: multiple small amounts same IP, sequential card numbers, high decline rates
• Prevent with velocity rules, CAPTCHA, minimum amounts, 3D Secure
• Impact: authorization fees, processor reviews, network fines, later chargebacks

Validating stolen card credentials through small test transactions.

Definition

Card testing (or carding) is when fraudsters make small transactions to verify that stolen card credentials are valid before making larger fraudulent purchases.

How Card Testing Works

Common Testing Targets

Target	Why Chosen
Donation pages	Low friction, often no AVS verification
Subscription services	Small recurring amounts look legitimate
Digital goods	Instant delivery, no shipping verification
Small merchants	Less sophisticated fraud detection
Account funding	Test via adding payment method

Detection Signals

Transaction-Level

Signal	Risk Level
Multiple small amounts, same IP	🔴 High
Sequential card numbers	🔴 High
High decline rate from same device	🔴 High
Round dollar amounts ($1, $2, $5)	⚠️ Medium
Multiple cards, same shipping address	🔴 High

Velocity Patterns

Pattern	Threshold Example
Transactions per IP per hour	>10
Unique cards per IP per hour	>5
Declines per IP per hour	>3
Transactions per device per hour	>10

Impact Beyond Direct Loss

Card testing creates problems beyond the test transactions:

1. Authorization fees – You pay for declines
2. Processor attention – High decline rates trigger reviews
3. Network fines – Fraud ratio penalties (see network programs)
4. System load – Bot traffic strains infrastructure
5. Chargebacks later – Validated cards used elsewhere come back to you

Prevention Strategies

Technical Controls

1. CAPTCHA – On payment pages, especially donations
2. Rate limiting – By IP, device, session
3. Velocity rules – Block on pattern detection
4. BIN-level blocking – High-fraud BINs
5. Device fingerprinting – Identify repeat offenders

Transaction Rules

1. Minimum amount – $5+ reduces testing value
2. AVS requirement – Address verification
3. CVV requirement – Harder for card list fraud
4. 3D Secure – Shift liability, add friction

Monitoring

1. Real-time dashboards – Spot attacks quickly
2. Decline spike alerts – Abnormal decline rates
3. IP reputation feeds – Known bad actors

Response Playbook

When card testing attack detected:

1. Immediate: Enable CAPTCHA, tighten velocity rules
2. Short-term: Block offending IPs/devices
3. Analysis: Identify attack vector and weakness
4. Long-term: Implement permanent controls

Next Steps

Under card testing attack now?

1. Follow response playbook - Immediate actions
2. Enable CAPTCHA - Add friction
3. Tighten velocity rules - Block patterns

Preventing card testing?

1. Implement velocity limits - Set thresholds
2. Add device fingerprinting - Track offenders
3. Require CVV/AVS - Verification signals

Measuring card testing impact?

1. Track authorization fees - Know your costs
2. Monitor decline rates - Spot attacks early
3. Check fraud metrics - Network ratio impact

---

Related Topics

• Third-Party Fraud - Fraud using stolen credentials
• Velocity Rules - Primary defense against card testing
• Device Fingerprinting - Track repeat offenders
• AVS & CVV - Verification signals
• 3D Secure - Authentication and liability shift
• Decline Codes - Understanding test failures
• Network Programs - Fraud ratio thresholds
• Fraud Metrics - Measuring card testing impact
• Survive Fraud Attack - Attack response playbook
• Processor Rules Configuration - Setting up blocking rules
• Account Takeover - Related attack pattern
• Risk Scoring - Combining signals