Verified by Visa (VbV / Visa Secure / 3D Secure)

Verified by Visa (VbV) is the consumer-facing brand Visa used between 2001 and 2019 for its implementation of the 3D Secure authentication protocol on online card payments. It's been rebranded as Visa Secure, but plenty of merchants, agreements and old checkout pages still call it VbV. Mastercard's equivalent was SecureCode, now Identity Check; Amex's is SafeKey. Behind the brand it's the same idea — when you pay online, your bank gets the chance to confirm it's really you before the transaction is approved.

Verified by Visa, now marketed as Visa Secure, is Visa's wrapper around the 3D Secure protocol. The protocol routes the authentication request through three domains — Visa's network, your bank, and the merchant's payment provider — so the bank can decide whether to approve the payment silently or ask you to verify yourself. Most flows you see in 2026 are running 3D Secure 2 (3DS2), not the original 1.0 spec, which Visa retired for new merchants in October 2022.

Where the name came from, and why it changed

Visa launched VbV in 2001 to bolt an authentication step onto online card payments, which were exploding alongside e-commerce and racking up fraud at rates the card networks couldn't ignore. The pitch to consumers was simple: register a password with your bank, type it in at checkout, and you'd be protected. The pitch to merchants was simpler still — if you implement VbV and the customer authenticates successfully, fraud chargeback liability shifts from you to the issuing bank.

The execution was rough. Customers forgot their VbV passwords constantly, the redirect to the bank's authentication page looked like a phishing attack, and on mobile it was actively bad. Merchants who turned it on watched their conversion rates fall by double digits. By the mid-2010s, the industry had agreed VbV 1.0 was a security upgrade that was costing more in lost sales than it was saving in fraud.

The rebrand to Visa Secure in 2019 wasn't just cosmetic. Visa wanted to retire the consumer-trained habit of typing a static password and signal a clean break to the data-driven authentication 3DS2 enables. The brand change also brought Mastercard, Amex, JCB, and Discover into closer alignment, since they all rebranded their consumer-facing 3DS programmes around the same time. If you're reading an older payment service agreement and it references "VbV", "Verified by Visa", "MasterCard SecureCode", or "Amex SafeKey", those terms still apply — the underlying protocol just runs on the new spec now.

3D Secure 2 fixed most of the problems

The replacement protocol, 3D Secure 2, is what runs under the Visa Secure brand today. Instead of demanding a password from every customer, 3DS2 sends 100-plus data points to the issuing bank — device, location, transaction history, behavioural signals — and lets the bank's risk engine decide. If the data looks normal, the bank approves the payment frictionlessly and the customer never sees a challenge. If something's off, the bank steps up to a challenge, usually via the banking app rather than a separate webpage. Well-tuned merchants run 90%+ of their 3DS2 volume through the frictionless flow.

You'll still see the words "Verified by Visa" on plenty of legacy contracts and merchant statements. The protocol underneath is the modern one — branding catches up slowly.

How a 3DS2 authentication actually flows

Here's what happens in the seconds after a customer clicks "Pay" on a Visa-branded card. The merchant's payment page hands the card data to its payment provider. The provider sends an authentication request — bundled with browser fingerprint, IP, billing/shipping address, device language, screen size, and dozens of other data points — to Visa's directory server. Visa's directory looks up the issuing bank's access control server (ACS) and forwards the request. The bank's risk engine scores the transaction in milliseconds.

If the score clears the bank's frictionless threshold, the ACS returns an authentication response that says "approved without challenge" and includes a cryptographic value called a CAVV (Cardholder Authentication Verification Value). The merchant's processor passes that CAVV through to the acquirer in the authorisation message, and the issuer approves the auth as a fully-authenticated transaction. The customer sees the order confirmation page and never knew anything special happened.

