Why BIN Attacks Don't Fear Your Firewall — But Do Fear Your Issuer

Wasif Faisal — Sat, 06 Jun 2026 06:27:40 +0000

Written for: Payment Gateway Product Managers · Bank Risk & Compliance Officers · Fintech Security Architects

I'm an undergraduate security researcher at BRAC University, and payment security has become something of an obsession over the past few months. I've been working through the primary documentation of major payment gateways — developer docs, knowledge base articles, network compliance bulletins — trying to build a clear picture of how card-not-present fraud actually works at an architectural level, not just conceptually.

Some of what I found I didn't expect. I'm writing this up because I think parts of it are underappreciated even by people working inside these systems, and honestly because I want pushback from people with direct industry experience — there's only so far you can get reading documentation.

CVV Checking Is Optional. That's the Whole Problem.

I went through the developer documentation of six major payment gateways — Visa/CyberSource, Stripe, Braintree, Adyen, Square, and Checkout.com — expecting to find differences in how they handle CVV mismatches. What I found instead was a near-identical pattern across all of them:

Not a single gateway enforces CVV matching as a hard, mandatory block by default.

Every one of them treats CVV mismatch blocking as something the merchant has to opt into. The default is to flag the mismatch and let the merchant decide. I kept checking this expecting to find an exception. There isn't one.

This isn't a bug or an oversight — it's a deliberate design decision, mostly driven by conversion rate optimization. But it creates an attack surface that card enumeration operations are specifically built around.

Where This Shows Up in the Docs: Reason Code 230

The clearest documentation of how this works comes from Knowledge Article 000002479 in the Visa/CyberSource knowledge base. It defines Reason Code 230 like this:

"The authorization was approved by the issuing bank, but declined during processing due to CVN mismatch. This is considered a soft decline."

Read that carefully: "approved by the issuing bank." By the time you see Reason Code 230, the bank has already said yes. The CVV mismatch gets caught at the gateway layer, after the bank has authorized the funds. The merchant then decides whether to proceed or reverse.

This creates what I'd call a double-blind problem. The merchant with CVV checks disabled assumes the bank's authorization means the transaction is legitimate. The bank, having approved it based on its own fraud signals, assumes the merchant's side has done appropriate authentication. Neither is checking what the other is doing. Both are making decisions with incomplete information — and both can end up holding the loss.

CyberSource also ships explicit API fields for bypassing the check entirely — these aren't hidden, they're in the public docs:

API	Bypass Field
REST API	`ignoreCvResult: true`
SCMP / Secure Acceptance	`ignore_bad_cv=yes`
Simple Order API	`businessRules_ignoreCVResult=true`

This is not a hidden backdoor. It is published, supported functionality with a legitimate purpose: preventing false declines for valued customers who mistype at checkout.

The Same Pattern, Six Times Over

CyberSource isn't an outlier. I found the same design across every gateway I looked at.

Stripe

Stripe handles CVV through Stripe Radar, its rules engine. Out of the box, a payment goes through even if the CVC check fails. Stripe's own docs are pretty direct about this:

"Without a specific block rule in place, a charge can still be approved by the customer's bank, even if the CVC or ZIP code (AVS) check fails. Banks take a variety of signals into account in their own systems and may see a charge as being legitimate despite the check not passing."

There are two built-in block rules available, but both have to be manually enabled:

Legacy rule (pre-December 2024): if CVC verification fails — hard block on failure
Newer rule (post-December 2024): if CVC verification fails based on risk score — blocks CVC failures unless Stripe's ML model thinks the transaction looks low-risk

The second one is interesting because it means even when you've turned the block rule on, Stripe can still let a CVC failure through if its model disagrees. Neither is active by default.

Worth noting: if no CVC is submitted at all, Stripe returns check_not_performed rather than a failure — so merchants who don't collect CVC at checkout don't even see a mismatch signal.

Braintree (PayPal)

Braintree's handling is probably the most explicit. The official docs just say it plainly:

"If you do not have AVS or CVV rules enabled, we will ignore the response code."

CVV rules live under Fraud Management > Basic Credit Card Fraud Tools > CVV in the Control Panel, and they're off by default. When you do turn them on, you can configure exactly what triggers a rejection — mismatch, not provided, specific card types, transaction amounts, etc.

There's also a transaction-level override in the API:

