Card Testing Fraud: Payment Gateway Signals and Controls

Card testing fraud uses payment attempts to assess whether stolen card details can be used. Payment-provider evidence, attempt velocity, account relationships and fulfillment timing help a team investigate it. Apply controls before value is released where possible, and treat device or IP observations as context rather than proof of cardholder authorization.

This guide breaks down how the attack works at fiat-to-crypto on-ramps, the signature it leaves in your payment data, what it costs, and the layered defenses that stop it, including where on-chain reputation fits.

What is card testing?

Card testing is a form of payment fraud in which criminals push through many small, fast transactions to learn which stolen card numbers still work. It is also called card checking, and, when numbers are guessed in sequence from a known prefix, an enumeration attack or BIN attack. It is reconnaissance before the real theft.

Fraudsters obtain card data from breaches, phishing kits, skimmers, or dark-web dumps. Because a dump can contain thousands of numbers of unknown status, they need a cheap, automated way to sort live cards from dead ones. Any checkout that accepts small charges with weak controls becomes their testing ground.

Why fiat-to-crypto on-ramps are a prime target for card testing

Fiat-to-crypto on-ramps are prime targets because a card charge converts into an asset that settles in minutes and cannot be clawed back on-chain. Low purchase minimums, global card acceptance, and constant new-user signups let fraudsters validate cards in cheap bursts and move the proceeds before a chargeback ever lands.

The economics are lopsided. A traditional merchant ships a physical good days later, leaving time to review orders. An on-ramp delivers a bearer asset almost instantly. Once the crypto leaves for an external wallet, the merchant absorbs the eventual dispute while the fraudster keeps the coins.

Visa's Biannual Threats Report (December 2023) attributed more than US$1.1 billion in global fraud losses to enumeration attacks, the automated family that includes card testing, over the year ending September 30, 2023, and recorded a 40% rise in these attacks in the first half of that year. It is a small share of card volume with an outsized cost. Source: https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/pfd-biannual-threats-report-december-2023.pdf

How a card testing attack works: the step-by-step pattern

A card testing attack runs as a loop: acquire stolen or generated card data, script rapid low-value purchases at a vulnerable checkout, keep the cards that approve, and discard the rest. At a crypto on-ramp, each approval buys a sliver of crypto that is swept to a fresh wallet within the same session.

The typical sequence looks like this:

1. Source the data. Buy a dump of card numbers or generate candidates from a valid BIN.
2. Automate the checkout. Point a bot or a headless browser at the on-ramp's buy flow, often behind rotating proxies.
3. Charge small. Attempt the platform minimum, frequently a few dollars, to stay under review thresholds.
4. Read the response. An approval means the card is live; a decline means it is dead or flagged.
5. Sweep and repeat. Route the purchased crypto to a throwaway wallet, then cycle to the next card.

Validated cards are then reused for larger purchases, resold at a premium, or fed straight into carding runs.

The attack signature: low-value bursts, many cards, and rotating BINs

The signature of card testing is unmistakable once you look for it: a sudden spike of tiny authorizations, an abnormally high decline rate, one device or IP retrying checkout dozens of times, and many distinct card numbers, often sharing a Bank Identification Number, all inside a few minutes.

Watch for these tells in aggregate:

• A decline rate that jumps from a normal single-digit baseline to well over half of attempts.
• Dozens or hundreds of unique cards from one device fingerprint or IP range.
• Clusters of cards whose first six to eight digits, the BIN, are identical, the hallmark of a BIN attack.
• Purchase amounts pinned to the exact platform minimum.
• Checkout completed faster than a human could plausibly type.

No single data point proves fraud. The pattern is what convicts.

What card testing costs on-ramps and merchants

Card testing is expensive even when most charges fail. Every disputed transaction triggers a chargeback and fee, high decline ratios push a merchant toward card-scheme monitoring programs, and processors can raise reserves or freeze the merchant ID outright. For an on-ramp, a frozen MID means no revenue at all.

The damage compounds in three layers. First, direct losses: successful fraudulent purchases plus per-chargeback fees. Second, ratio penalties: Visa and Mastercard track excessive declines and disputes, and breaching thresholds lands a merchant in a remediation program with fines. Third, existential risk: a payment processor that sees a card testing wave may hold funds or terminate the merchant ID entirely, cutting off the on-ramp's ability to accept cards.

Detection signals that stop card testing

Card testing is caught by correlating signals no single check can see alone: transaction velocity per card, device, and IP; device fingerprint reuse; BIN concentration; proxy, VPN, and datacenter-IP detection; and behavioral cues like inhuman checkout speed. Together they separate a burst of fraud from genuine buyers.

The core detection layers are:

• Velocity checks — limits on attempts per card, per device, and per IP inside a rolling window.
• Device fingerprinting — spotting one device masquerading as many buyers.
• BIN analysis — flagging an unnatural concentration of one issuer prefix.
• Network intelligence — detecting proxies, VPNs, and datacenter IPs that mask the origin.
• Step-up authentication — 3-D Secure, plus AVS and CVV checks, to force friction on suspicious attempts.

Banks lean on the same idea when they detect cloned cards: unusual velocity and geography measured against the cardholder's history. On-ramps increasingly pair these rules with systems purpose-built to flag card-testing bursts in real time, which score each attempt as it arrives rather than after the chargebacks roll in.

Where on-chain reputation and Proof-of-Human fit the crypto fraud stack

On-chain reputation and Proof-of-Human identity do not screen card payments directly. They harden the layer beneath the on-ramp: by scoring real wallet activity and filtering bots and sybils, protocols can refuse the throwaway wallets that receive laundered crypto, shrinking the payoff that makes card testing worth running.