If the bank wants more proof, the ACS returns a challenge URL. The customer is redirected into a flow that's typically a push notification to their banking app — "Did you just try to pay £127.50 at MerchantName?" — with an Approve/Deny button. They tap Approve, the ACS returns the same kind of authenticated response with a CAVV, and the auth completes. If the customer declines or doesn't respond inside the timeout (usually 4-10 minutes), the auth fails and the merchant can either retry without 3DS (losing liability shift) or treat the order as abandoned.

Liability shift is the reason merchants bother

The commercial draw of VbV/Visa Secure has always been the chargeback liability shift. When a transaction is successfully authenticated, the merchant is protected against "It Wasn't Me" fraud disputes — the issuing bank takes the loss instead. For card-not-present merchants, where chargebacks are an everyday cost line, that protection is worth real money. The catch is that the shift only applies when authentication actually completes, so merchants need to pay attention to authentication rates, not just whether 3DS is switched on.

What liability shift actually covers

The shift only applies to fraud-coded chargebacks — Visa reason codes 10.4 (Other Fraud — Card-Absent Environment) and 10.5 (Visa Fraud Monitoring Program) on the current Visa Claims Resolution framework. It does not cover:

• Goods-not-received disputes (13.1) — if the customer says the parcel never arrived, 3DS doesn't help you
• Goods-not-as-described disputes (13.3) — quality complaints sit with the merchant regardless
• Recurring billing disputes after a cancellation (13.2) — the customer authorised the original transaction, not the next ten
• Credit not processed (13.6) — refund management is a merchant operations problem
• Authorisation-related disputes (11.x) — those need a different fix

Roughly a third of card-not-present chargebacks across UK merchants are fraud-coded, so the shift is meaningful but not a complete fraud-loss insurance policy. Merchants who treat 3DS as the only fraud control they need usually discover that the other two-thirds of disputes still hurt.

The frictionless rate matters more than the on/off switch

"We've turned on 3DS" is the wrong success metric. The right one is the share of attempts that get a CAVV back — the authentication rate — and the share that complete without a challenge — the frictionless rate. A merchant who's running 3DS but seeing 25% of customers abandon at the challenge step is paying a heavy conversion tax for the liability shift. A merchant whose payment provider isn't sending enough data fields in the authentication request will get more challenges than necessary, because the bank's risk engine has less to work with. Tuning that data quality — particularly browser fingerprint, cardholder address, prior purchase history with the merchant — is where the conversion gains live.

PSD2 SCA made it effectively mandatory in Europe

From January 2021, the second Payment Services Directive's Strong Customer Authentication rules required two-factor authentication on most online card payments over £30 across the UK and EEA. 3D Secure 2 is the mechanism the card industry uses to deliver that — so for any European merchant taking online card payments above the threshold, running Visa Secure (and Mastercard Identity Check, and SafeKey) isn't really optional anymore. There are exemptions for low-value transactions, recurring payments, trusted beneficiaries and merchants with low fraud rates, but the default is authenticated.

The exemptions worth knowing about

The SCA framework includes a handful of exemptions a merchant can flag in the 3DS request. The bank still gets the final call, but a flagged exemption raises the chance of a frictionless approval:

• Low-value transactions: payments under €30 (£25 in the UK) can skip SCA, but only five times per card before SCA kicks in
• Transaction Risk Analysis (TRA): merchants whose 90-day fraud rate sits below the regulatory threshold can flag low-risk transactions for exemption — €100 threshold needs fraud below 0.13%, €250 needs below 0.06%, €500 needs below 0.01%
• Trusted Beneficiaries: customers can whitelist a merchant with their bank after the first authenticated payment, so subsequent payments skip the challenge
• Recurring transactions: the first payment in a series needs SCA; subsequent identical-amount payments don't
• Merchant-Initiated Transactions (MIT): stored credentials used for things the cardholder isn't actively driving — subscription renewals, automatic top-ups — are out of scope
• Mail Order / Telephone Order (MOTO): phone payments are categorised as MOTO and are out of scope for SCA entirely

