Visa Secure using EMV® 3DS User Experience Guidelines

Last updated on May 17, 2021

Introduction

Welcome to the UX product guidelines for Visa Secure using EMV 3DS flows on web browsers and mobile apps. Whether you’re a designer, developer, product manager, or business decision-maker, these guidelines will help you create the best experience for your customers.

Visa Secure (previously known as Verified by Visa) is Visa’s program that governs Visa transactions using the 3-D Secure standard. The program provides the rules and policies merchants and issuers must follow to invoke authentication for eCommerce transactions, enabling verification of the cardholder’s identity before the transaction is sent for authorization.

Depending on the authentication solution the Issuer chooses, there are many authentication methods available for an Issuer to use. Visa recommends that issuers use risk-based authentication as their authentication approach, when appropriate—recognizing that in some cases regulatory requirements may have specific “step-up” or challenge authentication requirements. Please reference regulatory requirements for specific challenge requirements.

Challenge anatomy

The layout of every challenge follows a natural hierarchy. A consistent hierarchy leads to a better customer experience.

Zoom

UI Components

Zoom

UI Requirements

Element	Requirement
Header Zone	Contains all labels managed by the 3DS Requestor and is located at the top of the screen. Note: The Browser UI does not include a header zone.
Branding Zone	There must be no competitive branding including but not limited to MasterCard Identity Check, American Express SafeKey, and JCB’s J/Secure. Issuer Name/Logo The Issuer’s logo must be displayed on an authentication page and must appear in the upper left corner. Only the logo of the issuer is allowed. Logos of other issuer services are not allowed Third-party names or logos are not permitted Visa Logo The Visa logo must be displayed on an authentication page must appear in the upper right corner. The Visa logo can be obtained from Visa Product Brand Standards https://www.productbrandstandards.com/account/login?ReturnUrl=%2F.
Challenge Zone	Contains processing and challenge information and is located between the Branding zone and the Information zone. No hover/visited state (applies to Mobile view only) No motion/animation design or sound
Information Zone	Contains additional information for the cardholder and is located at the bottom of the screen.
Page Background	The background requirement for any 3DS user interface page will vary depending on the type of user interface. For Native Interfaces A white background must be used to maintain consistency, and to avoid color-clashes between issuer and merchant color schemes For Browser/HTML interfaces A white background must be used to maintain consistency, and to avoid color-clashes between issuer and merchant color schemes The Issuer may use its color scheme that their consumers are familiar with and associate with the Issuer.
No External Links	There must be no external links or advertising, no links to other sites, and no advertising or other communications messages.

Responsive design

Merchants expect Visa Secure to be adaptive to all screen sizes (e.g., phone, tablet, and desktop devices).

Zoom

Screen Size and Resolution

Visa Secure challenge screens should adapt to the resolution of the device that they are being displayed on.

Visa Secure screens can have the following sizes:

250 x 400
390 x 400
500 x 600
600 x 400
Full Screen

Visa Secure screen layouts should be adaptive to all screen sizes. Issuers should check the screen size data element in the authentication request message to ensure that the screen size they display to users is appropriate.

If an issuer does not have a challenge screen size that matches the user’s screen size, it is recommended that the issuer presents a screen size smaller than the user’s screen size. A 250x400 screen can be displayed across all screen sizes, whereas the same is not true for the larger screen sizes.

Screen contents should be front loaded while following the Visa Secure visual hierarchy so that the challenge information header and challenge information text are clearly visible to the user. Users should be able to quickly understand why they are being asked to authenticate and how to do so.

Fonts

Open Sans should be used as the primary font where supported (e.g. Latin, Greek, and Cyrillic). Noto should be used for all languages not covered by Open Sans (e.g. Chinese, Japanese, Korean, Southeast Asian and Middle Eastern languages). Open Sans Regular or Open Sans Semibold can be used for emphasis or to build hierarchy in communications.

Definitions

