Card Testing Attacks: How Fraudsters Validate Stolen Cards on Your Checkout

Your Stripe dashboard lights up with dozens of $0.50 charges in the span of ten minutes. Most of them are declined. A few go through. By the time you notice, the damage is already done: stolen cards have been validated on your checkout, and the chargebacks are on their way.

This is a card testing attack, and it is one of the most common forms of payment fraud targeting online businesses today. If you accept credit card payments, you are a potential target.

What Is Card Testing?

Card testing, sometimes called "card checking" or "carding," is the process fraudsters use to verify whether stolen credit card numbers are still active and usable. The cards typically come from data breaches, phishing campaigns, or dark web marketplaces where stolen card data is sold in bulk.

The logic is straightforward. A fraudster buys a batch of 10,000 stolen card numbers. Before using them for high-value purchases, they need to know which ones actually work. So they find a website with a simple checkout flow and run small transactions against it to separate the live cards from the dead ones.

Your checkout page is the testing lab. You are not the end target. You are the tool.

How Card Testing Attacks Work

A typical card testing attack follows a predictable pattern:

1. Acquiring Stolen Card Data

Fraudsters obtain card numbers through breaches, skimming devices, or bulk purchases on dark web forums. A batch of 10,000 cards might cost as little as $100, making the economics work even if only 5-10% of cards are still valid.

2. Choosing a Target

Attackers look for checkouts with specific characteristics:

• No CAPTCHA or bot protection on the payment form
• Low minimum transaction amounts that won't trigger fraud alerts
• Simple checkout flows without address verification or multi-step validation
• Donation pages and subscription forms where small recurring amounts look normal
• Free trial signups that require a card on file

If your site matches these criteria, you are an attractive target for card testers.

3. Running Automated Tests

Using scripts or botnets, the attacker submits hundreds or thousands of small transactions in rapid succession. These charges are typically between $0.50 and $2.00, small enough to avoid triggering most fraud detection thresholds.

Each transaction response tells the fraudster something:

• Approved: The card is valid and has available funds
• Declined (insufficient funds): The card is valid but empty, still useful for future attempts
• Declined (invalid number): The card is dead, discard it
• Declined (expired): The card was once valid but is no longer active

4. Monetizing Valid Cards

Once the attacker has a list of confirmed working cards, they sell them at a premium on fraud marketplaces or use them directly for high-value purchases, gift card fraud, or money laundering schemes.

BIN Attacks: A More Targeted Variant

A related technique is the BIN attack (Bank Identification Number attack). Instead of testing stolen cards, the attacker generates card numbers algorithmically.

Every credit card number starts with a 6-8 digit BIN that identifies the issuing bank and card type. The remaining digits follow a pattern that can be validated using the Luhn algorithm. An attacker who knows a valid BIN can generate thousands of plausible card numbers and test them against your checkout to find ones that happen to match real accounts.

BIN attacks are particularly dangerous because they don't require any stolen data to start. The attacker only needs to know a valid BIN, which is public information.

Warning Signs of Card Testing

Catching card testing early limits the damage. Here are the signals to watch for:

Velocity Spikes

The most obvious sign is a sudden surge in transaction attempts. If your checkout normally processes 50 transactions per hour and suddenly receives 500, something is wrong. This applies to both successful and failed transactions.

Small Transaction Amounts

A cluster of transactions at $0.50, $1.00, or other round small amounts is a red flag. Legitimate customers don't typically make multiple sub-dollar purchases in rapid succession.

High Decline Rates

If your authorization decline rate jumps from a normal 3-5% to 40% or higher within a short window, you are likely being tested. The high failure rate reflects the attacker cycling through invalid cards.

Same IP, Different Cards

One of the clearest indicators. A single IP address submitting transactions with 20, 50, or 100 different card numbers within minutes is almost certainly a card testing bot. Legitimate customers use one or two cards at most.

Mismatched Data

Test transactions often have random or nonsensical billing information. Watch for mismatches between the card's country of origin and the IP geolocation, generic names in the billing fields, and addresses that don't pass AVS (Address Verification System) checks.

Sequential Card Numbers

BIN attacks sometimes generate card numbers in sequence. If you see authorization attempts with card numbers that increment by small amounts, it is a BIN attack in progress.

The Real Cost of Card Testing

Card testing might seem harmless since most charges are tiny. But the costs add up fast:

• Transaction fees: You pay processing fees on every authorization attempt, even declined ones. At $0.30 per attempt, 1,000 test transactions cost you $300 in fees alone.
• Chargebacks: The small charges that do go through will eventually be disputed by the real cardholders. Each chargeback costs $15-25 in fees on top of the refund.
• Chargeback rate damage: Card networks monitor your chargeback ratio. If it exceeds 1% of transactions, you face fines, increased processing rates, or account termination by your payment processor.
• Infrastructure strain: High-volume bot traffic consumes server resources and can degrade checkout performance for legitimate customers.
• Reputation damage: Getting flagged as a high-risk merchant affects your ability to work with payment processors and can increase your rates permanently.

Prevention Strategies

Stopping card testing requires multiple layers of defence. No single measure is enough on its own.

1. Velocity Limiting

Implement rate limits on your payment endpoints. Practical thresholds to start with:

• Per IP address: Maximum 5 transaction attempts per 10 minutes
• Per card number: Maximum 3 attempts per hour
• Per email address: Maximum 5 transactions per hour
• Global threshold: Alert when total attempts exceed 3x your normal hourly volume

When a limit is hit, block further attempts from that identifier and flag the activity for review.