options.skip_cvv = true

This lets developers skip CVV on individual transactions programmatically, even if account-level rules are enabled. Braintree also routes UnionPay and Maestro cards through CVV-exempt paths since those card types don't carry CVV numbers.

Adyen

Adyen splits CVV checking into pre-authorization and post-authorization phases, and both are off by default.

Adyen's risk management docs are straightforward about this:

"All post-authorization rules are disabled by default."

The CVC post-authorization rule — which can block a transaction after the issuer has approved it but before settlement — must be manually enabled by the merchant in their Customer Area under Revenue & Risk > Risk Profiles > Block. When configuring the rule, merchants choose from options including whether to block transactions where CVC is missing, mismatched, or unchecked.

Adyen's help documentation confirms the default state explicitly:

"The risk rule is disabled by default."

One thing that caught my attention: the CVC rule doesn't apply to recurring transactions at all — it only fires on the initial charge. So if a card gets tokenized without a CVC check (say, a subscription signup where CVV wasn't collected), every subsequent recurring charge processes with no CVC verification. That's by design.

There's also an odd note in the Recurly/Adyen integration docs saying merchants need to contact Adyen support to disable the CVC requirement for recurring billing — framing CVV collection as an operational inconvenience to turn off, rather than a baseline to keep on.

Square

Square's Risk Manager lets merchants build rules based on CVV results, but it's optional. From the docs:

"You can also set your rule to be based on factors such as Square's own risk evaluation, AVS mismatch, invalid CVV, or suspicious transaction amounts."

"Invalid CVV" is one condition you can choose to act on — it's not something that triggers automatically. Without a configured rule, Square passes CVV result codes through without blocking anything (CVV_NOT_CHECKED shows up in API responses). Standard payment flows don't enforce CVV matching at all unless you've set up a Risk Manager rule.

Checkout.com

Checkout.com returns structured CVV result codes through their API:

Code	Meaning
`Y`	CVV matched
`D`	CVV did not match
`N`	CVV should be present but was not provided
`P`	CVV check was not performed
`U`	Issuer does not support CVV
`X`	CVV information not available

A D (mismatch) doesn't trigger a decline on its own. It feeds into the merchant's Fraud Detection risk strategies, where the merchant decides what to do with it. If you haven't configured a rule that says "decline on D", the transaction goes through.

There's also a note in their docs that a Declined - Do not honour response can occur when CVV fails, but that's an issuer-level decline — not something Checkout.com enforces itself.

How BIN Attacks Actually Use This

This is where the gateway documentation findings connect to real attack behavior.

A BIN attack doesn't hit one merchant. It spreads across dozens or hundreds of checkouts simultaneously — specifically targeting merchants that haven't configured CVV blocking, which based on these defaults is most of them. Here's how the attack cycle works:

Phase 1 — Target selection
Small-to-mid e-commerce stores and subscription platforms on default gateway configurations. The attacker knows which gateways default to permissive CVV states because the documentation is public.

Phase 2 — Card number generation
Luhn-valid candidate numbers generated from a target BIN range. BIN databases are commercially available — they map BIN prefixes to issuing bank, card product tier, geography.

Phase 3 — Distributed probing
Candidates submitted through checkouts via rotating residential proxy networks. Each request comes from a different IP. Most merchant velocity controls are useless here because the per-IP volume is one or two requests — well below any threshold.

Phase 4 — Using response codes as an oracle
This is the part that makes CVV architecture directly relevant. A CVV mismatch on a valid, active card number comes back as a soft decline. A hard decline means the number is unissued. The attacker is using the gateway's own response signal to sort valid cards from invalid ones at scale.

Phase 5 — CVV enumeration on confirmed cards
Once a valid card number is confirmed, CVV is a constrained problem: 1,000 possible values (000–999). On a gateway returning soft declines for mismatches rather than hard blocks, the attacker gets a confirmatory signal on every attempt.

Why IP rotation defeats merchant-side defenses
IP throttling, CAPTCHA, device fingerprinting — all of these operate at a layer the attacker routes around entirely. Residential proxy networks provide real ISP-assigned IPs from real users. A probe from Dhaka, then Tokyo, then São Paulo produces no velocity signal at any individual merchant.

The Part Merchants Usually Don't Know: You Lose Your Chargeback Rights Too

There's a second liability problem here that operates completely separately from the issuer side — and it falls on the merchant.