Term	Definition
3-D Secure (3DS)	An e-commerce authentication protocol that enables the secure processing of payment, non-payment and account confirmation card transactions. For more information regarding 3-D Secure, refer to the EMVCo website [https://www.emvco.com/emv-technologies/3d-secure/]
Abandoned Authentication	An authentication that is not completed. An authentication may not be completed due to cardholder cancellation, inactivity timeout or issuer/merchant malfunction.
Access Control Server (ACS)	A component that operates in the Issuer Domain, that verifies whether authentication is available for a card number and device type, and authenticates specific Cardholders.
Access Control Server User Interface (ACS UI)	The ACS UI is generated during a Cardholder challenge and is rendered by the ACS within a Browser challenge window.
Authentication	In the context of 3-D Secure, the process of confirming that the person making an e-commerce transaction is entitled to use the payment card.
Authorization	A process by which an Issuer, or a processor on the Issuer's behalf, approves a transaction for payment.
Browser	In the context of 3-D Secure, the browser is a conduit to transport messages between the 3DS Server (in the Acquirer Domain) and the ACS (in the Issuer Domain).

Layout

In this section, we explore how merchants could implement Visa Secure guidelines based on our layout recommendations and guidelines for merchants. Choices will vary based on technical capabilities and existing platforms.

Modal view example

Zoom

Merchants should implement a modal view for the authentication screen that sits above their checkout page. For mobile devices, we advise the usage of full width and full height modal views.

The modal view is the preferred authentication challenge implementation for browsers as it effectively focuses users on the authentication challenge with minimal distractions.

Processing Screen (Frictionless-Risk-based Authentication)

A Frictionless Flow occurs when the Issuer authenticates the cardholder without cardholder involvement by evaluating the transaction’s risk level. The Merchant sends an authentication request message to the Issuer with all the required data to facilitate risk-based authentication. The Issuer evaluates the transaction and responds with either no additional verification requested or a challenge request. If a challenge request is received, one of the below challenge methods can be used.

During the message exchanges, a screen should be displayed to the cardholder to indicate that 3-D Secure processing is occurring.

Processing Screen – Browser

Zoom

Processing screen must include a spinning wheel and the Visa logo underneath

Processing Screen – Mobile

Zoom

Processing screen must include a spinning wheel and the Visa logo underneath

Payment Flows

This section contains descriptions for Visa Secure challenge methods for payment authentications, which includes both the browser and native version of the flow.

Overview

When customers are asked to verify transactions, they are presented with a challenge flow. The challenge method that's used is determined by the issuer. To ensure a smooth customer experience, issuers and ACS providers are required to display explanatory text on challenge screens.

One-time passcode (OTP)

Customers verify transactions using a secure code sent by text or email. Issuers can choose which delivery channels to make available for the customer. We recommend providing both to the customer.

Zoom

Specifications - OTP / Email (Mobile)

Zoom

Specifications - OTP / SMS (Mobile)

Zoom

SMS/Email Requirements – Mobile (In-App)

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Choice Screen	The page must display the headline Keep Your Account Safe above the Challenge Info text for OTP Choice Screen.
2	Challenge Information Text OTP Choice Screen	We’re almost done. To product your purchase, we’re sending you a verification from (Issuer Name). Where would you like it sent? Radio Button: My email <<masked email>> Radio Button: My mobile <<masked phone number>>
3	Challenge Information Header OTP Code Entry	The page must display the headline Verify by phone above the Challenge Info text.
4	Challenge Information Text OTP Code Entry	This text must include the following language: *OTP by SMS:* We just sent you a verification code to your registered mobile number <<masked phone number>>. You are authorizing a payment to (merchantName) {purchaseCurrency} (purchase amount). *OTP by Email:* We just sent you a verification code to your registered email address <<masked email address>>. You are authorizing a payment to (merchantName) {purchaseCurrency} (purchase amount). The merchant name, purchase currency, & purchases amount as included in the AReq message.
5	Challenge Information Label	The display name for this field must be ‘Verification Code’.
6	Challenge Information Data Entry	Input Box
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
8	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
9	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
10	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Specifications - Browser

Zoom

SMS/Email Requirements – Browser

#	Zone	Element	Content/Requirement
1	Challenge	OTP Choice Screen	The page must display the headline Keep Your Account Safe above the OTP Choice Information. We’re almost done. To product your purchase, we’re sending you a verification from (Issuer Name). Where would you like it sent? Radio Button: My email <<masked email>> Radio Button: My mobile <<masked phone number>>
2	Challenge	OTP Code Entry Screen	The page must display the headline Verify by phone above the Challenge Info text. This text must include the following language: *OTP by SMS:* We just sent you a verification code to your registered mobile number <<masked phone number>>. You are authorizing a payment to (merchantName) {purchaseCurrency} (purchase amount). *OTP by Email:* We just sent you a verification code to your registered email address <<masked email address>>. You are authorizing a payment to (merchantName) {purchaseCurrency} (purchase amount). The merchant name, purchase currency, & purchases amount as included in the AReq message.
3	Challenge	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box.
4	Challenge	Submit Authentication Field	A form element that should align with the center of the bottom margin displaying “Confirm”.
5	Challenge	Resend Information Field	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
6	Information	Need Help Field	The display name for this field must be ‘Need Help?’. Display the “Need Help?’ Label as a graphical control element that can be expanded. Display the Need Help Text only when the user selects the Need Help Label. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.
7	N/A	Authentication Successful	Challenge window closes and cardholder is brought to Successful Purchase Page. *Please see below for Incorrect Authentication Attempts

Zoom

Verification Code Incorrect Specifications Requirements - Browser

Zoom

Verification Code Incorrect Requirements

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder inputs verification code incorrect then follow below for incorrect input:

Verification Code Left Blank Specifications - Browser

Zoom

Verification Code Left Blank Requirements - Browser

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder does not input a verification code and clicks confirm, then follow below:

#	Element	Content/Requirement
1	Verification Code Left Blank Error Message	The page must display the headline Please fill out the required field. Above the Passcode Entry Field.
2	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box. The display name below the input box must be ‘Please enter a valid code’
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
4	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
5	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).

Incorrect Number of Digits Entered - Browser

Zoom

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder inputs the incorrect number of digits, then follow below:

#	Element	Content/Requirement
1	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box. The display name below the input box must be ‘Please enter all X digits’ include the total number of digits.
2	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
3	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
4	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).

Max Number of Attempts Specifications - Browser

Zoom

Max Number of Attempts Requirements

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder reaches the Max Number of Attempts, then follow below:

