Detecting BIN Attacks and Card Testing Before Charges Post

Card testing looks harmless on a dashboard: a wave of one-dollar authorizations, most of them declined. But every one of those attempts is a fraudster confirming which stolen card numbers still work, and the successful ones become full-value fraud within hours.

BIN attacks and card testing share a signature that pure payment data hides. The card details rotate constantly, so a processor sees thousands of unique cards and no obvious pattern. The device and network behind them, however, barely change at all.

How card testing actually runs

Attackers rarely type cards by hand. They script checkout against your payment form or a exposed API endpoint, cycling through generated card numbers under one BIN. A typical run shares these traits:

• Hundreds to thousands of attempts in minutes, far above human speed.
• Tiny or zero-dollar amounts to minimize the cost of a valid hit.
• The same automation stack (headless Chrome, a request library, or an emulator) across every request.
• A small pool of proxy IPs, often datacenter or residential rotation.
• Minimal cart interaction: no browsing, no add-to-cart, straight to pay.

Rate limiting by IP alone fails because attackers rotate addresses faster than you can block them. What stays constant is the machine.

Device signals that expose the pattern

A stable visitor identifier is the anchor. When Prynt assigns a durable visitorId that survives incognito mode, cleared cookies, and IP changes, the fifty rotating cards collapse into one device you can rate-limit and block. That single fact turns an unwinnable IP race into a solvable device problem.

Layer server-side Smart Signals on top:

• Automation and bot flags catch the headless browser or scripted client driving the checkout.
• Datacenter and proxy detection exposes the infrastructure behind rotating IPs.
• Velocity by device counts distinct cards attempted per visitorId in a rolling window, the single strongest card-testing indicator.
• Emulator and virtual-machine signals flag card-testing farms running on cheap cloud instances.

Because these signals are computed server-side and delivered through your backend, an attacker cannot read or tamper with the verdict the way they can with a client-only check.

Building a card-testing rule

Start with velocity thresholds keyed to the device, not the card or IP:

1. Count unique PANs (or payment tokens) per visitorId over five, thirty, and sixty minutes.
2. Count authorization failures per device; testers generate abnormally high decline ratios.
3. Combine with a bot or automation flag to separate a confused human from a script.

A device presenting six distinct cards in ten minutes with three declines and an automation flag is not a shopper. Step it up to a challenge, throttle it, or block outright before the authorization ever reaches your processor. Moving the decision in front of the payment gateway is the point: you avoid the fees and the network scrutiny that come from letting the attempts land.

For a deeper walkthrough of wiring device verdicts into the authorization path, see the payment fraud detection guide.

Protecting the endpoint, not just the page

Sophisticated testers skip your UI and hit the payment API directly. Defenses that only run in the browser never see them. Verify the Prynt visitorId and its signals on the server for every payment request, and reject or challenge requests that arrive with no fingerprint, a freshly minted one, or a mismatched, replayed identifier. Treat a missing device context as a signal in itself.

Pair this with sane hygiene: never expose raw processor errors that tell an attacker why a card failed, add invisible timing checks to your form, and cap authorization attempts per session.

Measuring whether it works

Track authorization approval rate, the ratio of declines flagged as card testing, and downstream chargebacks tied to tested BINs. A working defense shows a falling decline rate (because junk attempts never reach the processor) alongside fewer fraud chargebacks two to four weeks later, the lag being how long it takes tested cards to convert to real fraud.

The reputation network compounds this: a device that ran card testing against one Prynt-protected merchant carries that history when it appears at yours, so you can act on the first request rather than the thousandth.

Card testing is a volume game that only pays when the attacker can stay anonymous. Give every attempt a persistent identity and the economics collapse.

Try the signals against your own traffic in the playground and see how a live checkout flow scores.