General information

Overview

3‑D Secure 2 is a new version of the 3‑D Secure protocol which is intended to secure e-commerce card payments. The key advantages of 3‑D Secure 2, as compared to 3‑D Secure 1, include the following:

  • Extended payment options thanks to support of authentication in mobile apps. (No browser is required.)
  • Enhanced security thanks to no static passwords (for instance password sets issuer provides) and use of more secure authentication methods—for example by using biometric data—and support for extended customer details provided when performing authentication.
  • More convenient payment procedure and increasing payment conversion rate thanks to new flow for authenticating customer by issuer with no customer interaction.

3‑D Secure 2 supports two authentication flows: frictionless flow and challenge flow. In the frictionless flow, the customer authentication is performed with no customer interaction. The challenge flow requires the customer to provide additional authentication information such as one-time code (as in 3‑D Secure 1) or biometric data.



The choice between frictionless flow or challenge flow is performed by the issuer based on available information about the customer including the customer information provided by the merchant. The information may include customer account details in merchant stored web service or delivery address. To increase probability of selecting the frictionless flow, it is recommended that merchant collects and submits additional related to customer parameters.

As 3‑D Secure 1, the 3‑D Secure 2 uses three domains:

  • Acquirer domain In the context of the ECommPay payment platform interoperability, it includes merchant web service, the payment platform, and its 3DS Server.
  • Interoperability domain The infrastructure provided by the card scheme, for instance Directory Server (DS).
  • Issuer domain This includes the issuer's Access Control Server (ACS) (and the authentication page deployed on ACS).

For more information about interoperability of the domains, see 3‑D Secure 2 workflow in Payment Page and 3‑D Secure 2 workflow in Gate.

Please note that the information about the possibility of customer authentication is stored on the 3DS Server, and therefore this information can only be obtained after sending a payment request. Also, the payment platform does not have control over customer actions on the authentication page, but only receives the authentication result.

Frequently asked questions

This section provides the answers to the common questions regarding 3‑D Secure 2 and its support and usage options.

General protocol issues

Adopting and implementation

Usage options

For more information regarding 3‑D Secure 2, refer to your account manager at ECommPay.

What is the difference between 3‑D Secure 2 and 3‑D Secure 1?

The key advantages of 3‑D Secure 2, as compared with 3‑D Secure 1, include the following:
  • Extended payment options thanks to support for authentication in mobile apps. (No browser is required.)
  • Enhanced security thanks to use of more secure authentication methods and support for extended customer details provided when performing authentication.
  • More convenient payment procedure and increasing payment conversion rate thanks to new flow for authenticating customer by issuer with no customer interaction.
  • Enhanced security thanks to support of more secure authentication methods
  • Support for authentication in mobile apps and support for extended customer details provided when performing authentication
  • Possibility to perform authentication with no customer involvement

User experience becomes flexible with optional customer redirection to the preload page hosted on the payment platform, the support of the two authentication flows—frictionless flow and challenge flow, and new customer authentication methods (for example using biometric data in a mobile app).

The communication between merchant web services and the ECommPay payment platform was enhanced to include new parameters and new data structures in callbacks. To move to 3‑D Secure 2, merchants are required to register with Visa Secure and/or Mastercard Identity Check and place Visa Secure and/or Mastercard Identity Check logos on their payment pages.

It is not mandatory to support all these changes in your web service but it is required to place the logos on merchant payment pages.

Are there any changes in the end-user experience?

Unlike 3‑D Secure 1 in which the authentication procedure is always performed with a single redirect, in 3‑D Secure 2 the number of redirects may differ:

  • If your web service uses the same scheme as 3‑D Secure 1 authentication workflow, the customer is redirected to preload page hosted on the payment platform before redirection to issuer's Access Control Service (ACS) page. Alternatively, if your web service uses the new scheme implemented in the 3‑D Secure 2 authentication workflow, no such redirection occurs.
  • If the issuer chooses the challenge flow, the customer is redirected to issuer's ACS page. If the issuer chooses the challenge flow, such redirection is not performed.