#	Element	Content/Requirement
1	Error Message	The page must display the headline This is not the correct code. Please try again. Above the Passcode Entry Field. The max number of attempts should not exceed 6 times.
2	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box. The display name below the input box must be ‘Please enter a valid code’
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
4	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
5	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).
6	Max Number of Attempts Reached	The page must display the headline ‘Get New Verification Code’. Above the Max Number of Attempts language. You’ve reached the maximum number of attempts with your current verification code. To continue, we’ll send you another code to verify your identity. We’ll send you a verification code by text message to <<masked phone number>>. The max number of attempts should not exceed 3 times.
7	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.

Backup Authentication Method (Automated Phone + Biometrics) Specifications - Browser

Zoom

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder choose to send verification code to another security option:

#	Element	Content/Requirement
1	Backup Authentication Method page	Backup Authentication Method page
2	Backup Authentication Methods	Radio Button must be used with the following language. *Automated Phone Call:* Get Security code via phone call to <<masked phone number>> or <<masked phone number>>. *Biometrics:* Receive a push notification from your banking app to use fingerprint or face. *QR Code:* Generate a one-time token that is valid for time of the transaction.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue” one a radio button is chosen.
4	Automated Phone Call	The page must display the headline Select a phone number by phone above the Challenge Info text. Radio Button: My mobile <<masked phone number>> Radio Button: My landline <<masked phone number>>
5	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box.
6	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
7	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).
8	Need Help Label	The display name for this field must be ‘Need Help?’. Display the “Need Help?’ Label as a graphical control element that can be expanded.
9	Need Help Text	Display the Need Help Text only when the user selects the Need Help Label. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Backup Authentication Method (Biometric) - Browser

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder choose to send verification code to another security option:

#	Element	Code/Requirement
1	Backup Authentication Method page	The page must display the headline ‘Select Your Security Option’ above the Backup Authentication Method Choice.
2	Backup Authentication Methods	Radio Button must be used for backup methods. Not all options need to be supported, if these options are used the following language must be used. *Automated Phone Call:* Get Security code via phone call to <<masked phone number>> or <<masked phone number>>. *Biometrics:* Receive a push notification from your banking app to use fingerprint or face. *QR Code:* Generate a one-time token that is valid for time of the transaction.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue” one a radio button is chosen.
4	Biometrics	The page must display the headline Please approve this through your {Issuer Name} app then return to this page. A graphic with biometrics app can be shown with no animation or sound.
5	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
6	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).
7	Need Help Label	The display name for this field must be ‘Need Help?’. Display the “Need Help?’ Label as a graphical control element that can be expanded.
8	Need Help Text	Display the Need Help Text only when the user selects the Need Help Label. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.
9	Return to Checkout Page	Once consumer successfully completes biometric authentication and returns to checkout page, a successful purchase screen must be displayed.

Zoom

Backup Authentication Method (QR Code) - Browser

Zoom

The One-time Passcode SMS/Email Browser Requirements are displayed until cardholder choose to send verification code to another security option:

#	Element	Content/Requirement
1	Backup Authentication Method page	The page must display the headline ‘Select Your Security Option’ above the Backup Authentication Method Choice.
2	Backup Authentication Methods	Radio Button must be used for backup methods. Not all options need to be supported, if these options are used the following language must be used. *Automated Phone Call:* Get Security code via phone call to <<masked phone number>> or <<masked phone number>>. *Biometrics:* Receive a push notification from your banking app to use fingerprint or face. *QR Code:* Generate a one-time token that is valid for time of the transaction.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue” one a radio button is chosen.
4	QR Code	The page must display the headline Scan QR Code above QR Code. Please scan the QR code using your {Issuer Name} app on your mobile phone and follow the instructions. Show QR Code to scan.
5	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
6	Passcode Entry Field	The display name for this field must be ‘Verification Code’ above an Input Box.
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
8	Use Another Authentication Method	The display name for this field must be ‘Having Trouble?’. Display “Choose Another Security Option’ Label. A new screen must be displayed if this option is clicked on with another authentication method option (See Backup Authentication Method Section).
9	Need Help Label	The display name for this field must be ‘Need Help?’. Display the “Need Help?’ Label as a graphical control element that can be expanded.
10	Need Help Text	Display the Need Help Text only when the user selects the Need Help Label. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task

Out of Band authentication (OOB)

In-app native challenges are built with 3DS SDK templates for a streamlined experience that matches the merchant’s native user interface. The guidelines in this section account for the technical specifications of the 3DS SDK, which are slightly different to the technical specifications of the HTML user experience.

Picture of OOB in-app native flow – full flow

Zoom

HTML based challenges allow for greater issuer flexibility in designing the challenge experience. We have included three sections in our guidelines to specifically address the UX of HTML challenges for in-app, mobile browser and desktop browser experiences. HTML based challenges allow issuers to:

Use rich text for the challenge instruction screens
Allow users to choose a backup authentication method should they not be able to complete OOB authentication

Picture of OOB in-app HTML flow – full flow

Zoom

In both experiences, it is highly recommended that issuers send users a push notification to their OOB authentication service upon showing users the OOB challenge information text. This has been shown to improve the user experience by giving users a direct route to their issuer’s OOB authentication service, as opposed to manually navigating to it.

