Kavra LabWhat a BIN is, and why it can be abused
Every payment card number starts with a Bank Identification Number, also called an Issuer Identification Number. It tells the payment system which bank issued the card and what kind of card it is. The rest of the number is the account part plus a final check digit calculated with a public formula, the Luhn algorithm.
That structure is useful for routing payments, but it also narrows the search. Knowing a BIN, an attacker only has to guess the remaining digits, and the check digit rules out most invalid combinations before a single request is sent. Expiry dates fall within a few years, and security codes have only a few hundred to a few thousand possible values. With enough attempts, some guesses land on real cards.
How a BIN attack works
- 01
Pick a BIN
The attacker chooses an issuer range, often one known for weaker checks on small or card-not-present authorizations.
- 02
Generate candidates
Software fills in the remaining digits, keeps only numbers that pass the check digit, and pairs them with likely expiry dates.
- 03
Submit at volume
Bots send the guesses through a checkout, donation form or card-verification step, spread across many IP addresses and sessions.
- 04
Keep the hits
Approved combinations are real cards. They are used for purchases, sold, or tested further to find the security code.
BIN attack vs card testing
BIN attack
- Starts from an issuer prefix, not stolen cards
- Guesses numbers, dates or codes
- Very high decline rate, sequential or clustered numbers
- Also called card cracking or enumeration
Card testing
- Starts from a list of stolen card numbers
- Checks which cards are still live
- Many unrelated cards from many issuers
- Usually small or zero-value charges
Why it matters and how to stop it
A BIN attack leaves a very specific trail: bursts of payment attempts where card numbers share the same prefix, often in near-sequence, with a decline rate far above normal. The merchant pays for every authorization, and the issuer may block the whole range, which also blocks your real customers holding those cards. Once some guesses succeed, the resulting fraud turns into disputes against your account.
Card-level defenses help: limit attempts per card and per session, require the security code and billing ZIP, and watch for many declines sharing one prefix. Issuers run their own checks too. But attackers read the same playbook, so they spread guesses across time, merchants and networks to stay under every threshold.
Stopping it at the card level alone is a race, because attackers switch BINs and slow down. Stop it at the visitor level instead. Kavra assesses every checkout request and flags the automation, the spoofed devices and the rotating proxy traffic behind the attempts, so the guesses never reach your processor. The card testing prevention and payment fraud pages cover the full approach, and card testing explains the closely related attack.