Card Testing Fraud

What Is Card Testing Fraud?

Card testing fraud (also called card checking or carding) is a technique where criminals use stolen credit or debit card data to make small transactions, confirming whether the card numbers are still valid and active. Once a card passes the test, the fraudster either uses it for larger purchases or sells the verified card data at a premium on underground markets.

The attack targets the four-party card payment model at its weakest point: the merchant checkout. Because card-not-present transactions only require a card number, expiration date, and sometimes a CVV, fraudsters can test thousands of stolen credentials programmatically using bots. The small dollar amounts are designed to avoid triggering fraud alerts while still generating a valid authorization response from the issuing bank.

Card testing has grown significantly as e-commerce has expanded. The attack disproportionately targets small merchants, nonprofit donation pages, free trial signups, and digital goods sellers: sites that tend to have weaker fraud controls and simpler checkout flows.

How It Works

A card testing attack follows a predictable sequence that exploits the gap between authorization and meaningful fraud detection:

1. Acquisition: the fraudster obtains stolen card numbers from data breaches, phishing campaigns, card skimming devices, or dark web card shops
2. Automation: they deploy bots or scripts that submit small transactions (often $0.50 to $5.00) or $0/$1 authorization-only requests against a target merchant's checkout page
3. Validation: if the authorization succeeds, the card is confirmed as "live" (active and not yet blocked by the issuer)
4. Exploitation: validated cards are used for high-value fraudulent purchases or resold on underground markets at a premium over unverified card data

Why Small Transactions?

Fraudsters deliberately keep test amounts low for several reasons. Small charges are less likely to trigger issuer fraud alerts. Cardholders are less likely to notice a $1.00 charge on their statement, buying the fraudster time before the card gets reported and canceled. And small authorization requests still return a valid approve/decline response, which is all the fraudster needs.

Target Selection

Not all merchant sites are equally vulnerable. Fraudsters prefer targets with specific characteristics:

• Simple checkout flows with no CAPTCHA or 3D Secure challenge
• Donation pages and nonprofit websites that accept arbitrary dollar amounts without shipping addresses
• Digital goods merchants that fulfill instantly, avoiding the delay where fraud might be caught
• Free trial signups requiring card details, where a $0 or $1 authorization validates the card without any actual purchase

Bot Infrastructure

Modern card testing attacks use sophisticated automation. Bots rotate through proxy IP addresses, randomize user agent strings, vary timing between requests, and even mimic human browsing patterns to evade detection. Fraud-as-a-service platforms have lowered the barrier to entry, allowing less technically skilled criminals to run large-scale testing operations.

# Simplified card testing detection logic (server-side)
# Flag rapid authorization attempts from similar sources

def check_velocity(request):
    ip = request.remote_addr
    window = timedelta(minutes=5)

    recent_attempts = db.count(
        ip_address=ip,
        created_after=now() - window
    )

    if recent_attempts > 10:
        return "BLOCK"  # Velocity limit exceeded

    if request.amount < 2.00 and recent_attempts > 3:
        return "REVIEW"  # Low-value + moderate velocity

    return "ALLOW"

The Carding Ecosystem

Card testing is one step in a broader underground economy built around stolen payment credentials. Understanding this ecosystem explains why card testing exists and why it continues to scale.

Dark Web Card Shops

Stolen card data is bought and sold on dedicated dark web marketplaces. These platforms operate like e-commerce sites, with listings organized by issuing bank, card type, country of origin, and available balance. Prices vary based on data completeness: a card number alone may sell for a few dollars, while "fullz" data (the complete identity package including name, address, Social Security number, date of birth, and card details) commands $15 to $100 or more.

Card testing serves as quality assurance in this supply chain. Sellers who verify their cards before listing them can charge higher prices, and buyers pay premiums for "checked" or "verified" cards because they know the credentials will work.

Card Testing vs. BIN Attacks

While both attacks target the card payment system, they differ in approach. Card testing starts with already-stolen complete card numbers and verifies whether they are still active. A BIN attack starts with only the first six to eight digits of a card number (the Bank Identification Number) and uses algorithms or brute force to generate and test possible complete card numbers, expiration dates, and CVV codes.

Both attacks exploit the same vulnerability: card-not-present transactions allow credentials to be tested remotely and programmatically.

Impact on Merchants

Card testing inflicts financial damage far beyond the face value of the test transactions themselves. Even when the individual charges are small, the cumulative costs can be substantial:

• Authorization fees: every transaction attempt incurs a processing fee ($0.05 to $0.30), regardless of the amount. Thousands of bot-driven attempts can generate hundreds of dollars in fees overnight
• Chargeback costs: when cardholders notice even the small test charges and dispute them, merchants pay chargeback fees of $20 to $100 per dispute plus the transaction amount
• Processor scrutiny: elevated decline rates and chargeback ratios draw attention from the acquiring bank and payment processor, potentially leading to higher processing rates, reserve requirements, or account termination
• MATCH/TMF listing: merchants with excessive chargebacks can be placed on the card network terminated merchant file, making it difficult to obtain a new merchant account
• Operational burden: investigating fraudulent transactions, responding to chargeback disputes, and implementing additional fraud controls all consume time and resources

