BIN Attack Fraud: How It Works and How to Respond

BIN attack fraud is automated payment-credential testing involving card-number ranges. Merchants detect and mitigate it through abnormal attempt patterns, layered abuse controls, and coordination with their payment provider. Because the attempts run through an online checkout with no physical card, every one of them is a form of card not present fraud.

{{cta}}

O que é a fraude por ataque BIN?

A Bank Identification Number (BIN) is the first six to eight digits of a payment card, and it identifies the issuing bank. So what is a BIN attack? Automated software submits large numbers of payment attempts at a merchant's checkout or payment endpoint using card numbers built around one BIN, which is why you will also see it called a credit card BIN attack, BIN attack credit card testing, or simply BIN fraud. The goal is to learn which card details a payment network will accept. A small share of attempts may succeed, and most fail.

This is why a BIN attack is also called card testing or an "enumeration" attack. For a closer look at how testing-style fraud shows up across payment types, see understanding card testing fraud attacks. This page stays at the defensive level and does not describe how to generate or test card credentials.

The problem is common. The Merchant Risk Council 2026 Global eCommerce Payments and Fraud Report, based on a survey fielded in November and December 2025, lists card testing among five attack types that each affect at least one-third of merchants globally.

Como funciona, na prática, a fraude do tipo “ataque BIN”?

How does a BIN attack work, at a defensive level? It is automated abuse of your checkout. According to the Stripe card-testing guidance, card testing is an automated abuse pattern that calls for checkout defenses and coordination with your payment provider. Your store is used as the place where card details get checked.

What a merchant sees from the inside is a set of event counts that behave differently:

These are different event populations, so a large attack can show up in attempts and declines while settled sales barely move. The attack often blends in with legitimate traffic, which is what makes it dangerous for fast-growing brands processing high transaction volumes.

Which Checkout Endpoints Do Attackers Target?

According to Stripe's card-testing guidance, testers go after endpoints that let them save a card or make a payment, so those are the first places to restrict.

Tipos de fraudes por ataque BIN

Os ataques BIN se apresentam de algumas formas distintas, e é útil saber com qual delas você está lidando:

Quais são os sinais de alerta de um ataque BIN à sua loja?

The clearest sign of a BIN attack is a sudden, abnormal spike in declined transactions, often paired with tiny or zero-dollar charges. Compare attempts and declines with your store's normal pattern, and catch these red flags early.

Check each signal against your own baseline by hour and endpoint, and contact your payment provider if the pattern holds.

Por que os ataques ao BIN prejudicam sua empresa além das perdas decorrentes de fraudes?

BIN attacks can cost more than the fraudulent purchases themselves. Depending on your provider's pricing, failed and approved attempts can carry processing fees, and a large attack can generate thousands of attempts in minutes, so check your fee schedule and how your provider treats declined traffic. See the broader chargeback statistics for context on how this fits the wider fraud picture.

Test charges that settle and get noticed by cardholders become disputes, with chargeback fees on top of the lost goods. Disputes feed your chargeback ratio, and card network monitoring programs, covered in current chargeback threshold limits, can bring fines, remediation requirements, and in serious cases the loss of processing. For the US, Visa VAMP’s standard Excessive Merchant criteria pair at least a 1.5% combined fraud-and-dispute ratio (from April 1, 2026) with at least 1,500 monthly fraud-and-dispute records, when the acquirer is not Above Standard or Excessive. The ratio divides the combined count of TC40 fraud reports and TC15 disputes by the count of settled TC05 card-not-present VisaNet transactions; apply exclusions and country and regional rules. The Mastercard Excessive Chargeback Program uses current-month chargebacks against previous-month captured payments and separate count and ratio conditions. A ratio alone does not establish program status or penalties. Terms depend on your acquirer agreement.

Visa monitors enumeration separately from the dispute ratio inside the Visa Acquirer Monitoring Program (VAMP). The Visa VAMP fact sheet defines the VAMP ratio as the combined count of fraud reports (TC40) and disputes (TC15) divided by the count of settled card-not-present VisaNet transactions (TC05). The enumeration ratio instead divides enumerated authorization attempts by all authorization attempts, approved and declined, and the sheet lists a monthly ratio of at least 20% together with at least 300,000 enumerated authorization transactions in that same month. Do not use settled transactions as the enumeration denominator, and do not read the enumeration test as a received-dispute ratio. Thresholds are conditioned on acquirer context, and the sheet describes Visa programs only, so confirm the terms that apply to you with your acquirer.

Os custos ocultos também vão se acumulando:

• Processor scrutiny and possible reserve requirements once your decline rate spikes.
• Staff hours spent investigating spikes, blocking IPs, and answering cardholder complaints.
• Pressão sobre o atendimento ao cliente por parte dos titulares de cartões que percebem as cobranças de teste antes de você.
• Lost sales during the attack window if legitimate checkout traffic gets throttled or blocked alongside the automated traffic.
• Lower approval rates for real customers, because Stripe notes that a high decline count makes issuers and networks treat all of your transactions as riskier, even after the testing stops.

Treat BIN attack defense as one layer of your wider ecommerce fraud prevention program, because the second-order effects on your dispute ratio and merchant standing can outweigh the direct theft.

Como PREVENÇÃO e mitigar fraudes relacionadas a ataques BIN?

