Detecting BIN Attacks on Shopify

A BIN attack is one of the most damaging automated fraud patterns a Shopify store can face, and it can hit a shop of any size overnight. Attackers take a card's Bank Identification Number — the first six to eight digits that identify the issuing bank — and rapidly generate and test full card numbers against your checkout to discover which ones are live. Your store becomes their free card-validation service.

This tutorial explains what the attack looks like, the velocity signals that expose it, and the checkout-level blocks that shut it down before the fees mount.

What a BIN attack actually is

The Bank Identification Number tells an attacker the issuer and the number format. From one valid BIN, software generates thousands of candidate card numbers, then runs tiny transactions to see which ones authorize. A live card gets sold or used; a dead one gets discarded.

The attacker does not care about your products. They care that your checkout will tell them, for free, whether a stolen card number works.

Why it hurts even when nothing ships

Merchants often assume that if the fraudulent charge is small or gets declined, there is no harm. There is:

• Authorization and gateway fees. Every attempt — including declines — can carry a processing fee. Thousands of attempts add up fast.
• Chargebacks. The successful test charges become chargebacks, each with its own fee.
• Processor penalties. A spike in declines and disputes can trip fraud thresholds and put your merchant account at risk.
• Reputation damage. High decline ratios flag your store to payment networks.
• Real customers blocked. Gateways may throttle your store during the flood, hurting legitimate checkout.

A BIN attack can cost real money without a single product leaving your warehouse.

What the burst looks like

Signals. A card-testing burst has an unmistakable shape once you know it:

• A sudden spike in transaction attempts far above your normal baseline, often hundreds or thousands in minutes.
• A high decline rate. Most attempts fail because most generated numbers are dead — a decline ratio of 80–95% is typical.
• Tiny or identical amounts. Attackers use small charges, often the same low value or a single cheap product, repeated over and over.
• Sequential or clustered card numbers. Many attempts sharing the same BIN, with card numbers marching in near-sequence.
• Repeated CVV/expiry guessing. The same card number retried with different expiry dates or security codes.
• Automation fingerprints. Requests arriving faster than a human could type, from headless browsers or scripted clients.
• Concentrated or rotating origins. Traffic from one datacenter IP, or rotating through a proxy pool to dodge simple rate limits.

Signals. The combination that screams BIN attack is a spike + high decline rate + shared BIN + small amounts. Any one alone might be noise; together they are a card-testing run in progress.

Velocity signals to monitor

Velocity — the rate of activity over time — is the core of BIN-attack detection. Track these and set thresholds against your normal baseline:

• Attempts per IP per minute. Legitimate shoppers do not submit ten checkouts a minute.
• Attempts per BIN per hour. Many cards sharing one BIN in a short window is a strong tell.
• Declines per IP or per session. A cascade of declines from one source is card testing, not a confused customer.
• New cards per device fingerprint. One device trying dozens of different card numbers.
• Failed-CVV rate. Repeated security-code failures on the same or sequential cards.

The trick is thresholds that catch the attack without tripping on a genuine busy period. Baseline your normal traffic first, then alert on deviations from it.

Checkout-level blocks that stop it

Best control. Enforce velocity limits and block automated sources at the checkout level, before the payment attempt reaches your gateway — so the attacker never gets the free "is this card live" answer.

1. Rate-limit per IP, device, and session. Cap checkout attempts in a rolling window and hard-stop sources that blow past it.
2. Block on repeated declines. After a few failed attempts from one source, block further tries automatically.
3. Filter datacenter and proxy traffic. Card-testing bots overwhelmingly run from hosting IPs, VPNs, and proxies — none of which belong at retail checkout.
4. Challenge suspicious sessions. Insert a verification step for high-velocity or automated sessions so scripts stall.
5. Cap attempts per BIN. Limit how many distinct cards sharing one BIN can be tried in a window.
6. Alert on the burst pattern. Get notified the moment attempts spike and declines surge, so you can respond in minutes, not after the invoice.

Enforcing at checkout is the key point: if the block happens before the payment attempt, the attacker learns nothing about the card and moves on to an easier target.

Building all of this by hand — velocity counters, decline tracking, IP classification, and automated blocking — is a heavy lift. Shieldy Fraud Filter applies checkout-level velocity controls, blocks VPN, proxy, Tor, datacenter, and bot traffic, and uses AI fraud scoring to shut down card-testing bursts before they reach your gateway, so the fees and chargebacks never accrue.

Responding to an active attack

If a BIN attack is hitting you right now:

• Turn on strict velocity limits immediately to throttle the flood.
• Block the originating IPs and ranges, especially datacenter and proxy sources.
• Enable a checkout challenge to break the automation loop.
• Notify your payment processor so they know the decline spike is an attack, not your store misbehaving.
• Review recent successful charges for the tested BIN and refund/flag anything suspicious before it becomes a chargeback.

The takeaway

A BIN attack turns your checkout into a free card-testing tool, and the cost lands in fees, chargebacks, and processor penalties whether or not anything ships. Recognize the burst — a spike, high declines, a shared BIN, tiny amounts — watch velocity per IP, BIN, and device, and enforce blocks at checkout before the payment attempt.

Stop the attempt before the gateway sees it and you deny the attacker the one thing they came for. If you want that velocity logic and bot filtering running without building it yourself, Shieldy Fraud Filter has it ready at the checkout level.