OOB Requirements – Mobile in-app native

Mobile in-app native specifications with redline markup

Zoom

#	Element	Code/Requirement
1	Challenge Info Header	The page must display the headline Let’s Make Sure it’s You above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: Before placing your order, you must verify payment to [Merchant] for [Amount]. Step 1 - Open the [Issuer] app on your mobile device to verify. Step 2 - Return to this page and tap complete to finish placing your order.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
5	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

OOB Requirements – Mobile in-app HTML

Specifications - Mobile in-app HTML

Mobile in-app HTML redline specifications markup - challenge screen

Zoom

Mobile in-app HTML redline specifications markup - success message

Zoom

#	Element	Code/Requirement
1	Challenge Info Header	The page must display the headline Let’s make sure it’s you above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: Before placing your order, you must verify payment to [Merchant] for [Amount]. Open the [Issuer] app on your mobile device to verify. Return to this page and tap complete to finish placing your order. The usage of rich text numbered lists is recommended so that users can clearly understand the authentication steps.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Backup Authentication Method Text	This text must include the following language: Having Trouble?
5	Backup Authentication Method Label	A form element that should align with the left side of the bottom margin displaying “Choose another security option”.
6	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
7	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

OOB Requirements – Mobile Browser HTML

Zoom

Specifications – Mobile Browser HTML

Mobile Browser - HTML redline specifications markup

Zoom

#	Element	Code/Requirement
1	Challenge Info Header	The page must display the headline Let’s make sure it’s you above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: Before placing your order, you must verify payment to [Merchant] for [Amount]. Open the [Issuer] app on your mobile device to verify. Return to this page and tap complete to finish placing your order. The usage of rich text numbered lists is recommended so that users can clearly understand the authentication steps.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Backup Authentication Method Text	This text must include the following language: Having Trouble?
5	Backup Authentication Method Label	A form element that should align with the left side of the bottom margin displaying “Choose another security option”.
6	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
7	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

OOB Requirements – Desktop Browser HTML

OOB Desktop Browser HTML full flow diagram

Zoom

Specifications – Desktop Browser HTML

OOB HTML Desktop Browser redline specifications markup - challenge screen

Zoom

OOB HTML Desktop Browser redline specifications markup - success

Zoom

#	Element	Code/Requirement
1	Challenge Info Header	The page must display the headline Let’s make sure it’s you above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: Before placing your order, you must verify payment to [Merchant] for [Amount]. Open the [Issuer] app on your mobile device to verify. Return to this page and tap complete to finish placing your order. The usage of rich text numbered lists is recommended so that users can clearly understand the authentication steps.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Backup Authentication Method Text	This text must include the following language: Having Trouble?
5	Backup Authentication Method Label	A form element that should align with the left side of the bottom margin displaying “Choose another security option”.
6	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
7	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Premature Completion Requirements

In each of the device channels shown above, it is possible for users to click the “Complete” button prior to OOB authentication taking place. In the event that users click the “Complete” button prior to OOB authentication, it is recommended that issuers display a premature completion screen that adheres to the following guidelines so that users understand that they need to authenticate in their issuer’s OOB authentication service.

Zoom

Zoom

#	Element	Code/Requirement
1	Need Help Info Header	The page must display the headline Oops! Did you click “Complete” before going to your Digital Bank app first? above the Need Help Info text.
2	Need Help Info Text	This text must include the following language: Step 1 - Open the [Issuer] app on your mobile device to verify. Step 2 - Return to this page and tap complete to finish placing your order.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
5	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Backup Authentication Method Requirements – Mobile or Desktop HTML

HTML challenges give issuers the option to give users a backup authentication method choice, should OOB authentication not be feasible. To select a backup authentication method, users click on “Choose another security option” in the OOB HTML challenge screen and are presented with backup security options, should the issuer offer them.

Backup authentication method - Mobile - redline specifications markup

Zoom

Backup authentication method - Desktop - redline specifications markup

Zoom

Note: For European issuers complying to PSD2 SCA, one-time passcodes may not be sent to the user’s email address.

#	Element	Code/Requirement
1	Need Help Info Header	The page must display the headline Choose another security option above the Need Help Info text.
2	Need Help Info Text	This text must include the following language: (header in box) Get security code sent to [radiobtn] [email protected] [radiobtn] (123) xxx-xx12
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
4	Backup Authentication Method Cancellation Label	A form element that should align with the left side of the bottom margin displaying “I changed my mind. Go back.” This label routes user back to the OOB Challenge Info Screen

Knowledge-based authentication (KBA)

Customers verify transactions by answering knowledge-based questions. Issuers can choose which methods to make available for customers.

Zoom

Specifications - KBA (Mobile)

Zoom

Knowledge Based Requirements – Mobile (In-App)