The standard argument for disabling CVV checks is conversion: blocking on CVV mismatch means declining some legitimate customers who mistyped. Accept slightly more fraud risk, reduce false declines, improve revenue. The problem is this calculus ignores what happens when the fraud chargebacks actually arrive.

Under Visa Dispute Condition 10.4: Other Fraud — Card-Absent Environment, a merchant's ability to defend against a fraud chargeback in the pre-arbitration phase depends on submitting valid qualification data. Specifically, the Visa Rules require the merchant to provide:

Data Element	Requirements
Customer account / login ID	Unique identifier used at time of transaction; cleartext, not hashed
IP address	Cardholder's public IP; cleartext; valid IPV4 or IPV6 format
Device ID	Unique device identifier (e.g., IMEI); minimum 15 characters; cleartext
Device fingerprint	Derived from ≥2 hardware/software attributes; minimum 20 characters
Shipping address	Full address including street, city, state/province, postal code, country

This qualification data is the merchant's remedy — the evidence package that allows an acquirer to contest a Dispute Condition 10.4 chargeback on behalf of the merchant. If that data is valid and accurately submitted, the merchant has a defense path. If it is not submitted, or if it is found invalid or falsified, the remedy is forfeit.

In October 2023, Visa operationalized the Visa Fraud Dispute Monitoring Program (VFDMP) to specifically audit this qualification data. If the VFDMP finds submitted data is invalid or falsified: the acquirer, merchant, and service providers get notified, and the merchant's BIN gets suspended from using the Dispute Condition 10.4 remedy entirely until the acquirer confirms to Visa in writing that the issues are fixed.

The connection to CVV bypass is direct. A merchant operating with CVV checks disabled is, by design, processing transactions where the card authentication signal is weak or absent. These are precisely the transactions most likely to generate Dispute Condition 10.4 fraud chargebacks — CNP fraud in a card-absent environment. And when those chargebacks arrive, the merchant's defense depends on the quality of session-layer authentication data collected at the time of the transaction.

A merchant who disables CVV checks and also fails to collect robust device fingerprint, IP, and session data has eliminated their two main lines of fraud defense simultaneously: first-line authentication at the payment layer, and post-fraud chargeback remedy at the dispute layer. The conversion rate optimization translates directly into an unrecoverable revenue loss position.

The liability picture ends up being almost symmetrically bad. The issuer who approved a CVV mismatch transaction can't file a standard chargeback — the liability shift rules prevent it. The merchant who processed it without valid session data can't defend the chargeback — no qualifying evidence. In a CNP fraud scenario where both parties have weak authentication postures, whoever has the weaker documentary position at dispute time absorbs the loss. Under current Visa rules, that's usually the merchant.

Why the Attack Fails at the Bank Level

Merchant defenses don't stop large-scale BIN attacks. The issuing bank is what actually kills them — because the bank sees the full picture that no individual merchant can see.

Cross-merchant velocity aggregation
The issuer sees every authorization attempt against a specific card number regardless of the merchant, gateway, IP address, or session context. A card number receiving 35 authorization attempts from 15 different merchants in 80 minutes is a visible pattern at the issuer — and invisible to any individual merchant.

Card network fraud intelligence layers
Visa Advanced Authorization (VAA) and Mastercard Safety Net operate at the network level, aggregating behavioral signals across all participating acquirers and issuers. Coordinated BIN probing against a single BIN range — even distributed across many merchants — appears as a correlated pattern to network-level analytics that no individual gateway can replicate.

BIN-range velocity locks
When an enumeration attack is detected, issuers can apply velocity controls to the entire BIN prefix, effectively blackholing the attack's remaining candidate set across all merchants simultaneously. A lock on a 6- to 8-digit prefix can neutralize thousands of pending probe attempts with a single policy change.

The liability rule as a fraud-detection incentive
This is the mechanism documented in Visa/CyberSource KA-000002479 — and it is the one with the most direct financial consequence for issuers.

The network liability shift rules are:

Network	Effective Date	Rule
Visa	April 2018	Issuers cannot chargeback a transaction solely on CVV2 mismatch grounds
Mastercard	April 12, 2024	Issuers cannot seek fraud chargebacks for approved authorizations with CVC2 mismatches
American Express	April 2024	Amex will not place chargeback liability on the merchant for CNP transactions with CID mismatch
Discover	Ongoing	Settling CVV mismatch transactions increases fraud risk; no automatic settlement recommended