Prevention and Mitigation

Effective card testing defense requires layered controls that increase friction for bots while preserving a smooth experience for legitimate customers.

Velocity Limits

Rate limiting is the first line of defense. Merchants should cap the number of transaction attempts allowed from a single IP address, device fingerprint, or card number within a rolling time window. A legitimate customer rarely submits more than two or three transactions in quick succession, so limits of five to ten attempts per five-minute window catch most automated attacks.

CAPTCHA and Bot Detection

Adding CAPTCHA challenges to checkout forms blocks simple bots. More sophisticated approaches use invisible bot detection: device fingerprinting, behavioral analysis (mouse movements, typing patterns, scroll behavior), and browser environment checks that distinguish automated scripts from human users without adding visible friction.

AVS and CVV Verification

Address Verification Service (AVS) checks the billing address provided at checkout against the address on file with the issuing bank. CVV verification requires the three-digit security code printed on the physical card. While neither is foolproof (fullz data includes addresses, and some breaches capture CVVs), requiring both significantly reduces the success rate of card testing since many stolen card databases lack complete address and CVV data.

3D Secure Authentication

3D Secure adds an issuer-controlled authentication step that requires the cardholder to verify their identity through their bank. This is highly effective against card testing because the fraudster cannot pass the authentication challenge even with valid card credentials. The tradeoff is added friction that may reduce checkout conversion rates.

Machine Learning Fraud Scoring

Fraud scoring systems use machine learning to evaluate transaction risk in real time. These models analyze hundreds of signals: transaction velocity, device reputation, geolocation consistency, purchase patterns, and more. They assign a risk score that determines whether to approve, decline, or flag a transaction for manual review. Card testing patterns (high velocity, low amounts, new devices) produce distinctive signals that trained models catch quickly.

Why Push-Based Payments Eliminate Card Testing

Card testing fraud exists because of a fundamental architectural flaw in card payments: the pull payment model. When a customer provides card credentials to a merchant, they grant the merchant (and anyone who intercepts those credentials) the ability to initiate charges. The credentials are reusable, transferable, and testable.

Push-based payment systems invert this model entirely. In a push payment, the sender initiates and cryptographically authorizes each transaction individually. There are no reusable credentials to steal, test, or resell. Bitcoin, the Spark protocol, and stablecoin transfers all operate on this principle:

• No stored credentials: each transaction requires a unique cryptographic signature from the sender's private key. There is no card number equivalent that can be reused
• Sender-initiated only: merchants cannot pull funds. They present an invoice or address, and the sender authorizes the exact amount. A fraudster with a merchant's payment address cannot extract funds from anyone
• No authorization testing: there is no concept of a small test transaction that validates credentials for later use. Every transaction is a fully authorized, final transfer
• No intermediary chain to exploit: without acquirers, processors, and card networks, there is no infrastructure where stolen credentials can be replayed

This structural difference means that an entire category of payment fraud, including card testing, BIN attacks, and credential stuffing, simply cannot occur in push-based cryptocurrency payment systems. For a deeper analysis, see the research on how stablecoins reduce payment fraud.

Risks and Considerations

False Positives in Prevention

Aggressive fraud prevention can block legitimate customers. Overly strict velocity limits may reject a customer who re-enters their card after a typo. CAPTCHA challenges frustrate mobile users. Declining all low-value transactions eliminates real micropayments. Merchants must balance fraud prevention against conversion rates and customer experience.

Evolving Attack Sophistication

Card testing attacks grow more sophisticated over time. Modern bots use residential proxy networks to distribute requests across thousands of IP addresses, defeating simple IP-based rate limiting. AI-driven bots mimic human browsing patterns to bypass behavioral detection. Distributed attacks spread test transactions across many merchant sites simultaneously, making pattern detection harder for any single merchant.

Liability and Compliance

Under card network rules, merchants bear liability for card-not-present fraud unless they implement specific protections like 3D Secure. PCI DSS compliance requirements mandate that merchants protect stored card data, but they do not prevent fraudsters from using stolen data obtained from other breaches. This creates an asymmetric burden: merchants must invest in fraud prevention even though the card data was compromised elsewhere in the ecosystem.

Network-Level Responses

Card networks have introduced tools to combat card testing at the network level. Visa's Account Attack Intelligence (AAI) tool detects enumeration attacks in real time by analyzing authorization patterns across its entire network rather than at individual merchant endpoints. Network tokenization replaces actual card numbers with tokens, reducing the value of stolen credentials. These network-level defenses complement but do not replace merchant-side controls.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.