Also called: BIN enumeration attack
What a BIN attack is
A BIN attack targets online card payments. BIN means Bank Identification Number, the first six to eight digits of a payment card number. That prefix identifies the issuing institution and helps identify the card type or network.
Attackers use a known prefix to generate possible card numbers, then send automated attempts to a checkout or card-verification point. A BIN attack generates candidate numbers from a known prefix; card testing fraud focuses on checking stolen card numbers for validity. Both involve attempts to identify cards that work.
A BIN attack can turn thousands of declined checkout attempts into processing costs and extra fraud work.
How the attack reaches your checkout
Bots submit many low-value card attempts in a short period, often producing a stream of declines. Some test transactions are under $1. A successful authorization can reveal that a card is active, after which criminals may use or sell the details.
The attempts are card-not-present transactions, so the card is not physically presented to your staff. Attackers can distribute requests across IP addresses and browser profiles, which makes a single source harder to spot. A sudden rise in declines, validation errors, or tiny purchases is a practical warning sign.
What a BIN attack can cost your business
Your processor agreement may bill each attempted transaction, including a declined attempt. Thousands of automated requests can therefore add transaction charges even when the sales do not settle. Compare transaction-fee line items and their billed counts against your authorization and decline activity.
A successful test can lead to an unauthorized sale, refund, or chargeback. A surge in fraudulent activity also consumes staff time and can disrupt legitimate checkout attempts. These costs come from the attack and your processing arrangement, not from a standard BIN-attack fee with a fixed amount.
How to spot and contain one
Look for a sharp burst of small purchases or declines, repeated card-validation errors, or many attempts sharing a card prefix, device, or other pattern. A specific count is not a universal threshold, so compare the activity with your own normal transaction volume and checkout behavior.
If the pattern is active, alert your payment processor and review its fraud tools and transaction records. Tighten controls on the affected checkout path while preserving a route for legitimate customers. Do not rely on declines alone as protection, since each attempt can still create costs or operational work.
What you can actually change
You cannot prevent criminals from knowing a public card prefix, but you can make rapid automated testing harder and respond before the attempts pile up.
- Set velocity limits for repeated attempts by device, IP address, card prefix, and account.
- Add CAPTCHA or device fingerprinting to identify automated traffic and repeated behavior.
- Use Address Verification Service and 3-D Secure where appropriate, with rules that distinguish suspicious activity from normal customer purchases.
- Review declined-attempt fees and authorization counts against your processor agreement and monthly statement.
- Watch decline patterns. Track small-value attempts, validation errors, and sudden changes in declines against your normal online sales.
- Layer checkout controls. Combine velocity limits with bot screening and cardholder verification instead of relying on one filter.
- Audit attempt charges. Match billed transaction counts to authorization activity to find fees tied to declined tests.
Frequently asked questions
What is the difference between a BIN attack and card testing fraud?
A BIN attack generates possible card numbers from a known Bank Identification Number and tests them. Card testing fraud is the broader activity of checking card details for validity, including stolen card numbers. The terms overlap, but the BIN attack describes the use of a known card prefix to generate candidates.
Can declined BIN-attack attempts still cost my business?
Yes. Some processor agreements allow a transaction fee for each attempt, including a declined one. Compare your agreement's transaction-fee terms with authorization and decline counts to see whether test traffic is adding charges.
How can I recognize a BIN attack?
Watch for a sudden burst of small transactions or declines, repeated card-validation errors, or attempts that share a card prefix or device pattern. There is no universal attempt count that identifies every attack, so compare activity with your normal checkout volume.