3D Secure (Three-Domain Secure) is an additional security layer for online credit and debit card transactions. It is designed to reduce fraud and provide a safer online shopping experience.
When a cardholder makes an online purchase, the 3DS protocol may prompt them to complete an additional authentication step. This typically involves redirecting the cardholder to their bank's website or app, where they may be asked to enter a password, a one-time code sent via SMS, or use biometric authentication (like fingerprint or facial recognition).
This additional step helps verify that the person making the transaction is indeed the cardholder, thereby reducing the risk of fraud.
The 3DS authentication flow can result in two possible outcomes:
- Frictionless: where the cardholder is not required to complete any additional steps, as the transaction is deemed low-risk by the issuer;
- Challenge: where the cardholder is required to complete an additional authentication step, such as entering a password or a one-time code, to verify their identity before the transaction can be completed.
When a transaction is routed through 3DS v2, the payment provider can send over 100 data elements to the cardholder's bank to help assess the risk of the transaction. This transmission of data is commonly referred ti as Device Data Collection (DDC). The issuer uses this data to determine whether the transaction is low-risk and can be processed frictionlessly or if it requires additional authentication.
Note that the DDC step is not always required, and its implementation may vary based on the payment provider and the specific transaction.
This flow can happen before or after the DDC. Some transactions may qualify as frictionless immediately whilst others require the DDC take place before deciding which flow is applicable.
In practical terms, this means customers will not be required to complete a challenge (e.g., OTP, SMS code, etc.) and the transaction will be authorized without any additional steps.
If the bank requires additional authentication, the cardholder will be redirected to their bank's website or app to complete the challenge. This may involve entering a password, a one-time code sent via SMS, or using biometric authentication.
Please note: in older version of the 3DS protocol, the challenge would require the customer be redirected to the bank's website or app. However, Ryft supports 3DS v2, which allows for a more seamless experience where the challenge can be completed within the merchant's website or app, without redirecting the customer away from the purchase flow.
Typically merchants aim to increase the likelihood of achieving a frictionless flow, as this provides a better user experience and reduces the chances of cart abandonment. We recommend transmitting as much information as possible on our payments API. This can include information such as:
- billing address
- shipping address
- home/mobile phone number of the customer
- name on card
Starting from August 12th 2024, Visa are mandating changes to the fields required for 3DS transactions.
It is crucial that merchants provide the following fields in order to ensure compliance with Visa's requirements. Failure to do so will likely impact how frequent card issuers opt to challenge customers during the authentication process.
The minimum required fields are as follows:
| Field | Required |
|---|---|
| Browser IP address | Yes |
| Browser screen height | Yes |
| Browser screen width | Yes |
| Cardholder email address | Conditional [^1] |
| Cardholder name | Yes |
| Cardholder home/work/mobile number | Conditional [^1] (at least one) |
| Device IP address | Yes (native iOS/Android) |
[^1] - You must provide at least one of: email / home / work / mobile number of the cardholder. For instance, if you collect Cardholder email, then a phone number is not required. Likewise, if you collect a phone number then email is not required.
The impact of these changes vary based on how you are integrated into Ryft.
If you are PCI compliant and integrated directly with Ryft's Payments API, you will need to ensure that the required fields are included in your API requests. When creating payment sessions, these fields can be provided as follows:
| Field | Payment Sessions API name | Requires change |
|---|---|---|
| Browser IP address | N/A | No |
| Browser screen height | threeDsRequestDetails.screenHeight | No |
| Browser screen width | threeDsRequestDetails.screenWidth | No |
| Cardholder email address | customerEmail | No |
| Cardholder name | cardDetails.name | Yes[^1] |
| Cardholder home/work/mobile number | customerDetails.home/work/mobilePhoneNumber | Yes[^2] |
| Device IP address | N/A | No |
[^1] - We have not required the Cardholder name be collected previously. To collect this, see the section below
[^2] - Ryft have always required customerEmail, meaning you do not need to update your integration to start collecting hom / work / mobile number for the cardholder. Despite this, we still recommend collecting this if possible to increase the quality of the data we supply to Visa on your behalf.
Fields marked above as "No" are already collected by our SDKs and/or have always been required so do not need changes made to support.
Our SDKs already collect the required fields for you, aside from Cardholder name. You don't need to make any changes to your integration. The SDKs will automatically include the necessary information in the payment requests sent to Ryft.