What Is a BIN Attack?
A BIN attack is a fraudster testing thousands of guessed card numbers at a checkout to find the ones that still work. You see it as a wave of tiny declines. Those test charges can turn into chargebacks, and every number that survives usually turns into a bigger one later.
I've worked decline reports in a chargeback support role, and this attack always shows up days before the disputes do. Work through the signals below and you'll catch the testing while it's still just declines.
Key takeaways
Seeing declines you can't explain? Our pre-dispute alerts flag a disputed charge while a refund still closes it.
What is a BIN attack?
A BIN attack generates thousands of card numbers from a known bank identification number, then tests them at a checkout to find which ones are live. Cybercriminals use brute-force methods to guess valid combinations of credit card information this way. You see it as a spike in small-value declines, arriving faster than real shoppers could.
A fraudster with one valid bank identification number can generate every remaining digit sequence, because the BIN fixes only the bank and network digits. That's a different identifier from your CAID (card acceptor ID), which tags your own merchant checkout rather than the customer's card.
Each candidate then runs through the Luhn checksum, the arithmetic test every real card passes. That throws out the impossible numbers before any of them reach a checkout.
The numbers come from BIN ranges anyone can look up, so no card data leaves your systems.
Your checkout is where the fraudster runs the tests.
How a BIN attack works
The attack runs in four steps, from picking a bank identification number to spending the numbers that survive:
- Obtain a valid BIN: Pulled from a card dump, breached payment data, or a public lookup tool.
- Generate candidate numbers: Software fills in the remaining digits and keeps the Luhn-valid ones.
- Run small test authorizations: Bots push hundreds per minute at a live checkout.
- Exploit the hits: Confirmed numbers get spent or sold.
Stripe describes the same four-step mechanism, identification, generation, validation, and exploitation.
Each test charge stays small, often under $2. A charge that size is less likely to trigger the cardholder's fraud alert, and less likely to get noticed on a statement.
33% of merchants surveyed reported card testing fraud in 2025, per Chargebacks911, citing the Merchant Risk Council's annual fraud report. A BIN attack is one form of it.
Say your checkout logs 40 authorization attempts in ten minutes. Every one is under $2, and every card number shares its leading digits.
What marks an attack is the shared BIN prefix and the decline rate. Free-trial signups, donation platforms, and gift-card balance checks all produce the same low-value bursts, so judge the pattern rather than the amount.
What happens after a BIN attack succeeds
Every card number that survives the testing creates two separate chargeback exposures for you. The small test charge is the first. The much larger purchase that follows, once the fraudster knows the number works, is the second.
The first exposure comes from the tests that cleared. Nobody authorized those charges, so the real cardholder disputes them as card-absent fraud.
The second arrives when the fraudster spends a confirmed number on something worth having. That purchase disputes under the same code family, for real money. Both rounds usually land weeks after your declines stopped.
Blocking the tests in real time means none of them clear, so your first exposure never opens. Your controls protect you.
A fraudster declined at your checkout takes the number to the next merchant.
How to detect a BIN attack
A spike in declined authorizations that share a card prefix and land within minutes is the clearest signal of a BIN attack.
The fraudster is working through a generated number range, and that produces three patterns you won't see in ordinary traffic:
- Many transactions share the same first six to eight digits.
- Most authorizations decline instead of clearing.
- The volume lands in minutes rather than over a browsing session.
Any one of those alone is noise. A processor outage produces mass declines, and a flash sale produces a volume spike. All three inside the same window is the pattern worth acting on.
Our free BIN lookup tool shows whether a suspicious prefix maps to a real issuer.
One thing has to be true before any of this helps. Your processor has to show you the data.
Some dashboards report declines as a single daily count with no BIN-level breakdown. A few will only send it as a manual export.
Ask your processor for decline data broken out by BIN, by decline code, and by hour. In the setups I reviewed, this is where merchants lose the signal.
How to prevent BIN attacks
Velocity limits, CVV and AVS matching, and bot detection stop most BIN attacks before they produce a chargeback:
- Velocity limits: Cap authorization attempts per card range, IP, and session.
- CVV and AVS matching: Reject generated numbers that carry no matching details.
- Bot detection: Turn on device fingerprinting and failure-triggered CAPTCHA.
Each one breaks a different part of the attack, so take them in order.
1. Set velocity limits on authorization attempts
A velocity limit works because the attack needs hundreds of attempts a minute and a real shopper needs three. It caps how many authorization attempts one session, IP address, or card-number range can make in a short window.
A good starting rule blocks any IP, device, or shared prefix past 10 checkout attempts in five minutes. Hold the block for an hour.
Most payment platforms ship this as a setting. Stripe Radar and Shopify's fraud settings both support attempt-rate rules, and a web firewall like Cloudflare can rate-limit your checkout page before requests reach the processor.
Set the threshold too tight and you'll block real people. A shopper retrying a mistyped card looks like repeat attempts, and so does a family on one home network. Allow at least three attempts before the counter trips.
2. Enforce CVV and AVS matching
CVV and address verification catch most generated card numbers, because a fraudster who guessed a number rarely holds the matching code or billing address. Number generation produces a plausible card number. The security code and the billing address are separate facts the fraudster doesn't have.
What matters is how your processor treats a mismatch. Many merchants run these checks in flag-and-approve mode. The charge clears with a warning attached, and the warning goes nowhere.
Ask your processor to hard-decline CVV and AVS mismatches, then confirm it with a test order. This gap showed up constantly in the setups I reviewed.
3. Add bot detection to checkout
Bot detection targets the automated submission pattern itself, reading how fast a request arrived, from what device, and alongside how many others. Rate limiting, a CAPTCHA that fires after repeated failures, and device fingerprinting all work on that behavior around the request.
Trigger these at the same threshold as your velocity rule, 10 attempts in five minutes.
A CAPTCHA in front of every buyer costs you real sales. Stopping an attack that runs twice a year rarely justifies that trade.
Even a well-tuned checkout lets some fraud through, which is what our dispute alerts are for. They reach you while a refund still closes the case.
Responding when a BIN attack becomes a chargeback
Refund the charge or resolve it on an alert where you can, because these arrive as card-absent fraud disputes and turn on evidence you usually can't produce. That code family is the largest specific one in our own alert data, covered in our guide to fraud, card-absent disputes.
A fraud code asks you to show the charge matched the real cardholder's known behavior. That means their usual device, their saved shipping address, their order history with you.
Whether the order shipped sits outside the question. That's why a tracking number and a signed delivery slip do so little here. The parcel arrived, and the cardholder never disputed that part.
Refunding a flagged charge inside a pre-dispute alert window closes it before it becomes a chargeback. Ethoca (Mastercard) and Verifi (Visa) both send those alerts.
That beats fighting a code you're likely to lose.
How we sourced our data
The reason-code claim here comes from anonymized, aggregated alert data across merchants enrolled on the Chargeback.io platform. We rank reason codes by their share of the alerts carrying a recorded code, and we keep raw counts internal.
These figures describe the alerts our platform processed. They aren't a measurement of the payments industry, and merchant mix shapes what shows up in them.
FAQ
Is a BIN attack the same as card skimming?
No. A BIN attack guesses card numbers algorithmically, while skimming captures real card data from a physical terminal or a compromised checkout page.
Can a BIN attack happen without any transactions completing?
Yes, and it still costs you. A wave of declines racks up authorization fees, can draw acquirer scrutiny over your decline ratio, and ties up your team.
What does BIN mean in banking?
BIN stands for bank identification number, the first six to eight digits of a card number. Those digits identify the issuing bank and the card network.
Can a card get blacklisted after a BIN attack?
Individual cards can be blocked or reissued once an issuer sees them tested or used fraudulently. Issuers rarely block a whole BIN range, since that would cut off every legitimate cardholder on it.