None of these are free of trade-offs. Claiming TRA exemption means you keep the conversion gain but lose the liability shift on that specific transaction. Trusted Beneficiary status helps regulars but does nothing for first-time customers. The arithmetic only makes sense if you measure the conversion lift against the chargeback exposure for each exemption type.

Where VbV doesn't apply: phone payments

3D Secure is designed for online checkouts. Phone payments are MOTO transactions and they're carved out of the SCA mandate — there's no practical way to authenticate a customer through 3DS while they're on a voice call. That carve-out is useful for merchants taking MOTO payments, but it has a downside: no 3DS authentication means no liability shift. If a phone payment turns out to be fraud, the merchant pays. That's why phone-payment fraud controls — AVS, CVV checks, agent training, velocity rules — matter so much, and why fraudsters increasingly target the phone channel when online checkouts are well-protected.

The displacement effect we see in practice

When online fraud gets harder, fraudsters move to the next-weakest channel. Across our customer base in 2024-2026, we've watched a steady drift of card-testing and account-takeover fraud into voice channels: someone with a stolen card calls the merchant directly, claims their online checkout isn't working, and dictates the card details over the phone. Without 3DS protection, the merchant's authorisation system happily approves the charge if AVS and CVV match — and the genuine cardholder raises a chargeback two weeks later.

The defences that hold up on the phone aren't the same as the ones that work online. Agent training on social-engineering red flags, callback verification on high-value orders, velocity rules on attempts from the same number, and — where the payment volume justifies it — taking the agent out of the audio path entirely so the cardholder enters the card themselves via DTMF. That last control, which removes the agent from the position of being able to capture (or misuse) card data, is what Paytia's agent-assisted payment flow exists for.

3DS2 versions and what's current in 2026

The 3DS2 protocol has been through several minor revisions since EMVCo published the original specification in 2016. Each version added data fields, tightened message formats, or improved the experience on a new channel. In 2026, the relevant versions are:

• 3DS 2.1: the original 3DS2 release, still supported by most issuers but being phased out. Lacks decoupled authentication and several mobile-first data fields.
• 3DS 2.2: the workhorse version through 2022-2025. Added exemption flags for the SCA framework, decoupled authentication (allowing challenges to complete outside the merchant session), and merchant-initiated transaction support.
• 3DS 2.3: the current target. Adds proper support for digital wallets, split-shipment handling, better mobile SDK flows, and an "out-of-band" authentication path for in-app purchases. Adoption across European issuers is uneven — some are on 2.3 today, plenty are still on 2.2.

The 3DS 1.0 protocol — the original VbV password-based flow — was retired by Visa for new merchants in October 2022 and shut down completely on most issuing banks during 2023. If a payment provider is still listing "3DS 1.0 fallback" as a feature in 2026, that's largely marketing — the issuers it was designed to talk to no longer respond.

Authentication outcomes you'll see in reports

3DS reports come back with an ECI (Electronic Commerce Indicator) and a status code that tell you what actually happened. The values that matter:

• ECI 05 (Visa) / ECI 02 (Mastercard): fully authenticated, liability shift applies. This is what you want.
• ECI 06 (Visa) / ECI 01 (Mastercard): attempted authentication, issuer didn't support 3DS or didn't respond. Liability shift still applies for most chargebacks.
• ECI 07 (Visa) / ECI 00 (Mastercard): no authentication. Full merchant liability.
• Status Y: authenticated successfully
• Status A: attempted, treated as authenticated for liability purposes
• Status N: not authenticated — customer failed the challenge or it didn't complete
• Status U: unable to authenticate — system issue, ACS unavailable
• Status R: rejected — the issuer specifically refused authentication, which is a strong fraud signal worth blocking on

Merchants who pull these codes into their fraud dashboards spot issues faster. A spike in Status N usually means the customer experience broke at the challenge step; a spike in Status R means cards in your traffic are being explicitly rejected by their issuers and you've probably got a card-testing attack in progress.

Common failure modes

The challenge UI breaks on mobile

