3D Secure 2.0
3D Secure 2.0 (3DS 2.0, 3DS2 or EMV® 3-D Secure) is the new authentication protocol developed by EMVCo to address the issue of customer authentication in remote payments. It provides the fraud prevention and chargeback protection benefits of 3DS1 while facilitating frictionless and seamless e-commerce customer journeys compatible with different channels.
Payvision offers a 3D Secure 2.0 solution with flexible integration options which minimizes the complexity for merchants and consumers. And for our merchants who are already using our 3D Secure solution, we offer an easy upgrade path to 3DS 2.0.
Want to enable 3D Secure 2.0 for your business? Just get in touch with your Payvision account manager to set it up. Or, if you don't have a Payvision account yet, reach out to our Payment Experts for a chat. We're here to help.
3DS 2.0 is Payvision’s recommended method to meet the Strong Customer Authentication (SCA) requirements in Europe and request exemptions to SCA. Read more
Key features of 3DS 2.0
The key features of 3D Secure 2.0 include:
1. Secure authentication: This protocol allows advanced techniques of authenticating the cardholder, such as with two-factor authentication.
2. Dedicated device channels: It is tailored to whether the authentication is requested from a merchant Mobile Application, Website or from a Server-Server API call.
3. Improved user experience: With 3DS1, the cardholder goes through a full-page redirect, which results in a clunky user experience. 3DS2 introduces guidelines to remove these challenges for the cardholder.
4. Frictionless vs. Challenge flow: One of the new features includes the concept of the "frictionless flow", where a silent authentication is performed without challenging the cardholder.
5. Data-driven risk analysis: The 3DS2 protocol collects more data points than 3DS1. Though some of these data points are optional, providing them to the issuer during an authentication challenge allows high-quality decisions to be made on whether to proceed with a frictionless or challenge flow.
3DS 2.0 workflow with Payvision
The diagram below describes the 3DS 2.0 workflow with Payvision's integrated 3DS Server and the liability shift for each case.


