Welcome to the UX product guidelines for 3-Domain Secure 2.0 (3DS 2.0) 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.
3DS 2.0 is designed to prevent fraudulent online transactions. With this feature in place, an extra security layer helps keep transactions and accounts safer.
The majority of transactions are frictionless, but sometimes transactions need to be challenged. In these circumstances, we present a challenge question or an action to verify that the purchaser is really the account holder.
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.
Want to begin? Let’s get started.
3DS 2.0 accommodates all screen sizes. Now you have the freedom and flexibility to customize the user interface to fit your digital brand identity.
Merchants can embed 3DS 2.0 into a web page (via iFrame) or native application (via a Webview). You can customize the user interface elements (e.g., buttons, fonts, inputs) for all content for any challenge method you use.
As an issuer, you should always consider how merchants will implement 3DS 2.0.
The layout of every challenge follows a natural hierarchy. A consistent hierarchy leads to a better customer experience.
Merchants expect 3DS 2.0 to be adaptive to all screen sizes (e.g., phone, tablet, and desktop devices).
In this section, we explore how merchants could implement 3DS 2.0 guidelines based on our layout recommendations and guidelines for merchants. Choices will vary based on technical capabilities and existing platforms.
Merchants could implement a modal view that sits above their checkout page, however, we advise using full width and full height layouts for small screens.
Merchants could implement an overlay that sits above their checkout page, e.g., a slide in panel.
Merchants could place the challenge directly into a web page or web view (inline) during the checkout process. This is commonly used in 3DS 1.0 implementations.
This section contains descriptions for 3DS 2.0 challenge methods.
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.
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.
Customers verify transactions by answering knowledge-based questions. Issuers can choose which methods to make available for customers.
Customers verify transactions by entering a passcode or a biometric feature. Issuers can choose which methods to make available for customers.
A customer's purchase can be verified on the existing issuer app by entering sign-in credentials. We advise using a sign-in passcode on small screens for ease of use. Our recommended journey uses a mobile device to authenticate, no matter which channel is used to make purchases.
Many iOS and Android users already have the ability to use fingerprint scanning to access their phones. We recommend using the same method to authenticate customers. We advise any biometric authentication is used in addition to a passcode. So if biometric authentication issues arise, the customer may switch to a passcode.
Another method of authentication is voice recognition. This can be done directly via issuer app or via a connected device linked to an issuer app, such as a digital watch.
Users can also be authenticated using face recognition. Some iOS and Android devices already have the capability to identify users with this method.
We recommend giving users the flexibility to select a method of authentication (i.e., via passcode or fingerprint) and/or notification settings.
We recommend issuers enroll users to 3DS automatically. Once users are enrolled, we advise welcoming users in their banking app with the option to change the default settings.
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.
For full accessibility guidelines, visit wcag.org.
<h3>subsection header </h3>
<h3>subsection header </h3>
Visit wcag.org for full accessibility standards.
Recommendations and examples for challenge user interface elements.
We have split specific journeys into focused content blocks to tell a clear, linear story through challenges. As such, there is no back button functionality in 3DS 2.0.
Some challenges require text entry by entering a secure one-time passcode (OTP) or providing a knowledge-based answer (KBA).
Text field labels
For specific tasks, clearly label all form fields with descriptions for the required actions. Labels can be implemented in many ways but should adhere to the following rules.
Label buttons as calls-to-action to complete a task in challenges. Upon touch, the text field automatically becomes active.
Radio buttons allow users to select one option. When only one option is available, the button is selected by default.
Checkboxes allow people to select multiple options.
Error messages require three elements:
1. What went wrong?
The message informs the user which action/inaction resulted in the error message to appear.
2. How to fix the problem
Provide directions on how the user can "fix" the issue and move forward. Indicate to users how long a system error will take to restore and provide a suitable option to exit.
3. Clearly display error messages
The best practice is for error messages to be distinguishable from existing content, displayed in red and in close proximity to where the error occurred.
Any system issues that affect pages should result in a message page displayed to the users.
The information page should provide the following information:
Long wait times may cause users to drop off. A progress indicator informs users of activity and that loading is imminent.
The Issuer Implementation Guide provides details on:
The Merchant/Acquirer Implementation Guide provides details on the same areas, but for Merchants and Acquirers.
The implementation guides supplement the Visa Core Rules and Visa Product and Service Rules.
To get access to the latest documents, please visit Visa Online at https://secure.visaonline.com/
Important Information on Copyright and Disclaimers
© 2018 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.
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.