BIN Attack: What It Is and How to Stop It on Your Store

Short answer: a BIN attack is card testing with made-up card numbers. The attacker takes a real bank identification number (BIN), the first six or eight digits that identify the card issuer, generates the remaining digits so each number passes the standard check-digit test, and fires the numbers at a checkout with guessed expiry dates and security codes until some are approved. You see it as a burst of declines on cards that all start with the same digits. You stop it by limiting failed payments on every checkout endpoint, challenging risky sessions, and, during an attack, blocking or reviewing the BIN being used.

This page is the BIN-specific angle. For card testing in general on WooCommerce, including the Store API problem and WooCommerce's own rate limiter, read WooCommerce card testing. For how Visa now measures this kind of attack, read Visa VAMP 2026.

BIN attack or ordinary card testing?#

Both use your checkout to find working cards. The difference is where the card numbers come from, and that changes what you see and what works.

Visa groups both under enumeration, which it describes as "a rapid, brute force card testing attack at scale". In its VAMP program it counts enumerated authorizations, approved and declined, against acquirers and merchants. The thresholds are covered in the VAMP guide.

How a BIN attack works#

1. The BIN gives away the start of the number#

A card number (PAN) begins with the issuer's identification number. Visa's action sheet on the change says BINs "comprise the first digits of the Primary Account Number" and are governed by ISO. It also says ISO agreed to expand the issuing BIN "from six to eight digits" and announced the new standard, ISO/IEC 7812-1, in 2017. From April 2022, Visa acquirers and processors had to support the new length, while "issuers can set their own timeline" to move. So today both six-digit and eight-digit BINs are in use.

BINs are not secret. The same action sheet says they exist to identify the financial institution "to stakeholders within the payment ecosystem", and every card carries one in its number. That is why an attacker can pick one.

2. The check digit makes guessing cheaper#

The last digit of a card number is a check digit calculated with the Luhn algorithm, which is specified in ISO/IEC 7812-1. It catches typing mistakes, but as the Luhn article puts it, it was "designed to protect against accidental errors, not malicious attacks". A script can therefore skip every number that fails the check and only submit numbers that look valid, so the guessing goes much faster than trying every possible number.

3. Expiry dates and security codes are guessed too#

A generated number still needs an expiry date and, on most checkouts, a security code. Researchers at Newcastle University showed in December 2016 that a Visa card's number, expiry date and security code could be found by guesswork, spreading guesses across many websites. They wrote that each site allowed "typically 10 or 20 guesses" before blocking, and that Mastercard's centralized network detected the attack "after less than 10 attempts", while only the Visa network was vulnerable in their tests. That research is nearly ten years old and networks have changed since, but the method is the reason per-site limits matter: every checkout that allows unlimited attempts is one more place to guess.

4. Approved numbers are used or sold#

Stripe's card-testing guide says that once attackers identify valid cards, "they can cash them with merchants or resell confirmed cards on the dark web." Your store pays for the attempts, and another merchant, or you, later pays for the fraud.

Signs of a BIN attack in WooCommerce and Stripe#

In WooCommerce#

• A sudden run of Failed or Pending payment orders, often for your cheapest item or a donation or "pay what you want" product.
• Different names and emails on every order, but the same few shipping or billing details, or obviously fake ones.
• Orders arriving faster than a person could type, sometimes with no visit to the checkout page, because the script posts straight to the Store API. WooCommerce's developer blog reported on 18 December 2024 that it had seen "card attacks specifically targeting the Store API alone, even without the use of the Checkout block". The card testing guide explains the endpoint.
• Order notes from your gateway showing the same card brand again and again. Whether you can see more than that depends on the gateway: most card gateways turn the card into a token in the shopper's browser, so the BIN and last four never reach your server.

In Stripe#

Stripe's guide lists three symptoms of card testing: "a spike in failed or blocked payments", "a spike in requests with 402 errors", and "a spike in suspicious payments with low transaction amounts, often with nonsensical customer names and emails". For a BIN attack, look at the decline codes too. Stripe documents these, and a BIN attack produces a lot of them:

Stripe also tells you to show shoppers a generic message for codes such as fraudulent, stolen_card and lost_card, so an attacker does not learn why a card failed. Do the same in any custom error text.

Finally, Stripe's Radar has a card_bin attribute, "the first six digits of the card number", which lets you see and write rules on the BIN being attacked. If most failed payments in the last hour share one value, you are looking at a BIN attack.

What it costs to ignore#

A BIN attack hurts even when almost every attempt is declined:

• Fees. Stripe notes that card testing "can result in additional fees, such as authorization fees for custom pricing plans, and dispute fees."
• Your approval rate. Stripe says a high decline rate "might damage the reputation of your business with card issuers and card networks, which makes all of your transactions appear riskier", which can raise declines for real customers "even after card testing ceases."
• Card network measures. Visa's VAMP fact sheet defines an enumeration ratio as enumerated authorizations (approved and declined) divided by all authorizations, with thresholds of 20% (2,000 basis points) and 300,000 enumerated transactions, and it "requires acquirers to take proactive steps to prevent merchants from exceeding enumeration thresholds." Your payment provider carries that pressure to you.
• Fraud afterwards. The guesses that succeed turn into real fraud, fraud reports and disputes.

How to stop a BIN attack#

Work through these in order. The first three are the same layers that stop any card testing; the rest are specific to BIN attacks.

