The implementation of 3DS2 will be done consecutively and may last until 2021.

  • Fallback to 3DS1

    While 3DS2 is being deployed by all the operators, the following process will be applied:
    1. The payment gateway initiates the process of 3D Secure v2 authentication.
    2. If the card is 3D Secure v2 enrolled, the 3D Secure v2 process continues.
    3. If the card is not 3D Secure v2 enrolled, the payment gateway proceeds with cardholder authentication in 3D Secure v1 mode.
  • Merchant enrollment

    No impact on already 3DS1-enrolled merchants. The payment gateway is responsible for 3DS2 enrollments on different Directory Servers (DS).

    As for companies that are not yet 3DS1-enrolled, the payment gateway will enroll them to 3DS1 and 3DS2.

  • Impact of implementation on the merchant website

    Little impact. Without any modifications, your current implementation is compatible with 3DS2, even if you display the payment page in an iframe.

    When all operators are operational, it will be possible to transmit complementary details to increase the chances of frictionless during payments (see corresponding chapter Increasing the chances of a frictionless payment).

  • Selective 3D Secure

    Merchants who use the vads_threeds_mpi field for disabling 3D Secure v1 will have to update their implementation in order to take into account the newly available options:

    The new values will only become available after 3DS2 is enabled for your MID.

    vads_threeds_mpi Meaning
    missing or empty or 0 Management of 3DS authentication delegated to the payment gateway (domain, provider, shop configuration)
    1 Deprecated.
    • 3DS1: 3DS authentication disabled for the transaction.

      Requires the “Selective 3D Secure” option.

    • 3DS2: NO CHALLENGE REQUESTED: Allows to request authentication without interaction (frictionless).

      The merchant loses the payment guarantee if the request is accepted.

    • 3DS1: 3DS1 authentication
    • 3DS2: CHALLENGE REQUESTED: Allows to request strong authentication for the transaction.
    • 3DS1: 3DS1 authentication
    • 3DS2: CHALLENGE REQUESTED: mandate: Allows to indicate that strong authentication is required for the transaction, for regulatory reasons.
    • 3DS1: 3DS1 authentication
    • 3DS2: NO PREFERENCE: Allows to indicate to the DS that the merchant does not have a preference. If the issuer decides to perform an authentication without interaction (frictionless), the payment will be guaranteed.
  • Management of transactions with amounts over €30 and a merchant preference

    As long as the issuers are not ready for frictionless transactions, if the merchant sends the value NO_CHALLENGE_REQUESTED in the payment request, the gateway replaces this value with NO_PREFERENCE.

    Thus, if the issuer decides to challenge the buyer, the merchant does not lose the payment guarantee.

  • Creation of a token

    Eventually, strong authentication will always be required during token creation, regardless of the merchant’s choice.

  • Installment and recurring payments

    Eventually, strong authentication will always be required for the first installment, regardless of the merchant’s choice.

  • IPN

    A field has been added to the IPN in order to transmit the used authentication type (vads_threeds_auth_type) (FRICTIONLESS or CHALLENGE) to the merchant.