Some bank ACS pages still render badly on small screens — buttons cut off, password fields requiring zoom, push notifications not arriving. Customers abandon at the challenge step. Merchants can't fix the bank's UI, but they can choose a payment provider whose mobile SDK handles the challenge in a native bottom sheet rather than a webview redirect, which closes the gap considerably.

The customer's card is set up for SMS challenges and they don't have signal

If the customer's issuer falls back to SMS OTP and they're on a train, in a basement, or roaming on a flaky network, the code never arrives and the auth times out. Best you can do is set the timeout long enough to give a slow message a chance, and present clear retry guidance when it fails.

The merchant doesn't send enough data

3DS2's frictionless rate depends on the bank having a rich risk picture. A payment provider that only forwards the bare minimum (card number, amount, currency) will get more challenges than one that sends the full browser fingerprint, address data, account age, and prior-purchase history. Check what your provider is actually sending — the difference between a 60% and a 90% frictionless rate is mostly in the data fields.

Recurring payments trigger SCA when they shouldn't

A subscription renewal flagged incorrectly as a customer-initiated transaction will get challenged, and the customer isn't in the checkout to respond, so it fails. The fix is correct MIT flagging and a stored credential reference from the first authenticated payment. Get this wrong and you lose subscribers silently.

The merchant's BIN-routing logic gets confused