1. Limit failed payments, not just requests#

A BIN attack makes many failed attempts per approved card, so counting failures is the most direct control. Count them per IP address, per IP network, per email, per browser and per session, because the attacker rotates names, emails and often IP addresses. The card testing guide gives starting limits.

2. Cover every endpoint a card can reach#

That means the classic checkout, the Store API checkout, the pay for order page and the add payment method form. Stripe points out that card testers like the card setup route because "card validation and authorizations during card setup don't typically show up on cardholder statements", so a saved-card form with no limits is an easy target.

3. Add a challenge for risky sessions#

Stripe's guide recommends CAPTCHA and says to make sure it "requires validation on all requests that enable card validations or payments" and is checked on the server side. A challenge is especially effective against BIN attacks because the attack depends on volume: if each try needs a solved challenge, guessing becomes too slow to pay.

4. Use the BIN during the attack, carefully#

Once you know which BIN is under attack, you can act on it at the gateway. In Stripe, Radar's rule language supports card_bin and lists, so a temporary rule such as Review if :card_bin: = '412345' (with the real BIN) or a block rule on a list of attacked BINs can stop a wave. Two cautions:

• A BIN covers every card from that issuer range, so a block rule also stops your real customers with those cards. Prefer review, or a block with a time limit, and remove it when the attack ends.
• Attackers move to another BIN. A BIN rule buys time; it is not your defence.

Custom rules are a paid Radar feature. On Stripe's Radar pricing page, checked 26 October 2026, Radar Standard (from $10 a month for businesses) includes default rules and lists, and custom rules with backtesting start at Radar Plus (from $14 a month). Radar Lite is described as included "at no additional charge for businesses on standard payments pricing", with card-testing prevention but not custom rules.

5. Add velocity rules where your gateway supports them#

Stripe's Radar has velocity attributes that fit a BIN attack, including declined_charges_per_ip_address_hourly, declined_charges_per_email_hourly and card_count_for_ip_address_hourly (cards seen from one IP address). Stripe says velocity attributes are commonly used "to reduce card testing or enumeration attack scenarios". Remember that these run when the payment reaches Stripe, after WooCommerce has created the order. Limits inside WooCommerce stop the attempt earlier.

6. Do not give the attacker feedback#

Show one generic decline message for every failure. If your checkout says "incorrect security code" for one card and "expired card" for another, you are helping the script narrow its guesses.

7. Clean up#

Cancel the failed orders, refund any order that succeeded during the attack before it becomes a dispute, tell your payment provider, and keep a note of what you changed. The full cleanup list is in the card testing guide.

Which control fits which situation?#

What "BIN attack software" can and cannot do#

People search for BIN attack software meaning two things: the tools criminals use to generate numbers, and the tools merchants use to stop them. This section is about the second.

Any tool you consider should answer these questions in writing:

1. Does it count failed payments on the classic checkout and the Store API, or only requests or orders?
2. Can it limit per IP network, browser and session, since a BIN attack rotates everything else?
3. Can it count per card? Most card gateways tokenize the card in the browser, so a WooCommerce plugin only sees the BIN and last four if the gateway passes them back. Ask which gateways it reads card details from.
4. Can it show a challenge only to risky shoppers, and turn on a stricter mode when failures spike?
5. Does it read the gateway's risk results so you can see the attack from both sides?

The plugin-by-plugin view is in WooCommerce anti-fraud plugins compared, and the wider tool categories are in ecommerce fraud prevention software.

How ChargeWarden stops BIN attacks on WooCommerce#

ChargeWarden counts checkout attempts and failed payments on the classic checkout, the Store API checkout, the Store API pay for order route, the pay for order page and the add payment method form. By default it blocks an IP address after 5 failed payments in 10 minutes, a /24 or /64 network after 12, an email after 4 in an hour, a browser after 5 in an hour and a session after 3 in 10 minutes. Every limit can be changed. See how the limits work.

To be exact about card counting: ChargeWarden also has a per-card limit (BIN, meaning the first six digits, plus last four, 3 failures in an hour by default), but it applies only when the gateway exposes card details. Most card gateways tokenize the card in the browser, so the BIN and last four are not posted to your server. ChargeWarden reads PayPal Payments' saved last four after a payment, and developers can supply card details for other gateways with the chargewarden_order_card and chargewarden_request_card filters. Without card data, the IP, network, email, browser and session limits still apply, and those are the ones that catch a BIN attack's rotating identities. The gateway risk data doc lists exactly what it reads from each gateway.

During an attack, attack mode divides every limit by three, asks every shopper for a Cloudflare Turnstile or hCaptcha check if you set one up, and refuses checkouts that did not run your checkout page's script, which scripts posting straight to the Store API do not. It turns on by itself when failed payments store-wide reach 30 in 10 minutes, by default. ChargeWarden does not block BINs at the gateway; for that, use your gateway's own rules, such as Radar.

Watch blocked attacks and attack mode on the live demo, then choose a plan. On our pricing page on 26 October 2026, ChargeWarden is $129 a month for one store, $199 for 5 stores and $349 for unlimited stores.

This guide is general information, not legal or financial advice. Card network rules, gateway features and prices change; confirm current terms with your payment provider. Visa, Mastercard, Stripe, PayPal and WooCommerce are trademarks of their owners. PluginLoom is not affiliated with or endorsed by them.