# Example: Check if an IP is suspicious before processing payment
curl -X POST https://api.fidro.io/v1/analyze/ip \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"ip": "185.234.72.19"}'

Fidro's IP analysis returns risk signals including VPN/proxy detection, data centre identification, and abuse history, giving you the data to make an informed decision before the transaction reaches your payment processor.

2. CAPTCHA on Payment Forms

Adding CAPTCHA (like reCAPTCHA v3 or hCaptcha) to your checkout creates friction for automated scripts. While not foolproof against sophisticated attackers who use solving services, it eliminates the majority of simple bot-driven attacks.

The key is implementing it correctly. Use invisible CAPTCHA with risk scoring rather than challenge-based CAPTCHA that annoys legitimate customers.

3. IP Intelligence

This is where most businesses leave money on the table. Checking the IP address of every transaction attempt before processing it reveals critical context:

• VPN/Proxy detection: Legitimate customers occasionally use VPNs, but a high volume of test transactions from VPN exit nodes is a clear indicator of fraud.
• Tor exit nodes: Almost no legitimate e-commerce transactions originate from Tor. Blocking or flagging these is a high-confidence move.
• Data centre IPs: Real customers browse from residential or mobile IPs. Transactions from cloud hosting providers (AWS, DigitalOcean, etc.) are almost always bots.
• Geolocation mismatch: If the card was issued in the US but the transaction comes from an IP in a different country, that is a risk signal worth investigating.

Fidro's IP analysis API checks all of these factors in a single request, returning a risk score and detailed breakdown that you can use to block, flag, or allow the transaction.

4. Address Verification System (AVS)

Always enable AVS checks with your payment processor. AVS compares the billing address provided during checkout against the address on file with the card issuer. Fraudsters running card tests rarely have the correct billing address, so AVS mismatches are a strong signal.

Configure your payment flow to decline transactions where AVS returns a mismatch on both street address and ZIP code.

5. Stripe Radar Rules

If you use Stripe, create custom Radar rules tailored to card testing patterns:

Block if :card_country: != :ip_country:
Block if :risk_score: > 80
Review if :card_funding: = 'prepaid' AND :amount_in_usd: < 2.00
Block if :ip_address: in @blocklist

Combine Stripe Radar with Fidro's risk scoring for a layered approach. Use Fidro to pre-screen the IP and email before creating the payment intent, then let Stripe Radar handle the payment-level checks.

6. Minimum Transaction Amounts

Setting a minimum charge amount above the typical card test range ($5 or higher) eliminates most testing attempts. If your product or pricing doesn't allow this, consider requiring a higher authorization amount that you partially refund.

7. Email Validation at Checkout

Card testers often use disposable or randomly generated email addresses. Validating the email before processing payment catches another category of fraud signals:

curl -X POST https://api.fidro.io/v1/validate/email \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "checkout-user@tempmail.com"}'

Fidro's email validation detects disposable email providers, checks DNS records, and flags addresses with patterns associated with fraud.

How Fidro Catches Card Testers

Fidro's API is designed to sit in front of your payment flow and catch fraud signals before the transaction reaches Stripe or your payment processor.

Here is how it works in a card testing scenario:

1. A transaction attempt hits your checkout. Before creating a payment intent, your server sends the customer's IP and email to Fidro's API.

2. Fidro analyzes the IP. In under 100ms, Fidro checks whether the IP is a VPN, proxy, Tor exit node, or data centre. It cross-references abuse databases and calculates a risk score based on the IP's history.

3. Fidro validates the email. The email is checked against 50,000+ disposable providers, verified for DNS validity, and scored for fraud patterns.

4. You get a risk verdict. Fidro returns a combined risk score with a clear recommendation: allow, review, or block. Each individual risk factor is broken down so you can build custom logic.

5. Your checkout acts on the score. High-risk transactions are blocked before they ever reach your payment processor. No authorization attempt, no fees, no chargebacks.

This pre-screening approach means card testers never get the authorization response they need. Without that feedback loop, your checkout becomes useless for validating stolen cards, and attackers move on to easier targets.

Building a Complete Defence

The most effective card testing prevention combines multiple layers:

1. Front-end: CAPTCHA on payment forms, JavaScript bot detection
2. Pre-payment: Fidro API for IP intelligence and email validation
3. Payment processing: Stripe Radar rules, AVS, and 3D Secure
4. Post-payment: Transaction monitoring, velocity alerting, chargeback tracking

No single tool stops every attack. But layering these defences makes your checkout expensive and unreliable for fraudsters, which is the goal. You don't need to be impenetrable. You need to be harder to exploit than the next target.

Getting Started

If you are seeing signs of card testing, here is a practical action plan:

1. Audit your current exposure. Check your Stripe dashboard for recent velocity spikes, high decline rates, and clusters of small transactions.
2. Add CAPTCHA to your checkout if you haven't already. This is the lowest-effort, highest-impact first step.
3. Integrate Fidro's API to pre-screen IPs and emails before payment processing. The free plan includes 200 requests per month, enough to test the integration and measure impact.
4. Set up Stripe Radar rules to block known fraud patterns based on IP country mismatches, prepaid cards, and risk scores.
5. Monitor and tune. Review flagged transactions weekly and adjust your thresholds based on your specific traffic patterns.

For a quick check on any suspicious IP address, try the free IP checker tool or the VPN detector to see the full risk analysis instantly.

Card testing is not going away. But with the right layers in place, your checkout stops being a useful tool for fraudsters, and the attacks stop before they start.