Some merchants try to skip 3DS for cards issued outside SCA jurisdiction (US cards, for example, where there's no equivalent mandate). The routing rules sometimes misfire and skip 3DS for European cards too. Issuers then decline those auths under the SCA regulation, and the merchant blames "weird issuer behaviour" rather than their own routing.

Versus other authentication methods

Compared with the alternatives, 3DS2 sits in a particular place. Network tokenisation reduces the value of a stolen card to a fraudster, but doesn't authenticate the person presenting it. Address Verification Service catches some bad orders but is trivial to defeat once the fraudster knows the billing address. CVV checks stop a class of attack but don't prove identity. Behavioural analytics catches patterns at the merchant tier but doesn't shift liability. 3DS2 is the only mainstream method that combines an identity signal, a regulator-recognised SCA outcome, and a chargeback liability shift in one mechanism — which is why most CNP merchants run it even where SCA isn't mandated.

It's not free of cost. Even in the best implementations, somewhere around 5-10% of authentication attempts add visible friction the customer didn't have before. The right framing is that 3DS2 is a tool whose conversion drag should be tuned (through exemption claims, data quality, and a good challenge UI) until the chargeback-saving and SCA-compliance benefits clearly outweigh the lost sales. Most merchants aren't anywhere near that tuned.

recommended approaches for getting it right

• Measure both authentication rate and frictionless rate. If either is sliding, you've got a problem that won't show up on the chargeback report for 60-90 days.
• Send the maximum data your provider supports. Browser fingerprint, full address, account age, prior order count — every field raises the chance of frictionless approval.
• Use the right ECI/status codes in your fraud rules. A Status R cardholder is being explicitly rejected by their bank. Treat that as a strong signal.
• Don't claim exemptions you can't defend. TRA exemption against a fraud rate you're not actually measuring will catch up with you when the issuer reviews.
• Build a parallel set of controls for phone payments. AVS, CVV checks, agent training, callback verification, and where the volume justifies it, a PCI-compliant DTMF capture flow that takes the agent out of the card-data path.
• Watch for protocol churn. 3DS 2.3 is rolling out unevenly. Your provider's roadmap matters.
• Read your chargeback codes. If 3DS-authenticated transactions are still hitting fraud chargebacks, the issuer may be claiming a CAVV mismatch — that's a processor or routing issue, not a 3DS one.

What about consumer-facing experience?

From the customer side in 2026, the experience is invisible most of the time. Pay online with a Visa card and the bank's risk engine quietly approves the transaction in the background. About one transaction in ten you'll get a push notification from your banking app asking you to confirm — tap the green button and the order completes. SMS codes still exist as a fallback for customers whose banks haven't adopted app-based authentication, but they're less common than they were three years ago. The static-password "Verified by Visa" screen of 2010 is gone for almost everyone, even though plenty of customers still call any 3DS challenge "the Verified by Visa thing".

Where this fits in Paytia's product

For our customers, 3D Secure / Visa Secure handles the online side. Paytia's job starts where 3DS stops — at the phone. We give merchants a way to take card payments over a voice call without the agent seeing or hearing the card data: the customer types the card number on their phone keypad, our system masks the DTMF tones from the agent, and the card data goes directly to the merchant's PCI-compliant payment processor. There's no 3DS authentication on a phone payment, but with the agent removed from the card-data path, the most common phone-payment fraud vectors — agent fraud, written-down card numbers, recorded card details in call recordings — are closed off. Online and phone together cover both channels: 3DS on the website, Paytia on the phone, fraudsters with nowhere obvious to displace to.

Frequently asked questions

Is Verified by Visa still active in 2026?

The brand is retired — Visa renamed it to Visa Secure in 2019 — but the underlying protocol is more active than ever, running as 3D Secure 2 on most online card payments. You'll still see "VbV" on plenty of old contracts and merchant statements.

What's the difference between Verified by Visa and Visa Secure?

The name. Visa Secure is the current consumer-facing brand for Visa's 3D Secure implementation. The 2001-2019 brand was Verified by Visa, originally tied to the static-password 3DS 1.0 protocol. The modern Visa Secure brand applies to 3DS 2.x flows.

Does Verified by Visa apply to phone payments?

No. 3D Secure is designed for online checkouts. Phone payments are MOTO transactions and the SCA regulation explicitly carves them out. The trade-off is that without 3DS authentication, the merchant carries full liability on phone payments — which is why phone-payment fraud controls have to be tighter.

Will turning on 3D Secure / Visa Secure hurt my conversion rate?

It can, but a well-tuned 3DS2 setup with high data quality and the right exemption flagging usually runs 90%+ frictionless, so most customers never see a challenge. The remaining 10% who do see one will have some drop-off. The right comparison is conversion drag against chargeback savings plus the value of SCA compliance.

What does the liability shift actually protect me from?

Successfully authenticated 3DS transactions shift the chargeback liability on fraud-coded disputes (Visa reason codes 10.4 and 10.5) from the merchant to the issuing bank. It doesn't cover non-fraud disputes — goods not received, not as described, recurring billing complaints, refund disputes. Roughly a third of CNP chargebacks are fraud-coded.

Do US merchants need to run Visa Secure?

It's not mandated in the US the way SCA mandates it in Europe, but most US CNP merchants run it for the chargeback liability shift. The economics still work even without regulatory pressure.

Why does the customer sometimes get a challenge and sometimes not?

The issuing bank's risk engine decides on every transaction. Familiar device, familiar IP, familiar purchase pattern, normal amount — frictionless approval. Unusual device, new shipping address, sudden spike in spend, payment from an unfamiliar geography — challenge. Merchants can influence this by sending richer data, but they can't override the bank's final call.

What happens if 3DS fails — does the payment go through?

It depends on how the merchant has configured fallback. Most providers let you choose: hard-fail (reject the auth if 3DS doesn't complete successfully), soft-fail (attempt the auth without 3DS, accepting full liability), or retry without 3DS for specific failure codes. The right answer depends on the merchant's fraud appetite and conversion sensitivity.

Is 3DS 2.3 available everywhere?

Not yet. Adoption across European issuers in 2026 is uneven. Most are on 2.2 with 2.3 rolling out. Most merchant payment providers support both and negotiate the highest mutually-supported version at runtime, so this is rarely something a merchant has to actively manage.

If Verified by Visa is just for Visa, what about other cards?

Each network has its own brand for the same protocol: Mastercard Identity Check (formerly SecureCode), American Express SafeKey, Discover ProtectBuy, JCB J/Secure. They all run on 3D Secure 2 today and behave essentially identically from the merchant's side. The differences are in branding and a handful of edge cases around exemption rules and reason-code mapping.