Below you will find all the major 3-D Secure flows for both versions explained using some simple screenshots. These screenshots contain steps that employ simulators of the actual authentication and authorization steps that you will also encounter during your testing on our testing environments.
The images depict a flow using the MyCheckout Hosted Payment Pages, but they can be used to illustrate a pure API integration using the Create Payments API as well. In that case the Payment product selection, Card data entry and Payment result pages are on your website and all other pages are identical to the MyCheckout hosted payment pages. Even for the Create Payments API it is possible to style the pages that we display using the Page Editor in the Configuration Center. It is even possible to employ multiple variants and call each of them via the API.
No 3-D Secure
The most simple flow is the one that does not involve any 3-D Secure elements. This could happen when the issuer isn't capable to perform any authentication. To make all the images follow the same flow the authorization seems to take place at a much later moment in time, but in reality it is executed directly after the enrollment check.
3-D Secure version 2 - Frictionless
The ideal 3-D Secure version 2 flow doesn't involve any redirection and is called frictionless. In essence the user experience is identical to the previous no 3-D Secure flow, however in this case the authentication did in fact took place based on the various properties that you provided in the payment request.
3-D Secure version 2 - MethodURL + Frictionless
Some issuers will make use of what is known as the MethodURL in the EMVco specifications. This is a seemingly empty page that will allow the issuer to collect information from the clients browser in a hidden iFrame. This page requires to display a spinner while this process is ongoing. The issuer is allowed to take maximum 10 seconds to complete this step and we will automatically continue with the process. This MethodURL step is performed prior to to actual authentication request. In this flow the outcome of the authentication is that no challenge is required, so we continue with a frictionless flow to authorization.
3-D Secure version 2 - MethodURL + Challenge
If the issuer doesn't have a high confidence in the transaction even after the MethodURL step the outcome of the authentication request can be that the consumer needs to complete a so called Challenge. Please note that some specific transaction use cases Strong Customer Authentication is required:
- Tokenization for a card for future use (first Consumer Initiated Unscheduled Card on File transaction)
- First recurring transaction
How this Challenge will be performed will differ between issuers and is outside of our control. After the Challenge is successfully completed we will perform the authorization before showing the result page or redirecting back to your website.
3-D Secure version 2 - Challenge
Not all issuers will implement the additional MethodURL step as there is likely some cost for the issuer involved. If the issuer doesn't feel confident or is required due to the type of transaction to perform a Strong Customer Authentication the consumer will need to complete the Challenge step.
3-D Secure version 1 - Challenge
In the case of 3-D Secure version 1 most issuers don't perform any risk analysis as they get very little transaction information to make any informed decision on, so they employ the only defense they have, which is a Challenge flow.
- Highlevel implementation
- Consumer user experience
- MyCheckout hosted payment pages implementation
- Create Payment API implementation
- Test cases
- Special use cases