TL;DR: BIN attack detection at the browser layer
- Why controls fail: Rotating IPs and cheap CAPTCHA challenges are treated as the answer to BIN enumeration, but Visa attributes roughly $1.1 billion in ecosystem losses to this attack in a single year, so the standard controls are clearly not doing the job.
- What cside does: cside captures the device fingerprint, behavioral score, and script activity of every checkout session and flags flat scoring, missing cursor motion, and superhuman form-submit timing before the transaction leaves the browser for the gateway.
- Check your logs: If your last 30 days include sessions with more than five distinct card numbers and a decline ratio above 90%, your gateway is billing you for authorization attempts on an attack it is only detecting after your money is spent.
Short on time? See cside's chargeback-evidence tooling. It covers everything below in one deployment.
Attackers do not test stolen cards by hand. They run an automated script that hammers a merchant's checkout with thousands of low-value transactions in a few minutes. Each successful approval hands the criminal a validated card number worth reselling or reusing. If your acquirer sees a spike of low-value declines from a narrow set of sessions, you are the target of a BIN attack.
What a BIN attack actually is
A Bank Identification Number is the first six to eight digits of a credit or debit card, and it identifies the issuing bank and card scheme. Attackers who obtain or algorithmically generate card numbers within a valid BIN range use automation to figure out which numbers are live.
The mechanics are consistent across every attack we have seen at the browser layer:
- A script iterates through candidate card numbers within a valid BIN range.
- Each candidate is submitted as a small transaction, often $0.01 to $1.00, against a merchant's checkout.
- Any card that returns approved is flagged for reuse in a higher-value fraud attempt downstream.
Visa tracks the same attack under the name enumeration attack and has attributed roughly $1.1 billion in ecosystem losses to it in a single year. Mastercard flags it inside its Fraud and Chargeback Reduction reporting and has been rolling out Fraud Protection Technologies specifically to counter enumeration.
Why merchants get chosen
BIN attackers pick checkouts that let automation run cheaply. Three properties usually put a merchant in the top of that pile:
- Guest checkout with no login gate
- Little or no bot friction beyond a basic CAPTCHA
- Minimum transaction amount set very low, so the attempts fly under fraud rules
Small merchants absorb most of the volume because their controls are lighter. Large merchants still pay a real price: gateway fees on every attempt, chargebacks on the successful attempts, and network-level fines if the ratio of enumeration traffic gets high enough.
The browser-layer signature
A BIN attack looks unmistakable if you can see the session, not just the transaction. Six patterns show up together:
- Dozens or hundreds of submit attempts from one session, device, or IP in a short window
- Sequential card numbers inside a single BIN range
- Decline-to-approve ratios above 90%
- The same device fingerprint attempting many different cards
- No cursor movement, no scrolling, no cart edits, just pure form submission
- Timing that is more regular than any human could produce
Server-side fraud tools that only see the transaction stream catch this attack after the fact. The browser layer sees the automation signature before the transaction hits the gateway. This is the same signal that catches AI-driven card testing agents. See our guide on how to block AI credit card testing agents for the case where the automation is an LLM-driven agent rather than a scripted bot.
Controls that actually work
| Control | What it stops | Realistic impact |
|---|---|---|
| Device fingerprinting | Repeated attempts from the same device, even across IP rotation | High |
| Behavioral scoring | Scripted versus human interaction on the checkout | High |
| Velocity limits at the browser layer | Rapid submits from a single device or session | Medium |
| Gateway rate limits per IP | Straight-line IP flooding | Low; attackers rotate IPs |
| CAPTCHA | Basic automation | Low; modern bots bypass reCAPTCHA cheaply |
| BIN blocklist | Known abused BIN ranges | Medium and reactive |
Device fingerprinting sits at the top because BIN attacks depend on stable device identity to run at scale. Rotating IPs is trivial for an attacker. Rotating device fingerprints in a way that also fools behavioral models is not.
Where cside fits
cside captures device fingerprint, behavioral signals, and script activity from the browser on every checkout session. When a session shows automation patterns (flat behavioral scoring, no natural pointer motion, form submissions faster than a human could type), cside can flag it before the transaction leaves the browser.
The same device fingerprint also becomes usable evidence on the small percentage of BIN-attack transactions that succeed and get disputed. See how device fingerprinting for card testing works when disputes arrive.
What to do this week
If you are not sure whether a BIN attack has already landed on your checkout, three checks tell you fast:
- Pull the last 30 days of authorization data from your gateway and count the sessions with more than five distinct card numbers attempted. That is your enumeration attempt volume.
- Compare the decline ratio on those sessions to the site average. Anything above 90% is enumeration.
- Check whether any of those sessions successfully processed a transaction. If yes, expect a chargeback in the next 30 to 60 days.
If the first two numbers are high and you cannot see the browser-layer signal, you are relying entirely on your gateway's fraud rules, and your gateway sees the attack only after it has spent your money.