3DS 2.0 workflow with Payvision
The merchant initiates the 3DS2 authorization/payment request to AceHub through one of our Integration options. It's possible to request for exemptions during this step. From here on, AceHub facilitates the authentication and authorization.
AceHub checks with the card issuer if 3DS2 is supported. If yes, it collects the device data of the cardholder and forwards the authentication request with all the data points and exemptions (if requested) to the issuer.
The issuer decides whether it will result in a frictionless or challenge flow. Note that if the merchant requested for an exemption and it results in a frictionless flow, the liability sits with the merchant. However, if the issuer decided to apply the exemption, the liability shifts to the issuer.
If the frictionless flow is triggered, AceHub immediately proceeds with the authorization without any further action needed and sends the cardholder back to the merchant's store.
If a challenge is requested, AceHub handles all the communication between the cardholder and issuer to complete the additional authentication before proceeding with the authorization and finally sends the cardholder to the merchant's store.
In case the issuer does not support 3DS2, AceHub automatically routes the transaction via the 3DS1 route to ensure that authentication takes place regardless, before proceeding with the authorization. This is beneficial to the merchant as the liability shifts to the issuer.
Your 3DS 2.0 implementation options
Payvision offers the following implementation options to support 3DS 2.0 and comply with PSD2 SCA.
-
If you're using the Payments API, refer to 3D Secure 2.0 with Payments API
-
If you're using the Checkout API, refer to 3D Secure 1 and 2 with Checkout
-
If you're using the Payment link API, refer to 3D Secure 1 and 2 with Payment link
-
If you're using an external 3DS Server and using Payvision for authorization-only, refer to 3D Secure 2 with external 3DS Server
Additional datapoints for 3DS 2.0
Merchants are required to collect certain mandatory 3DS2 protocol data elements before authentication. The cardholder's name, billing information, and email address are just some examples of the new data elements that are required.
In addition to the new required data elements, there are other optional data points that, if provided, can increase the likelihood of a frictionless flow.
If you're using Payvision's integrated 3DS Server with Payments API, Checkout API or Payment Link API, you can refer to the list below to see the required and optional parameters to be passed when requesting for 3DS2.
Required parameters
Unless market or regional mandates restrict the sending of a parameter listed below, the below parameters must be passed through in 3DS requests.
Parameter name | Type | Description |
---|---|---|
Transaction block | ||
transaction.returnUrl | String | The URL to which the customer should be returned after authentication. |
3D Secure block | ||
threeDSecure.version | String | Version of 3DSecure. |
threeDSecure.recurringInfo.purchaseDate | Date-time | Conditional– Required for initial recurring transaction (i.e. type=FIRST). NOTE: If not passed, Payvision will use current date. |
threeDSecure.recurringInfo.recurringEnd | Date | Conditional – Required for initial recurring transaction (i.e. type=FIRST). |
threeDSecure.recurringInfo.recurringFrequency | Int | Conditional – Required for initial recurring transaction (i.e. type=FIRST). |
Customer block | ||
customer.givenName | String(255) | Given name of the customer. |
customer.familyName | String(255) | Last name of the customer. |
customer.email | String(255) | Email address of the customer. |
customer.mobileNumber | String(64) | Mobile number of the customer. Recommended format E.164. Required for some risk checks. |
Billing address block | ||
billingAddress.city | String(255) | The name of the city. |
billingAddress.stateCode | String(3) | State code. ISO 3166-2 |
billingAddress.street | String(255) | The name of the street. |
billingAddress.countryCode | String(2) | Country code. ISO 3166-2. Mandatory if stateCode is provided. |
billingAddress.zip | String(20) | Zip/postal code for the billing address. |
Please note that no validation errors will be returned by Payvision if these fields are not provided so it is important that you double-check your integration to ensure that no fields are missing. Failure to provide one or more of these fields may result in a higher rate of challenges or declines by the issuer.
Optional parameters
It is recommended that the below parameters are included where possible for the best 3DS experience.
Parameter name | Type | Description |
---|---|---|
Billing address block | ||
billingAddress.houseNumber | String(255) | The street number of the house. |
billingAddress. houseNumberSuffix | String(255) | Conditional - Required only if a house number is supplied and there is a suffix for the house number. |
billingAddress.streetInfo | String(255) | Additional street information. |
Customer block | ||
customer.phoneNumber | String(64) | Phone number of the customer. Recommended format E.164. Required for some risk checks. |
customer.authInfo.alternateAuthenticationMethod | String | Mechanism used by the cardholder to authenticate to the 3D S requester. Possible Values: |
customer.authInfo.alternateAuthenticationDate | Date-time | Date and time in UTC of the cardholder authentication. |
customer.authInfo.alternateAuthenticationData | String | Data that documents and supports a specific authentication process that was sent in the AlternateAuthenticationMethod parameter. |
customer.priorAuthInfo.authenticationData | String | Data that the ACS can use to verify the authentication process. |
customer.priorAuthInfo.authenticationMethod | String | Mechanism used by the Cardholder to previously authenticate to the 3DS Requestor. |
customer.priorAuthInfo.authenticationDate | Date-time | Date and time in UTC of the prior cardholder authentication. |
customer.priorAuthInfo.authenticationRef | String | This data element contains an ACS Transaction ID for a prior authenticated transaction. For example, the first recurring transaction that was authenticated with the cardholder. |
customer.workPhoneNumber | String(64) | The phone number of work. |
DBA block | ||
dba.website | String | Override the Merchant URL configured in the 3DS Server Merchant profile. |
dba.merchantcategoryCode | String | Merchant Category Code to override default value. |
dba.name | String(255) | 'Doing business as' name. For applicable suppliers. |
Risk info block | ||
riskInfo.shippingMethodIndicator | String | Indicates shipping method chosen for the transaction. Possible Values: |
riskInfo.deliveryTimeframe | String | Optional. Indicates the delivery timeframe. Possible Values: |
riskInfo.deliveryEmail | String(255) | For electronic delivery, email address to which the merchandise was delivered. |
riskInfo.reorderIndicator | String | Indicates whether the cardholder is reordering previously purchased merchandise. Possible Values: |
riskInfo.preOrderIndicator | String | Indicates whether cardholder is placing an order with a future availability or release date. Possible Values: |
riskInfo.preOrderDate | Date | Expected date that a pre-ordered purchase will be available. |
riskInfo.giftCard.amount | String | The purchase amount total for prepaid gift cards in major units e.g. $123.45 USD = 12345 |
riskInfo.giftCard.currencyCode | String | ISO 4217 currency code for the gift card purchased. |
riskInfo.giftCard.count | String | Total count of individual prepaid gift cards purchased. |
riskInfo.cardHolderInfo.accountAgeIndicator | String | Length of time cardholder has had account. Possible Values: |
riskInfo.cardHolderInfo.accountCreateDate | Date | Date the cardholder opened the account. |
riskInfo.cardHolderInfo.accountChangeIndicator | String | Length of time since the last change to the cardholder account. This includes shipping address, new payment account or new user added. Possible Values: |
riskInfo.cardHolderInfo.accountChangeDate | Date | Date the cardholder's account was last changed. This includes changes to the billing or shipping address, new payment accounts or new users added. |
riskInfo.cardHolderInfo.accountPwdChangeIndicator | String | Length of time since the cardholder changed or reset the password on the account. Possible Values: |
riskInfo.cardHolderInfo.accountPwdChangeDate | Date | Date the cardholder last changed or reset password on account. |
riskInfo.cardHolderInfo.shippingAddressUsageIndicator | String | Indicates when the shipping address used for transaction was first used. Possible Values: |
riskInfo.cardHolderInfo.shippingAddressUsageDate | Date | Date when the shipping address used for this transaction was first used. |
riskInfo.cardHolderInfo.transactionCountDay | Int | Number of transactions (successful or abandoned) for this cardholder account within the last 24 hours. |
riskInfo.cardHolderInfo.transactionCountYear | Int | Number of transactions (successful or abandoned) for this cardholder account within the last year. |
riskInfo.cardHolderInfo.addCardAttempts | Int | Number of add card attempts in the last 24 hours. |
riskInfo.cardHolderInfo.accountPurchases | Int | Number of purchases with this cardholder account during the previous six months. |
riskInfo.cardHolderInfo.fraudActivity | String | Indicates whether the merchant experienced suspicious activity (including previous fraud) on the account. Possible Values: |
riskInfo.cardHolderInfo.paymentAccountIndicator | String | Optional. Indicates the length of time that the payment account was enrolled in the merchant account. Possible Values: |
riskInfo.cardHolderInfo.paymentAccountAge | Date | Date the payment account was added to the cardholder account. |
Shipping address block | ||
shippingAddress.customer.givenName | String | Given name of the customer. |
shippingAddress.customer.familyName | String | Last name of the customer. |
shippingAddress.customer.phoneNumber | String | Phone number of the customer. Recommended format E.164. Required for some risk checks. |
shippingAddress.customer.workPhoneNumber | String | Work phone number of the customer. Recommended format E.164. Required for some risk checks. |
shippingAddress.houseNumber | String | The number of the house. |
shippingAddress. houseNumberSuffix | String | The suffix of the house number. |
shipping.street | String | The name of the street. |
shippingAddress.streetInfo | String | Additional street information. |
shippingAddress.stateCode | String | State code. Format: ISO 3166-2. |
shippingAddress.city | String | The name of the City. |
shippingAddress.countryCode | String | Country code. Format: ISO 3166-2. Mandatory if stateCode is provided. |
shippingAddress.zip | String | Zip/postal code for the shipping address. |
3D Secure block | ||
threedsecure.additionalInfo.challengeWindowSize | String | Conditional. An override parameter that a merchant can pass in to set the challenge window size to display to the end cardholder. The ACS will reply with content that is formatted appropriately to this window size to allow for the best user experience. The sizes are width x height in pixels of the window displayed in the cardholder browser window. NOTE: Payvision will choose the best possible option based on the device data collected or set a default value in the merchant's configuration. This value will override both of those. |
threedsecure.additionalInfo.decoupledMaxTime | Int(5) | Indicates the maximum amount of time that the 3DS Requestor will wait for an ACS to provide the results of a Decoupled Authentication transaction (in minutes). Possible Values: |
threedsecure.additionalInfo.decoupledIndicator | String(1) | Indicates whether the 3DS Requestor requests the ACS to utilise Decoupled Authentication and agrees to utilise Decoupled Authentication if the ACS confirms its use. Possible Values: NOTE: If the element is not provided, the expected action is for the ACS to interpret as N, DO NOT use Decoupled Authentication. |
Updated about 1 year ago