#	Element	Code/Requirement
1	Challenge Info Header Confirmation of Payment prior to Authentication	The page must display the headline Keep your account safe above the Challenge Info text.
2	Challenge Info Text Confirmation of Payment prior to Authentication	This text must include the following language: You're authorizing a payment to (merchantName) for {purchaseCurrency} (purchase amount). Let’s make sure it’s you. Please answer {X} security questions. The merchant name, purchase currency, & purchases amount as included in the AReq message. It is recommended to ask a minimum of 2 security questions.
3	Challenge Info Header Challenge Page	The page must display the headline Verify your purchase above the Challenge Info text.
4	Challenge Info Text	The display name for this field must be {Question 1} and {the actual Question}.
5	Challenge Info Label If not a multiple choice question	The display name for this field must be ‘Your Answer’.
6	Challenge Info Data Entry If not a multiple choice question	Input Box
7	Challenge Info Label For multiple choice question	The display name for this field must be ‘Please select all that apply’.
8	Challenge Info Data Entry For multiple choice question	Multiple Check boxes
9	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”.
10	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
11	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Knowledge Based Specifications – Browser

Zoom

Knowledge Based Requirements – Incorrect Answer - Browser

#	Element	Content/Requirement
1	Error Message	The page must display the headline You have answered one or more question incorrectly. Please try again. Above the Information Entry Field.
2	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
3	Confirmation of Payment prior to Authentication	This text must include the following language: You're authorizing a payment to (merchantName) for {purchaseCurrency} (purchase amount). Let’s make sure it’s you. Please answer {X} security questions. The merchant name, purchase currency, & purchases amount as included in the AReq message. It is recommended to ask a minimum of 2 security questions.
Display # 3-10 above for consumer to try again

Cancel / Close

Zoom

#	Element	Code/Requirement
1	Cancel/Close	The cardholder must be provided with a means of not proceeding with challenge entry. However, if the cardholder selects ‘Cancel or Close’, the issuer must present an alert.
2	Cancel/Close Alert	If the cardholder clicks on the ‘Cancel or Close’, or if the cardholder clicks on the Back button, an alert, must be displayed to inform the cardholder that the transaction will terminate. The page must display the headline Are You Sure? above the Exit text. If you cancel, you will not be able to authorize a payment to (merchantName) {purchaseCurrency} (purchase amount). This means you will not be able to purchase the item in your basket.
3	Return to Authentication page	A form element that should align with the center of the margin displaying “I Changed My Mind”.
4	Complete Cancel/Close	The display name for this field must be ‘Yes, I want to Cancel’. If the cardholder clicks OK, the ACS must return a failed authentication response to the participating merchant to prevent fraudulent users from avoiding authentication. This alert should appear to advise the cardholder that continuing with the cancellation terminates the purchase with the participating merchant.

Static Password Authentication

To improve the user experience and cardholder security, Visa recommends that issuers use risk-based or dynamic cardholder authentication methods. Static passwords can lead to high authentication challenge abandonment rates, as users may not always have their issuer static passcodes readily available for authentication.

Additionally, as of October 2018, Visa has eliminated the use of Visa Secure-specific static passwords and related enrollment processes.

Previous Releases

Click here to download the UI Guidelines with Visa Secure using 3DS 1.0 PDF.

Design Best Practices

A set of UX principles

In our world of UX, we live by three main principles, which are below. The overall effect is a quick and easy-to-follow flow for customers.

Keep it clear
Think human, not robotic
Be trustworthy

Accessibility

According to the Web Accessibility Initiative, the percentage of people with disabilities in many populations is between 10% and 20%; an estimated 285 million people have a form of visual impairment; and 10-15% of the world's population has dyslexia. We recommend that designers refer to international standards according to the AA-level Web Content Accessibility Guidelines 2.0. We've collected a quick list of suggestions for different areas.

The 3DS UX guidelines presented on this website are ADA compliant. It is recommended for issuers to follow these UX guidelines so that their 3DS screens can be accessible to all users.

For full accessibility guidelines, visit wcag.org.

UI Resources

Visa 3DS_UIAssets_Mobile_Browser.sketch

Additional Use Cases

Visa Secure supports features that enhance authentication functionality and user experience beyond the payment flows. This section covers token identity and verification (ID&V) and trusted beneficiary status with Visa Secure.

Cardholder Verification as part of EMV token ID&V

Issuers can perform identification and verification (ID&V) of their accountholders using EMV® 3-D Secure (3DS) for Visa Token Service (VTS) use cases such as token provisioning or Cloud Token Framework (CTF) device binding and cardholder authentications. The EMV 3DS 2.1 and 2.2 specifications define a non-payment message category and authentication indicator specifically for EMV® token ID&V.

ID&V authentication requests have the following fields set as:

3DS Requestor Authentication Indicator = 06 (Cardholder verification as part of EMV token ID&V)

It is recommended for issuers to present users authentication challenge flows specific to ID&V for ID&V authentication requests. Below are issuer EMV® 3DS ID&V challenge flow guidelines according to challenge method and device channel.

When completing an EMV 3DS 2.3 authentication for a payment, cardholders may have the option to trust list a business they trust to potentially avoid having to authenticate future purchases. These businesses are then included on a “trust list” maintained by the cardholder’s issuer or payment service provider.

To request trusted beneficiary status, a merchant must set the 3DS Requestor Challenge Indicator in the authentication request to 09 (Challenge Requested – Trust List Prompt requested if challenge required). Once a merchant is added to a cardholder’s trust list, the merchant should set 3DS Request Challenge Indicator to 08 (No challenge requested; utilize Trust List exemption if no challenge required).

