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

Card testing (or carding) is when fraudsters run small $0.50-$5.00 transactions to find out which stolen card numbers still work. They pick donation pages, subscription services and small merchants because those usually don't have velocity controls. You'll see it as a burst of small charges from one IP, and you'll stop it with velocity rules, CAPTCHA and a minimum order amount.

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

The test transactions aren't the expensive part. Here's what else it costs you:

1. Authorization fees - You're billed for every decline
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 you're under attack:

1. Immediate: Enable CAPTCHA, tighten velocity rules
2. Short-term: Block offending IPs/devices
3. Analysis: Find the hole they're using
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
• Data Enrichment - Datacenter IP and bot detection signals
• 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