Customers may be offered to choose authentication method, for example the issuer may request the customer to confirm their identity by using biometric data.

What are the procedures for handling customer's biometric data?

3‑D Secure 2 can use biometric data to authenticate customers. This functionality requires that both issuer and customer device are capable to store and process biometric data. Note, though, that it is issuer who—at its own discretion—determines the customer authentication procedure and the authentication options.

Customer authentication by using fingerprint reader or facial recognition system (such as Face ID) on customer's mobile device is example of using biometric data.

Can I find out in advance whether customer must be authenticated?

No, the information about the possibility of customer authentication is stored on the 3DS Server, and therefore this information can only be obtained after sending a payment request.

Are there any payments that do not require the 3‑D Secure 2 authentication?

Yes, the following payments that lie outside of the PSD2 scope:

  • Payments with cards issued outside of EEA
  • Payment with anonymous prepaid cards such as gift card or prepaid virtual card
  • Mail Order/Telephone Order payments (MO/TO)
  • Merchant-initiated transactions (MIT) in which the initial transaction included the 3‑D Secure 2 authentication procedure regardless of the flow type—challenge flow or frictionless flow.

The payment platform detects these payments and omits the authentication procedure when processing these payments.

Optionally, issuer may also choose not to require 3‑D Secure 2 for exemptions such as the following payments:

  • Purchases below €30, if after the last 3‑D Secure 2 authentication procedure the customer made no more than five payments totaling no more than €100.
  • Low-risk payments that comply with the PSD2 regulations.
  • Payments to merchants that are included in cardholder's trusted beneficiaries list.
  • Secure corporate payments that are initiated by payers who are not consumers and use dedicated corporate processes and protocols that national competent authorities consider sufficiently secure.

Currently, the ECommPay payment platform does not supports these exemptions.

Can I altogether avoid 3‑D Secure 2 authentication when performing payments that are exempt from 3‑D Secure 2?

No, this is not necessarily true. It is up to the issuer to decide whether 3‑D Secure 2 authentication is required. The issuer may respond with a soft decline after which the merchant will be required to resend the payment request with the same payment parameters as in the initial request to perform the 3‑D Secure 2 authentication.

What is required to implement 3‑D Secure 2?

To implement 3‑D Secure 2 on your web service, you need to do the following:

  1. Contact your ECommPay account manager and discuss the possibility of implementing 3‑D Secure 2 and the implementation time and schedule.
  2. Update your web service to support 3‑D Secure 2. For more information, see The payment platform updates and merchant's TODO list).
  3. Test and deploy the 3‑D Secure 2 support with ECommPay support service assistance.

How does the implementation of 3‑D Secure 2 affect the Gate payments?

Merchants face the following choice:

  • Basic workflow that uses almost the same algorithm that 3‑D Secure 1 and the same requests and callback parameters. Continue to use the authentication workflow as it is implemented for 3‑D Secure 1. In this case, the implementation of 3‑D Secure 2 does not affect the interaction between merchant web service and the payment platform and there is no need to update any parameters; but in order to implement the 3‑D Secure 1 authentication workflow, merchant needs to place Visa Secure and/or Mastercard Identity Check logos on their payment pages.
  • Extended workflow that uses the new algorithm and does not require any intermediate customer redirects. Upgrade their code to comply with the new 3‑D Secure 2 workflow. In this case, merchant will be able to avoid multiple customer redirects. In order to implement the new 3‑D Secure 2 authentication workflow, you need to implement parsing callbacks with the new parameters; also, merchant needs to implement a new procedure of redirecting the customer to the authentication page. Also, you can implement parsing callbacks from the Access Control Server and issuing a new request and use the 3‑D Secure 2 authentication in a few or all the payments. For information about how to implement the 3‑D Secure 2 authentication in payment processing, see 3‑D Secure 2 workflow in Gate.

Also, in either of the authentication workflows, to increase probability of selecting the frictionless flow, it is recommended that merchant collects and submits additional customer parameters in payment requests. Apart from that, the communication with the payment platform remains the same.