Issuers receiving trusted beneficiary authentication requests should give their cardholders the option to add the merchant that they are shopping from to their trusted beneficiary list. The following UX guides have been tested so that an issuer can effectively communicate to their cardholder that trusted beneficiary status can be granted to the merchant that they are shopping from.

One-Time Passcode (OTP)

One-Time Passcode (OTP) – Browser

Customers verify transactions using a secure code sent by text or email. Issuers can choose which delivery channels to make available for the customer. We recommend providing both to the customer. Once the customer successfully submits the correct OTP, the issuer ACS closes the challenge window and hands control of the experience back to the 3DS Server.

Zoom

SMS/Email Requirements – Browser

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Choice Screen	The page must display the headline Get Verification Code above the Challenge Info text for OTP Choice Screen.
2	Challenge Information Text OTP Choice Screen	For added security, [Card Issuer] will send you a one-time code. Choose how to receive your code: Radio Button: Text Message <<masked phone number>> Radio Button: Email <<masked email>>
3	Challenge Information Header OTP Code Entry	The page must display the headline Enter verification code above the Challenge Info text.
4	Challenge Information Text OTP Code Entry	This text must include the following language: OTP by SMS: We just sent you a verification by text message to <<masked phone number>>. You have [number of attempts to enter OTP] OTP by Email: We just sent you a verification code by email to <<masked email>>. You have [number of attempts to enter OTP]
5	Challenge Information Label	The display name for this field must be ‘Verification Code’.
6	Challenge Information Data Entry	Input Box
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
8	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
9	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
10	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

One-Time Passcode (OTP) – Mobile in-app native

Customers verify transactions using a secure code sent by text or email. Issuers can choose which delivery channels to make available for the customer. We recommend providing both to the customer.

In-app native experiences leverage the 3DS SDK. Native experiences provide a more merchant-issuer integrated look and feel for users. Native experiences do not leverage rich text.

One Time Passcode (OTP) – Mobile in-app native

Zoom

SMS/Email Requirements – Mobile in-app native

Zoom

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Choice Screen	The page must display the headline Get Verification Code above the Challenge Info text for OTP Choice Screen.
2	Challenge Information Text OTP Choice Screen	For added security, [Card Issuer] will send you a one-time code. Choose how to receive your code: Radio Button: Text Message <<masked phone number>> Radio Button: Email <<masked email>>
3	Challenge Information Header OTP Code Entry	The page must display the headline Enter verification code above the Challenge Info text.
4	Challenge Information Text OTP Code Entry	This text must include the following language: OTP by SMS: We just sent you a verification by text message to <<masked phone number>>. You have [number of attempts to enter OTP] OTP by Email: We just sent you a verification code by email to <<masked email>>. You have [number of attempts to enter OTP]
5	Challenge Information Label	The display name for this field must be ‘Verification Code’.
6	Challenge Information Data Entry	Input Box
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
8	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
9	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
10	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Out of Band (OOB)

Out of Band (OOB) – Mobile Browser

Users verify transactions in their issuer’s authentication service. Issuers can choose which service to make available for user OOB authentication, such as authentication through the issuer’s mobile application. Once authentication via the issuer’s OOB service is complete, users return to the issuer’s 3DS challenge screen and click “Complete” to finish 3DS strong authentication.

It is highly recommended that issuers send users a push notification to their OOB authentication service upon showing users the OOB challenge information text. This has been shown to improve the user experience by giving users a direct route to their issuer’s OOB authentication service, as opposed to manually navigating to it.

Zoom

OOB Requirements – Mobile Browser

Zoom

#	Element	Content/Requirement
1	Challenge Info Header	The page must display the headline Let’s Make Sure it’s you above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: For added security, you will be verified with [Issuer OOB authentication service]. Open the [Issuer OOB authentication service] to verify. Return to this page and tap Complete after you have completed verification with [issuer OOB authentication service]. The usage of rich text numbered lists and boldface fonts is recommended so that users can clearly understand the authentication steps.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
5	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Out of Band (OOB) – Mobile in-app native

In-app native experiences leverage the 3DS SDK. Native experiences provide a more merchant-issuer integrated look and feel for users. Native experiences do not leverage rich text.

Zoom

OOB Requirements - Mobile in-app native

Zoom

#	Element	Content/Requirement
1	Challenge Info Header	The page must display the headline Let’s Make Sure it’s you above the Challenge Info text.
2	Challenge Info Text	This text must include the following language: For added security, you will be verified with [Issuer OOB authentication service]. Open the [Issuer OOB authentication service] to verify. Return to this page and tap Complete after you have completed verification with [issuer OOB authentication service]. The usage of rich text numbered lists and boldface fonts is recommended so that users can clearly understand the authentication steps.
3	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Complete”.
4	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
5	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

One-Time Passcode (OTP) & Knowledge-Based Authentication (KBA)

One-Time Passcode (OTP) & Knowledge-Based Authentication (KBA) – Mobile Browser

If an issuer is interested in performing multi-factor authentication, OTP and KBA challenge methods can be put together in sequential order. Customers perform verification by submitting a secure code sent by text or email and answering two security questions.

Zoom