RubyScore's Multichain Reputation Score normalizes recorded wallet activity to a 0–1000 scale. Its Proof-of-Human ID is an ecosystem-specific, non-transferable attestation earned against locally defined activity thresholds. These are activity-based eligibility signals; they do not independently establish legal identity, unique personhood or honest intent.

The connection to card testing is downstream but real. Fraudsters cash out validated cards into fresh, historyless wallets. A dApp, airdrop, or quest platform that gates rewards behind a reputation floor or a PoH ID denies those wallets a place to spend or farm, so even a successfully tested card struggles to convert into usable value inside Web3.

Card testing vs. other payment fraud at on-ramps

Card testing is only one payment-fraud pattern on-ramps face, and it is often the opening move. Carding spends the cards it validates, account takeover hijacks trusted users, chargeback fraud abuses dispute rights, and sybil farming games rewards. Each leaves a different signature and needs a different control.

The short version of card testing vs. carding: card testing confirms which cards are alive, while carding is the follow-up purchase that monetizes them.

A prevention checklist for on-ramps, wallets, and quest platforms

Stopping card testing takes layered controls, not one silver bullet. On-ramps, wallets, and quest platforms should combine velocity limits, step-up authentication, device and network intelligence, and downstream on-chain reputation so that even a validated card cannot cheaply convert into usable, launderable value.

Practical controls to put in place:

• Cap attempts per card, device, and IP with rolling-window velocity rules.
• Trigger 3-D Secure step-up on high-risk attempts, and enforce AVS and CVV.
• Fingerprint devices and detect proxies, VPNs, and datacenter IPs.
• Alert on BIN concentration and decline-rate spikes in real time.
• Raise the minimum-purchase friction that makes cheap testing viable.
• Gate rewards and payouts behind on-chain reputation or a Proof-of-Human ID to devalue laundered proceeds.

Payment gateway fraud detection needs a pre-fulfillment decision

Payment gateway fraud detection should join attempts, account context, payment-provider results and fulfillment. Card testing can spread low-value attempts across accounts, cards or network addresses, so a per-IP rate limit is only one control. Use the payment provider's documented indicators and authentication controls for the methods you accept.

Separate authorization from delivery, and record retries under stable server-side identifiers. A later risk result can support investigation but may arrive too late to stop a delivered asset. Device context cannot independently establish that a cardholder authorized a payment.

For implementation context, see payment-fraud controls and card-testing detection guide. Read next: payment fraud crypto on ramps, best fraud detection apis developers 2026.

Compare tools for this workflow

For a documented shortlist and a provider-selection checklist, read 7 Best Ecommerce Fraud Prevention Tools in 2026.

Frequently asked questions

What is card testing? Card testing is a form of payment fraud where a criminal submits many small transactions to confirm which stolen card numbers still work. Working cards are kept for larger purchases or resold, while declined ones are discarded. It is also called card checking or, when numbers are generated in sequence from a known prefix, an enumeration attack.

Why are crypto on-ramps a prime target for card testing? Fiat-to-crypto on-ramps convert card payments into assets that settle fast and are hard to reverse, so a validated card can be cashed out almost immediately. Low minimums, global card acceptance, and high signup volume add to the appeal. Visa's Biannual Threats Report (December 2023) attributed more than US$1.1 billion in global fraud losses to enumeration attacks over the year ending September 30, 2023. Source: https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/pfd-biannual-threats-report-december-2023.pdf

How do you detect card testing? Card testing is detected by its signature: spikes in low-value authorizations, unusually high decline rates, one device or IP hitting checkout repeatedly, and many different card numbers or BINs in a short window. Velocity rules, device fingerprinting, proxy detection, and 3-D Secure step-up work together to flag and slow the pattern.

Is card testing illegal? Yes. Card testing uses stolen or illegally obtained card data, so it is payment fraud in nearly every jurisdiction. Automating attacks against a checkout with those numbers can trigger access-device fraud, wire fraud, and computer-misuse statutes such as the U.S. Computer Fraud and Abuse Act, alongside equivalent laws worldwide. On-ramps and merchants that suffer it are victims, but still absorb the chargebacks and processor penalties.

What is a BIN attack? A BIN attack is a card testing variant where fraudsters take one valid Bank Identification Number, the first six to eight digits of a card, and generate thousands of candidate card numbers. They then test the numbers at checkout to find live accounts. An on-ramp sees this as many cards sharing the same BIN prefix in minutes.

Can on-chain reputation stop card testing? On-chain reputation and Proof-of-Human identity do not screen card payments directly, but they harden the layer beneath the on-ramp. By scoring wallet activity and filtering bots and sybils, protocols and quest platforms can deny the throwaway wallets that receive and launder proceeds from validated stolen cards, shrinking the payoff of the attack.

Sources and editorial notes

Updated in 2026 by RubyScore Research, the organizational editorial byline for this blog. Product descriptions are attributed to their publishers; examples and risk signals do not establish a shared vendor benchmark. Disclosure: linked ShieldLabs publications and related comparison sites are part of the project portfolio. For source-specific corrections, contact RubyScore.

[1] payment-fraud controls — vendor product scope.

[2] card-testing detection guide — related technical or workflow explanation.

[3] RubyScore documentation — on-chain product context.

Further sources for payment gateway fraud detection

These references cover specific parts of the workflow discussed above. Provider explanations, product pages, documentation and controlled demos have different evidential roles; the notes state how each source should be used.