Once you implement the algorithm similar to the one used for 3‑D Secure 1, you can benefit from a simplified transition (without account manager assistance) to the workflow that uses the new algorithm. To do so, you only need to pass the acs_return_url object with the return_url parameter inside payment requests. For more information, see Payment request formats. If you not include the return_url parameter in payment requests, the new algorithm will not be applied.

How does the implementation of 3‑D Secure 2 affect the Payment Page payments?

There is no immediate need for merchants to update their web service to comply with the 3‑D Secure 2 procedures, although to increase probability of selecting the frictionless flow, it is recommended that merchants implement the functionality for parsing new parameters and use additional customer parameters in requests for opening Payment Page. Apart from that, the communication with the payment platform remains the same.

How does the implementation of 3‑D Secure 2 affect the Dashboard operations?

In order to comply with the Payment Services Directive 2, we apply two-factor authentication with Google Authenticator codes to access the Dashboard interface and with one-time SMS codes for confirming financial operations.

Do you offer test cards to set up and debug the new workflow?

To implement and debug your payment procedures that use the new authentication workflow, you can use the following test cards:

Visa cards:

  • frictionless flow authentication:
    • 4477 0000 0000 0006—successful payment (payment status: success)
    • 4012 0000 0002 0063—declined payment (payment status: decline)
  • challenge flow authentication:
    • 4314 2200 0000 0056—successful payment (payment status: success)
    • 4012 0000 0002 0089—declined payment (payment status: decline)

Mastercard cards:

  • frictionless flow authentication:
    • 5252 0000 0000 0004—successful payment (payment status: success)
    • 5544 3300 0000 0029—declined payment (payment status: decline)
  • challenge flow authentication:
    • 5413 3300 0000 0019—successful payment (payment status: success)
    • 5544 3300 0000 0045—declined payment (payment status: decline)

If you have any questions regarding test payments, contact our technical support at support@ecommpay.com.

Can I use 3‑D Secure 2 for all payments with Visa, Mastercard, and Maestro cards?

No, support of 3‑D Secure 2 depends on the issuer and provider readiness to implement the new authentication procedure. From the 14 September 2019, the expectation is for all e-commerce payments in European Economic Area (EEA) to be processed by using 3‑D Secure 2 to meet the Strong Customer Authentication (SCA) requirements. The issuers in other regions are expected to support 3‑D Secure 2 by the end of 2020.

Do I need to support 3‑D Secure 1 if I use 3‑D Secure 2?

Yes, you do need to support the 3‑D Secure 1 authentication, since in some cases an issuer or a provider may prefer 3‑D Secure 1 because the 3‑D Secure 2 is not possible or feasible. For instance, Mastercard allows payment platform to fall back to 3‑D Secure 1 and retry the authentication procedure, if the 3‑D Secure 2 authentication fails due to unavailability of payment system or issuer.

Can merchant choose to use 3‑D Secure 1 instead of 3‑D Secure 2?

No, the decision as to protocol choice belongs solely to the 3DS Server and depends on available issuer facilities. There is no way the merchant can affect the protocol choice.

Is there a tool I can use to find out the protocol that was used?

To determine the protocol that was used in processed payment, you can use a callback with the information about payment results that the payment platform submits or use the Dashboard interface.

Is it possible to process payments without authenticating by using 3‑D Secure (non-3DS)?

Yes, merchant can refrain from using the 3‑D Secure authentication. Note though the following:
  • From 1 February 2020, all the EEA issuers must decline any payments that do not use 3‑D Secure 2 except for the following payments: the payments that fall outside the PSD2 scope and the payments which are exempt according to PSD2. For more information, see the answer to the question regarding this type of payments. Merchant can refrain from using the 3‑D Secure authentication in payments with cards issued inside of EEA if the payments lie outside of the PSD2 scope.
  • If you as a merchant stop using authentication for payments, you will be fully responsible and held liable for all damages that arise due to any fraudulent actions.

For more information about exempts from mandatory 3‑D Secure 2 authentication, refer to you ECommPay account manager.