OTP & KBA Requirements – Mobile Browser

Zoom

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Choice Screen	The page must display the headline Get Verification Code above the Challenge Info text for OTP Choice Screen.
2	Challenge Information Text OTP Choice Screen	For added security, [Card Issuer] will send you a one-time code. Choose how to receive your code: Radio Button: Text Message <<masked phone number>> Radio Button: Email <<masked email>>
3	Challenge Information Header OTP Code Entry	The page must display the headline Enter verification code above the Challenge Info text.
4	Challenge Information Text OTP Code Entry	This text must include the following language: OTP by SMS: We just sent you a verification by text message to <<masked phone number>>. You have [number of attempts to enter OTP] OTP by Email: We just sent you a verification code by email to <<masked email>>. You have [number of attempts to enter OTP]
5	Challenge Information Label	The display name for this field must be ‘Verification Code’.
6	Challenge Information Data Entry	Input Box
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
8	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
9	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
10	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Zoom

#	Elements	Content/Requirement
1	Challenge Info Header Challenge Page	The page must display the headline Answer Security Questions above the Challenge Info text.
2	Challenge Info Text	The display name for this field must be Almost done! Please answer these two security questions. Question 1 of 2 {Question 1} and {the actual Question}.
3	Challenge Info Label If not a multiple choice question	The display name for this field must be ‘Your Answer’.
4	Challenge Info Data Entry If not a multiple choice question	Input Box
5	Challenge Info Label For multiple choice question	The display name for this field must be ‘Please select all that apply’.
6	Challenge Info Data Entry For multiple choice question	Multiple Check boxes
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Submit”.
8	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
9	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

One-Time Passcode (OTP) & Knowledge-Based Authentication (KBA) – Mobile in-app native

In-app native experiences leverage the 3DS SDK. Native experiences provide a more merchant-issuer integrated look and feel for users. Native experiences do not leverage rich text.

Zoom

OTP & KBA Requirements – Mobile in-app native

Zoom

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Choice Screen	The page must display the headline Get Verification Code above the Challenge Info text for OTP Choice Screen.
2	Challenge Information Text OTP Choice Screen	For added security, [Card Issuer] will send you a one-time code. Choose how to receive your code: Radio Button: Text Message <<masked phone number>> Radio Button: Email <<masked email>>
3	Challenge Information Header OTP Code Entry	The page must display the headline Enter verification code above the Challenge Info text.
4	Challenge Information Text OTP Code Entry	This text must include the following language: OTP by SMS: We just sent you a verification by text message to <<masked phone number>>. You have [number of attempts to enter OTP] OTP by Email: We just sent you a verification code by email to <<masked email>>. You have [number of attempts to enter OTP]
5	Challenge Information Label	The display name for this field must be ‘Verification Code’.
6	Challenge Information Data Entry	Input Box
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Continue”.
8	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
9	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
10	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task. The display name for this field must be ‘Need Help?’.

Zoom

#	Element	Content/Requirement
1	Challenge Info Header Challenge Page	The page must display the headline Answer Security Questions above the Challenge Info text.
2	Challenge Information Text	The display name for this field must be Almost done! Please answer these two security questions. Question 1 of 2 {Question 1} and {the actual Question}.
3	Challenge Info Label If not a multiple choice question	The display name for this field must be ‘Your Answer’.
4	Challenge Info Data Entry If not a multiple choice question	Input Box
5	Challenge Info Label For multiple choice question	The display name for this field must be ‘Please select all that apply’.
6	Challenge Info Data Entry For multiple choice question	Multiple Check boxes
7	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Submit”.
8	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
9	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

Trust List

Trusted Beneficiary Flow

During a purchase, the merchant’s EMV 3DS Server provider will send a request through EMV 3DS for the Issuer to allow the cardholder to grant trusted beneficiary status for that merchant. The Issuer’s ACS will display the option to grant trusted beneficiary status to the cardholder. If the cardholder agrees to grant trusted beneficiary status to the merchant, then the cardholder will authenticate for both granting trusted beneficiary status and for the payment. Upon success of the authentication, trusted beneficiary status will be granted to the merchant for the cardholder’s primary account number (PAN).

Once a cardholder has granted trusted beneficiary status to the merchant, future purchases using the same PAN at that merchant may not require strong cardholder authentication. Cardholders should be able to manage which merchants have trusted beneficiary status via their issuer’s online banking services.

Zoom

Zoom

