BIN Test: What It Is and How Merchants Detect It

A BIN test is a small authorization attempt, often a low-value purchase, used to check whether a card number is active before it is used for larger fraud. The name comes from the Bank Identification Number, the first six to eight digits of a card number that identify the issuing bank and the card type. Fraud and risk teams watch for BIN test activity because a run of successful tests usually means a card list is being validated against a specific checkout.

What a BIN actually contains

A BIN is not a secret and does not identify a cardholder. It identifies the institution that issued the card, along with the card network and product tier. That is why BIN ranges are used by payment professionals for routing, interchange, and reporting rather than for identifying people. A BIN test therefore tells a fraudster something narrow but useful: whether this particular number will authorize at this particular merchant.

How BIN testing shows up in transaction data

Individual tests are easy to miss. The pattern is what matters. Common signals in authorization logs include:

• Many card numbers sharing one BIN, one IP address, or one device fingerprint
• Unusually small order values that sit just above an authorization threshold
• A high ratio of authorization attempts to completed checkouts
• Decline codes clustered around a narrow value or card range
• New accounts, guest checkouts, or newly created email addresses buying the cheapest item in the catalog

None of those signals is proof on its own. Together they describe a validation pattern rather than a normal customer.

Why merchants care

Every BIN test that reaches the processor costs money. Authorization fees apply whether the transaction settles or not, and a large testing run can push decline rates up until a healthy merchant account starts looking risky to its acquirer. Chargebacks follow later, once the validated numbers are used for real orders. For subscription businesses, a successful test can also create a live recurring billing relationship on a stolen card.

BIN test vs BIN attack

The two terms overlap. A BIN test is a single probe of one card number. A BIN attack is the volume version of the same idea: thousands of numbers from one BIN range pushed through a payment page in a short window, often using bot traffic or a distributed set of IP addresses. A BIN attack is an automated card enumeration event. A BIN test is the unit of measurement inside it.

Detection methods that work

• Velocity rules on attempts per card, per IP, per device, and per BIN within a rolling window
• Address Verification Service and Card Verification Value checks, since a tester often has the number but not the full card details
• Device fingerprinting and IP reputation scoring to group attempts that look unrelated on the surface
• Authorization-to-settlement ratio monitoring for each payment page and each sales channel
• Monitoring of failed attempts, not just approved orders

Prevention controls

Rate limiting is the first line. Cap the number of authorization attempts from a single IP or device, then require a challenge when the cap is reached. Requiring the CVV and a billing address match raises the cost of testing, because those fields are not always included with a leaked number. Blocking or flagging the BIN ranges that generate the most failed attempts helps in the short term, though attackers rotate ranges. For high-risk categories, 3-D Secure authentication shifts liability and interrupts automated scripts. Reviewing attempted transactions weekly, not only settled ones, catches testing runs while they are still small.

What to do after you find one

Log the card numbers, IP addresses, device identifiers, and timestamps involved, then feed them into your rules engine so repeat traffic is blocked. Report the activity to your acquirer or payment processor, since a coordinated attack usually hits several merchants at once. If cardholder data may have been exposed on your side, follow your incident response plan and the notification requirements that apply to your business. Testing traffic that fails is still worth documenting, because the next attempt will often come from a related source.