BIN attack prevention takes layers, not a single tool. To prevent a BIN attack on a credit card checkout, start by limiting automated traffic at checkout and the payment endpoint, then add verification signals, then review what slips past both layers. This layered approach mirrors the broader chargeback mitigation playbook every merchant needs.

The Stripe AVS and CVC verification guidance notes that verification results are context, not conclusive identity proof, so treat AVS and CVV as inputs to a decision rather than a verdict. These controls reduce the noise, but attackers adapt. Not every dispute after an attack is true fraud, and a claim alone does not show intent, so review the evidence before treating a dispute as friendly fraud.

Payment service providers can enforce some of these controls at the gateway level, but the strongest programs combine provider-level rules with a dedicated fraud and dispute layer. Stronger rules also raise the risk of blocking good customers, a problem covered in fraud false positives. A sound chargeback risk management process weighs both sides.

Use a Defensive Incident Timeline

When an attack is underway, work in phases so that containment does not hide the evidence or block real customers. Track the attack at the authorization layer, not only in the chargeback dashboard.

A fraude por ataque BIN pode levar a um “ Chargebacks ”?

It can. Some successful fraudulent payments may later be disputed. When a legitimate cardholder does not recognize a charge, they can dispute it with their bank, which is a chargeback. If the issuer finds the charge fraudulent, the payment can be reversed to the cardholder, and the merchant may lose both the goods and the transaction. Not every authorization or validation becomes a settled chargeback, so keep attempts and received disputes as separate counts. Card-absent fraud disputes typically arrive under fraud reason codes such as Visa 10.4, Other Fraud: Card-Absent Environment (see Visa chargeback reason codes). Refunding a settled test charge before the cardholder disputes it keeps it out of your dispute count, and chargeback alerts give you the window to do that.

Each dispute also raises the total you track when you calculate your chargeback ratio, and enough of them can push you toward card network monitoring programs. Recovering disputes with chargeback management tools like Chargeflow Automation matters as much as blocking the attack in the first place.

Perguntas frequentes

Qual é a diferença entre um ataque BIN e o teste de cartão?

A BIN attack is a form of card testing in which card numbers are built around one known Bank Identification Number. Card testing is the broader term for any scheme that checks stolen or guessed card details through small transactions. In practice the two overlap heavily, and both flood a store with rapid, low-value authorization attempts.

Em que o ataque BIN difere da quebra de senha de cartão?

The term card cracking is used in more than one way. Where it describes a scam that recruits account holders to hand over card details for promised quick money, the entry point and the victim differ from a BIN attack, which runs automated attempts against a checkout. Where it describes guessing missing card details at checkout, it overlaps with a BIN attack. Ask your provider which meaning a report uses.

É possível que ocorra um ataque BIN sem que haja uma violação de dados?

Yes. A BIN attack does not require access to your systems. Automated software can submit attempts against any exposed checkout, so your store is simply the place where details get tested, which is why even well-secured merchants get hit. Rate limiting, CAPTCHA, and provider abuse controls are the first line of defense, with post-checkout review as a further layer.

Como os ataques BIN levam a um “ chargebacks ”?

Some successful fraudulent payments may later be disputed by the legitimate cardholder, leaving you facing lost goods plus chargeback fees. Each received dispute counts toward your chargeback ratio. Not every authorization or validation becomes a settled chargeback, and Visa tracks enumeration separately from the dispute ratio.

Can a BIN attack harm a merchant without completed sales?

Yes. A BIN attack can create operational and payment-system exposure through attempted authorizations even when few sales settle. Monitor attempts separately from received chargebacks.

Does a post-checkout fraud tool replace card-testing controls?

No. Post-checkout controls can help review successful suspicious orders, but upstream card-testing mitigation requires checkout and payment-provider abuse controls.

What does BIN mean in scamming?

In fraud-forum slang, a "BIN" often means a card-number range from one issuer, or a list of numbers within it, that someone plans to test. The BIN itself is not secret: it is the first six to eight digits of a card and only identifies the issuing bank. For a merchant, the practical meaning is a cluster of attempts that share the same prefix at your checkout, so defense focuses on limiting attempt volume rather than hiding anything.

How common is card testing?

At least one-third of merchants globally are affected, according to the Merchant Risk Council 2026 Global eCommerce Payments and Fraud Report, based on a survey fielded in November and December 2025. The report places card testing among five attack types at that level, and MRC members report it more often than non-members.

Should I block the BIN used in an attack?

Temporarily, yes, if attempts cluster on one BIN and you can set an expiry. A BIN block also stops real customers who hold cards from that issuer, so pair it with rate limits and CAPTCHA, watch approvals for that issuer while the rule is live, and remove it once attempt volume returns to baseline.

O que devo fazer se achar que estou sendo alvo de um ataque BIN?

Enable rate limiting and CAPTCHA on your checkout to slow the automated traffic, then contact your payment provider to flag the activity and ask about supported abuse controls. Review your transaction logs for the targeted BIN and block the offending IPs. Use your payment provider's authorization reports to confirm when attempts stop, use Chargeflow Insights to watch your dispute rate for delayed fraud reports, and check that legitimate checkout still works.

Acabe com a fraude de ataques BIN na origem

Stop the testing with checkout and provider controls, add Chargeflow Prevent to review orders after checkout and before fulfillment, and recover the disputes that still slip through with Chargeflow Automation.