Visa Secure using EMV® 3DS User Experience Guidelines
Welcome to the UX guidelines for EMV 3DS
Whether you are a designer, product manager or business decision-maker, these guidelines will help you create the best EMV 3DS authentication challenge experiences for your cardholders across desktop and mobile devices.
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.
Payment Flows
This section has UX guidelines so that you can create the best possible EMV 3DS authentication challenge experiences for your cardholders.
Additional Use Cases
The EMV 3-D Secure protocol is able to solve for various use cases in addition to eCommerce payment authentications.
Global Anatomy
The layout of every challenge follows a natural hierarchy. A consistent hierarchy leads to a better customer experience.
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
Visa Logo |
Challenge Zone |
Contains processing and challenge information and is located between the Branding zone and the Information zone.
|
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
For Browser/HTML interfaces
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. |
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
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 – Mobile + Browser
Processing screen must include a spinning wheel and the Visa logo underneath.
Responsive Design
Merchants expect Visa Secure to be adaptive to all screen sizes (e.g., phone, tablet, and desktop devices).
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.
Mobile
Full width panel is shown on small screens.
Tablet
Temporary side panel overlay; the position and width of the panel stays the same as it appears over the merchant content
Computer
You can choose to launch the panel on the left or right to work with your content. Customers can close it by pressing 'Cancel' in the panel
TV
For TV, the authentication challenge is shown in the screen real estate provided for it by the merchant using the 3DS SDK
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
Element |
Requirement |
|---|---|
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. |
| 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). |
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.
Element |
Code/Requirement |
|---|---|
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 verify payment to (merchantName) for {purchaseCurrency} (purchase amount). This means you will not be able to purchase the item(s) in your basket. |
Return to Authentication page |
A form element that should align with the center of the margin displaying “Don’t Cancel”. |
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.
Design Best Practices
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.
- Visa Global Accessibility Requirements (VGAR) on Visa Developer Platform
- Visa Accessibility Statement published on visa.com
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.
Previous Releases
Click here to download the UI Guidelines with Visa Secure using 3DS 1.0 PDF.
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
© 2022 Visa. All Rights Reserved
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.