Introduction
“Non-VBV” is an informal legacy term that originated around Verified by Visa, Visa’s former branding for its 3-D Secure authentication program. It is commonly used online to imply that a card or transaction does not receive a Verified by Visa challenge.
That description is misleading in modern payments. Verified by Visa evolved into Visa Secure, and Visa Secure now operates using EMV 3-D Secure. Modern EMV 3DS is risk-based: some transactions are authenticated frictionlessly with no visible OTP or bank challenge, while other transactions receive step-up authentication.
This means the absence of a visible authentication screen does not prove that a card is permanently “non-VBV,” that the merchant lacks 3DS, or that the transaction is unprotected. Authentication behavior can depend on the issuer, merchant integration, payment network, country, regulatory requirements, transaction context, device information, and issuer risk decision.
For merchants, the useful security question is therefore not “Which cards are non-VBV?” but “Where can authentication or payment-security coverage be incomplete, and what layered controls reduce the resulting card-not-present risk?” This article answers that question without identifying exploitable merchants, card ranges, or ways to bypass authentication.
Quick Answer: What Does Non-VBV Mean?
Non-VBV usually means “not using Verified by Visa” in older payment-security language.
Verified by Visa was the former name of Visa’s 3-D Secure program. Visa now calls the program Visa Secure, and Visa describes Visa Secure as its EMV 3-D Secure program for reducing customer friction and helping prevent card-not-present fraud.
The term “non-VBV card” is not a reliable formal classification of a modern Visa card. A card that receives no visible challenge in one transaction may receive a challenge in another because modern 3DS authentication is transaction-specific and risk-based.
A more technically accurate modern vocabulary is: 3DS-enabled transaction, frictionless authentication, challenge authentication, authentication unavailable, authentication attempted, or transaction not authenticated—using the actual status returned by the merchant’s payment provider.
Why the Term “Non-VBV” Became Popular
Early Verified by Visa experiences were highly visible. Shoppers were often redirected to an issuer page and asked for a password or one-time code.
Because that challenge was easy to see, people began informally describing checkout experiences as “VBV” when a challenge appeared and “non-VBV” when it did not.
That mental model made more sense during the legacy 3DS1 era than it does today. Modern EMV 3DS specifically supports frictionless authentication, where the issuer can authenticate a transaction without asking the cardholder to perform an extra visible step.
As a result, screen appearance is no longer a reliable way to determine whether authentication occurred.
Verified by Visa Became Visa Secure
Verified by Visa is legacy terminology. Visa’s current program is Visa Secure.
Visa describes Visa Secure as its global EMV 3-D Secure program and says it is designed to make authentication simpler, reduce customer friction, and help prevent card-not-present fraud.
The shift was more than branding. Modern EMV 3DS introduced richer transaction data, better mobile and app support, frictionless authentication, and improved challenge methods.
Therefore, discussions about “VBV cards” should be translated into current concepts involving Visa Secure and EMV 3DS authentication outcomes.
Why a Card Is Not Simply “VBV” or “Non-VBV” Forever
Modern authentication is contextual.
The same Visa card can experience different authentication outcomes across different transactions. One purchase may be frictionlessly authenticated. Another may trigger a banking-app challenge. Another may encounter an issuer or technical condition where normal authentication cannot be completed.
The outcome can depend on the issuer’s risk assessment, merchant implementation, transaction information, regulatory rules, payment channel, device context, and supported EMV 3DS version.
That makes permanent labels such as “VBV card” and “non-VBV card” technically weak. Authentication status belongs to the transaction flow more than to a simplistic permanent card category.
No OTP Does Not Mean No 3DS
One of the most important misconceptions is that 3-D Secure exists only when the customer receives an OTP.
EMVCo describes EMV 3DS as supporting seamless authentication designed to prevent card-not-present fraud without adding unnecessary checkout friction.
A low-risk transaction can therefore be authenticated in a frictionless flow without a visible OTP, password, or banking-app prompt.
For merchants, the correct source of truth is the authentication result supplied through the gateway, acquirer, or 3DS provider—not what the checkout looked like to the shopper.
What Is a Frictionless Authentication Flow?
In a frictionless flow, the issuer determines that it has enough information to authenticate the transaction without requesting an additional action from the cardholder.
EMV 3DS allows transaction and contextual information to be exchanged so issuers can evaluate risk more intelligently.
A frictionless transaction may look almost identical to a checkout with no authentication at all from the customer’s perspective.
This is precisely why the old “VBV vs non-VBV” visual classification no longer works.
What Is a Challenge Flow?
A challenge flow occurs when the issuer needs additional proof that the person initiating the payment is authorized.
Depending on the issuer and supported authentication methods, the cardholder may be asked to approve through a banking application, provide a one-time code, use biometrics, complete out-of-band authentication, or use another approved method.
Modern EMV 3DS therefore concentrates visible friction where additional verification is considered useful rather than necessarily challenging every transaction.
What Is an Authentication Gap?
An authentication gap is a situation in which a remote payment does not receive the level of customer authentication the merchant would ideally want for the transaction risk.
That can arise for legitimate technical or ecosystem reasons: the issuer may not support a particular authentication capability, the payment route may not provide the expected result, a merchant may have incomplete integration, a transaction may fall outside a normal interactive flow, or a technical failure may occur.
An authentication gap should not be interpreted as a guaranteed fraud opportunity. Payment authorization, issuer risk controls, merchant fraud systems, tokenization, account controls, and transaction monitoring still operate independently.
For merchants, gaps should trigger stronger risk management—not assumptions that a payment is automatically safe or automatically fraudulent.
Authentication Is Not Authorization
3DS authentication and card authorization are different processes.
Authentication asks whether the person making the remote transaction appears authorized to use the payment account.
Authorization is the issuer’s separate decision about whether the payment itself should proceed.
Even a transaction without a successful visible 3DS challenge still passes through payment authorization, where the issuer can consider account status, fraud indicators, available funds or credit, merchant information, and other controls.
Likewise, a successfully authenticated transaction can still be declined during authorization.
Why Merchants Should Not Rely on 3DS Alone
EMV 3DS is an important card-not-present fraud control, but no single security layer eliminates online payment fraud.
Fraud can involve account takeover, phishing, malware, compromised payment pages, social engineering, first-party misuse, stolen card data, or abuse of legitimate accounts.
Merchants therefore need layered controls that protect the payment page, customer account, payment credential, transaction decision, and post-transaction fulfillment process.
Visa and EMVCo position 3DS as an authentication layer within the broader payment ecosystem, not as a substitute for every other control.
Merchant Defense 1: Use Modern EMV 3-D Secure
Merchants should integrate current EMV 3DS through a reputable acquirer, processor, gateway, or 3DS provider.
Modern 3DS gives issuers richer information for authentication decisions and supports frictionless and challenged flows.
Merchants should send accurate transaction and customer-context information permitted by the protocol so issuers can make higher-quality decisions.
They should also monitor authentication success, challenge rates, frictionless rates, unavailable results, technical failures, and downstream authorization outcomes.
Merchant Defense 2: Treat Authentication Results as Risk Signals
Authentication outcomes should feed the merchant’s fraud-decision system rather than being reduced to a simplistic “VBV/non-VBV” flag.
A merchant should distinguish successful authentication, frictionless authentication, challenge success, authentication attempt, unavailable results, and technical failure according to its payment provider’s actual documentation.
Different outcomes may justify different levels of transaction scrutiny, but merchants should avoid publishing or hard-coding universal rules that criminals could use to predict approval behavior.
Risk rules should be tuned using the merchant’s own fraud data and monitored for false declines.
Merchant Defense 3: Use Strong Fraud Analytics
Fraud analytics can evaluate signals beyond card authentication.
Useful defensive context can include customer account history, device characteristics, transaction velocity, prior disputes, behavioral anomalies, order history, merchant-specific patterns, and other legitimate risk signals.
No single signal should automatically determine fraud. Modern decisioning combines multiple indicators to distinguish suspicious behavior from legitimate customers with unusual circumstances.
The goal is to reduce fraud without creating excessive false declines.
Merchant Defense 4: Secure Customer Accounts
A transaction can appear legitimate if a criminal has taken over a real customer account.
Merchants should therefore protect customer logins with strong password practices, multi-factor authentication where appropriate, login anomaly detection, secure password-reset processes, and protection against credential stuffing.
Changes to saved payment methods, delivery addresses, email addresses, or account recovery settings can deserve additional risk scrutiny when they occur near a purchase.
Strong payment authentication cannot fully compensate for weak customer-account security.
Merchant Defense 5: Use Tokenization
Tokenization reduces exposure of reusable payment credentials by replacing the underlying account number with a substitute digital value in supported payment environments.
Card-on-file systems and digital wallets can use tokenized credentials so merchants do not repeatedly handle the original PAN.
Tokenization does not replace customer authentication, but it reduces the consequences of certain data exposures and strengthens the broader payment-security architecture.
Merchant Defense 6: Maintain PCI DSS Controls
PCI DSS provides baseline technical and operational requirements for protecting payment-account data.
Merchants that store, process, transmit, or can impact the security of cardholder or sensitive authentication data fall within the payment-data security ecosystem covered by PCI DSS.
Strong 3DS authentication does not excuse weak handling of payment data. A merchant can authenticate customers perfectly and still suffer serious fraud if its checkout page or backend systems leak card information.
Merchant Defense 7: Protect the Payment Page Against E-Skimming
E-commerce payment pages are a major security boundary because malicious scripts can steal payment data before or during checkout.
PCI SSC’s current e-commerce guidance highlights PCI DSS requirements 6.4.3 and 11.6.1, which focus on authorizing payment-page scripts, checking script integrity, and monitoring payment pages for unauthorized changes.
These controls address a different part of the fraud lifecycle from 3DS. 3DS authenticates a customer; payment-page security helps prevent payment credentials from being stolen in the first place.
Merchants need both.
Merchant Defense 8: Use CVV and AVS Appropriately
CVV and AVS can provide additional transaction context where supported.
CVV validates a card-verification value, while AVS compares billing-address information against issuer-recognized information.
Neither check authenticates the buyer by itself, and neither should replace 3DS or fraud analytics.
Merchants should use the actual result codes supplied by their payment provider rather than simplistic universal rules.
Merchant Defense 9: Protect Fulfillment
Fraud prevention does not end when authorization succeeds.
For goods and services that are not delivered instantly, merchants may have an additional opportunity to identify suspicious transactions before fulfillment.
Order review can consider legitimate signals such as account history, authentication outcomes, transaction behavior, unusual changes to customer information, and merchant-specific fraud patterns.
The faster suspicious activity is detected, the more likely the merchant can prevent loss of both funds and merchandise.
Merchant Defense 10: Monitor Chargebacks and Fraud Trends
Post-transaction data is valuable security intelligence.
Merchants should analyze confirmed fraud, disputes, chargebacks, authentication outcomes, product categories, account behavior, and false declines to understand where controls are failing.
A merchant whose fraud rules never change while attacker behavior evolves will eventually develop blind spots.
Fraud models and authentication strategies should therefore be reviewed continuously using current merchant data and payment-network guidance.
What About Transactions Where 3DS Is Unavailable?
Authentication can sometimes be unavailable because of issuer participation, technical conditions, unsupported flows, or payment-routing circumstances.
An unavailable result is not the same as a successful authentication, but it is also not proof that the transaction is fraudulent.
The merchant should apply its documented risk policy using additional evidence such as account history, transaction context, fraud analytics, payment-provider recommendations, and applicable network or regulatory rules.
High-risk merchants or transactions may choose more conservative policies, while lower-risk contexts may use additional review rather than automatic rejection.
Should Merchants Automatically Decline Every Non-Authenticated Transaction?
Not necessarily.
A universal rule can create unnecessary false declines because authentication availability and requirements vary by issuer, region, transaction type, regulation, and payment flow.
At the same time, automatically approving every non-authenticated transaction would ignore a valuable risk signal.
The correct approach is a documented risk-based policy informed by the merchant’s payment provider, card-network rules, regulatory obligations, transaction characteristics, and historical fraud data.
3DS and Liability Shift
One merchant benefit of 3DS can be liability shift for certain qualifying fraud-related disputes.
Visa states that successful authentication can reduce fraud risk and may shift liability away from the merchant under applicable program rules.
Liability shift is not universal. Eligibility can depend on region, authentication status, transaction type, network rules, exemptions, and other conditions.
A merchant should never assume that “3DS enabled” means immunity from every fraud dispute or chargeback.
Why “Non-VBV Merchant Lists” Are Misleading
Lists claiming that particular merchants are permanently “VBV” or “non-VBV” are technically unreliable and can quickly become outdated.
Authentication is often transaction-specific. Merchant integrations change. Issuers update risk models. Payment providers change routing. Regulations evolve. A frictionless flow can also make a protected transaction look visually unauthenticated.
For legitimate merchant security work, the correct evidence comes from actual gateway and 3DS authentication data—not crowd-sourced lists claiming which websites do or do not show a challenge.
Publishing or using such lists as a targeting mechanism also shifts the discussion away from defensive security toward misuse rather than helping merchants strengthen payment controls.
How Consumers Should Interpret “Non-VBV” Claims
Consumers should be cautious with websites, social-media posts, or forums that market cards or merchants as “non-VBV.”
The phrase is outdated and is frequently used in contexts that misunderstand modern EMV 3DS or promote payment-card abuse.
A legitimate customer does not need to search for merchants with weaker authentication. They should use trusted merchants and complete issuer authentication when requested.
If an unexpected 3DS challenge appears for a purchase the customer did not initiate, they should reject it and contact the card issuer using an official channel.
How Consumers Can Improve Online Payment Security
Consumers can reduce risk by using trusted merchants, enabling transaction alerts, protecting their email and banking accounts with strong authentication, keeping issuer contact information current, and reviewing statements regularly.
They should never send OTPs, banking passwords, PINs, or authentication approvals to someone who unexpectedly contacts them.
If card information is suspected to be compromised, the cardholder should contact the issuer promptly, report unauthorized activity, and follow the issuer’s card-locking or replacement instructions.
Common Myths About Non-VBV Cards
Myth: A non-VBV card is a formal Visa product category. Reality: “non-VBV” is informal legacy terminology, not a reliable modern card classification.
Myth: No OTP means no 3DS. Reality: EMV 3DS can authenticate transactions frictionlessly without a visible challenge.
Myth: A card that is frictionless once will always be frictionless. Reality: authentication decisions can differ from one transaction to another.
Myth: A transaction without successful 3DS has no fraud protection. Reality: issuer authorization, merchant fraud analytics, tokenization, account controls, and other defenses may still apply.
Myth: 3DS eliminates all online fraud. Reality: it is an authentication layer within a larger security architecture.
Myth: A merchant can safely approve everything that passes 3DS. Reality: authenticated transactions can still involve other fraud or dispute scenarios.
Myth: Lists of “non-VBV sites” accurately describe merchant security. Reality: authentication behavior is dynamic and merchant/payment configurations change.
Conclusion
The phrase “non-VBV card” comes from an older generation of online payment authentication and no longer describes modern Visa security accurately.
Verified by Visa became Visa Secure, while the underlying 3-D Secure technology evolved into a risk-based authentication framework capable of working frictionlessly or presenting a challenge when greater verification is required.
For merchants, the important issue is not identifying cards that appear to avoid a particular screen. It is understanding the actual authentication result for each transaction and building defenses that remain effective even when authentication is unavailable, incomplete, or insufficient by itself.
The strongest approach combines modern EMV 3DS with secure payment pages, PCI DSS, tokenization, fraud analytics, account protection, transaction monitoring, and disciplined fulfillment controls.
In modern payment security, “VBV vs non-VBV” is the wrong question. The better question is whether the transaction has enough independent security layers to remain resilient when any single control is absent or fails.