The implication is precise: an issuer that approves an authorization despite a known CVV mismatch — and that transaction later proves fraudulent — cannot file a standard fraud chargeback. The loss is the issuer's to absorb.

This creates a direct financial incentive for issuers to become active fraud detection stakeholders rather than passive authorization machines. An issuer operating with loose CVV approval policies is not just taking a compliance risk — it is pricing in an asymmetric fraud liability with no chargeback recovery mechanism.

What This Suggests for Risk Teams

I want to be clear that I'm working from documentation, not from running payment infrastructure. But the pattern is consistent enough across six gateways and multiple network rule sets that it seems worth flagging for people in a position to act on it.

For merchants

If you've disabled CVV checking for conversion reasons, the risk isn't just the fraud — it's that you may have also eliminated your ability to fight the chargebacks when they arrive. Under Visa Dispute Condition 10.4, defending a CNP fraud chargeback requires valid session-layer data: IP address, device fingerprint, device ID, login ID, shipping address. If that data is absent or invalid, you can't use the remedy regardless of how the transaction was processed.

Session data should be treated like a legal record. Every transaction needs the full Visa qualification dataset captured in cleartext — not hashed, not synthetic. The VFDMP exists specifically to audit this.

The actual cost of CVV bypass also takes time to materialize. The conversion lift shows up immediately in your metrics. The chargeback losses, processing fees, and potential suspension of dispute remedy rights show up weeks or months later. Most unit economics models I've seen don't capture the full cycle.

For payment gateway product managers

The default states matter more than most people realize. If your gateway ships with CVV blocking off, your onboarding flow is the de facto first line of defense for most of your merchants — and most of them will never go looking for the setting on their own.

Fields like ignoreCvResult: true and skip_cvv are high-risk configurations. A merchant who enables these without compensating fraud signals (3DS, behavioral analytics, device fingerprinting) is carrying elevated enumeration exposure. These probably shouldn't be invisible in your merchant dashboards.

Reason Code 230 velocity is also a detectable attack signal at the gateway layer that most merchants never see surfaced. A spike in soft declines across a narrow BIN prefix from multiple sessions and IPs is a BIN attack in progress — this could be exposed in near real-time.

For bank risk and compliance officers

The liability shift rules have been in place longer than many people realize — Visa since April 2018, Mastercard and Amex since April 2024. Every CVV mismatch authorization your bank approves and that later proves fraudulent is a loss you can't recover through standard chargeback channels. Your CVV mismatch approval rate is worth tracking as a KRI — a rising trend, especially concentrated in specific BIN ranges, is an early signal of either targeted enumeration or compromised card data.

Cross-merchant velocity is the signal that makes the attack visible. Without Visa Advanced Authorization or Mastercard Safety Net feeds providing that cross-merchant dimension, your fraud engine is missing the single most important indicator in a distributed BIN attack. Issuer-level data alone isn't enough.

Wrapping Up

The finding across all six gateways is consistent: CVV verification is not a system-enforced gate. It's a merchant-configurable preference that defaults to off. Attackers have clearly internalized this — the distributed BIN attack methodology is built around it.

The bank is what actually stops large-scale attacks, not merchant controls. Cross-merchant visibility, network-level velocity intelligence, and the liability shift rules that make approving bad CVV data financially painful — these are the mechanisms that matter.

But there's a second layer to this that I didn't fully appreciate going in: the VFDMP means merchants who disable CVV checks are also degrading their ability to defend fraud chargebacks. The conversion optimization and the dispute remedy forfeiture are part of the same decision — they're just separated in time, which makes the tradeoff easy to miss.

The rules are all in place. Visa's liability shift has been active since 2018. The VFDMP enforcement on merchants went live in October 2023. What I can't tell from documentation is how consistently these are being applied in practice — that's where I'd genuinely benefit from input from people working inside these systems.

If you work in payment security, fraud operations, or gateway engineering and something here is wrong or incomplete — I genuinely want to know. I'm an undergrad working from documentation and there's real limit to what you can see without operational experience. Comments or a LinkedIn message both work.

If you found this useful or want to exchange notes on payment security research, connect with me on LinkedIn.

DEV Community: Wasif Faisal