#	Data Elements from EMV 3DS specification	Content/Requirement
1	Challenge Information Header OTP Code Entry	The page must display the headline Enter verification code above the Challenge Info text.
2	Challenge Information Text OTP Code Entry	This text must include the following language: OTP by SMS: We just sent you a verification by text message to <<masked phone number>>. You have [number of attempts to enter OTP] attempts. OTP by Email: We just sent you a verification code by email to <<masked email>>. You have [number of attempts to enter OTP]
3	Challenge Information Label	The display name for this field must be ‘Verification Code’.
4	Challenge Information Data Entry	Input Box
5	Submit Authentication Label	A form element that should align with the center of the bottom margin displaying “Confirm”
6	Resend Information Label	The display name for this field must be ‘Resend Code’. Challenge Information is resent to the customer. A form element that should vertically align with the center of the bottom margin.
7	Trusted Beneficiary Check Box	A check box must be included with the following suggested language: Turn on fast authentication to skip these steps in the future While an issuer may have their own language around the trusted beneficiary program, the language above, calling the program ‘Fast Authentication’ was preferred during Visa user testing. This is the recommended language for Trusted Beneficiary programs from a Visa perspective.
8	Trusted Beneficiary Information Label	Display the Trusted Beneficiary information label as a graphical control element that can be expanded. The display name for this field must be ‘Learn more about fast authentication’.
9	Trusted Beneficiary Information Text	Display the Trusted Beneficiary Information Text only when the user selects the “Trusted Beneficiary Information Label”. The following language is recommended: Banks are now required to take customers through extra verification steps when making certain purchases online. [Issuer Name] allows customers the option to skip these at some online stores without compromising on security.
10	Why Information Label	Display the Why Information Label as a graphical control element that can be expanded. The display name for this field must be ‘Need Help?’.
11	Why Information Text	Display the Why Information Text only when the user selects the “Need Help? Label”. Text provided by the Issuer to be displayed to the cardholder to explain why the cardholder is being asked to perform the authentication task.

The guidelines above demonstrate the trusted beneficiary flow using a one-time passcode (OTP) challenge. Issuers may use any of the EMV 3DS challenge types (Out of Band, Knowledge-Based, etc.) to authenticate a cardholder for the trusted beneficiary use case.

Cardholder Information Text

The cardholder information text field is text provided by the ACS/Issuer in the authentication response to a merchant during a frictionless or decoupled transaction. This field is optional for ACS/Issuers to populate unless the transaction utilizes Decoupled Authentication. It is optional for Merchants to display in EMV 3DS 2.1 but mandatory for Merchants to display in EMV 3DS 2.2. Regardless of the EMV 3DS version in use, when populated, Merchants are strongly encouraged to display this information to cardholders to enhance the EMV 3DS user experience.

The cardholder information text is useful whenever an issuer wants to give their cardholder a call to action to improve their authentication experience. For example, an issuer may suggest to their cardholder to download their mobile banking app for a better authentication experience next time they shop online or to convey important information to the cardholder e.g. Contact your bank.

Merchants benefit from displaying the cardholder info text to cardholders by enabling cardholders to complete the necessary steps to have a better EMV 3DS experience, and thus a better shopping experience. Merchants are encouraged to display the cardholder information text to cardholders in the checkout page. The user-tested guidelines below show merchants how to properly display the cardholder information text to the cardholder.

Successful Authentication

Issuers may want their cardholders to complete an additional step (i.e., download mobile banking app) to enhance their EMV 3DS 2.2 user experience after a successful authentication. Merchants are encouraged to show the cardholder info text in the ‘Order Confirmation’ screen such that cardholders can complete the issuer’s call to action and have a better EMV 3DS user experience next time they shop online.

Cardholder Information Text - Order Confirmed Screen

Zoom

It is recommended for the cardholder information text to be formatted in the style of the merchant’s checkout page. The cardholder information text should be prominent in the merchant’s order confirmation screen so that cardholders can take the call to action.

Failed Authentication

In the event of a failed authentication, issuers may want their cardholders to complete authentication steps outside of the EMV 3DS 2.1 and 2.2 flow so that their cardholder can be authenticated via EMV 3DS for their next purchase. Merchants are encouraged to show the cardholder info text so that both merchant and cardholder can enjoy the benefits of EMV 3DS.

If a merchant proceeds to submit an ECI 07 (non authenticated eCommerce) authorization request due to the failed EMV 3DS authentication, it is recommended for the merchant to display the cardholder info text to the cardholder in the ‘Order Confirmation’ screen.

Zoom

If a merchant does not proceed to authorization and the transaction ends, then it is recommended for the cardholder information text to be shown in the merchant’s checkout page. Thus, if the cardholder follows the call to action, they may be able to return and complete the purchase.

Cardholder Information Text - Checkout screen

Zoom

Visa Secure Program & Implementation Guide

Please visit Visa Online at https://secure.visaonline.com/, sign in and search for “Visa Secure” for related Program and Implementation guides. If you do not have a sign in credential to Visa Online, please work with your issuer or acquirer.

Legal Disclaimer

Important Information on Copyright and Disclaimers

Notice: The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively the “Trademarks”) are Trademarks owned by Visa. All other trademarks not attributed to Visa are the property of their respective owners, are used for identification purposes only and do not imply product endorsement or affiliation with Visa.

Note: This document is not part of the Visa Core Rules and Visa Product and Service Rules. In the event of any conflict between any content in this document, any document referenced herein, any exhibit to this document, or any communications concerning this document, and any content in the Visa Core Rules and Visa Product and Service Rules, the Visa Core Rules and Visa Product and Service Rules shall govern and control.

Note: Please note that the screens are for illustrative purpose only.

Disclaimers: THIS DOCUMENT IS PROVIDED ON AN "AS IS,” “WHERE IS,” BASIS, “WITH ALL FAULTS” KNOWN AND UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE LICENSED WORK AND TITLES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT OF THIRD-PARTY INTELLECTUAL PROPERTY RIGHTS.