3D Secure 2.0

Principles of 3DS 2.0

Though it reinforces security by better covering the risk of non-payment, the first version of the 3D Secure protocol has often been criticized for its lack of ergonomics. It is indeed responsible for the loss of conversion of loyal customers, and remains constrained to authentication through a smartphone, forcing the customer to juggle between receiving the SMS and validating the code on the same screen.

The 2.0 version of 3D Secure is a major fix, with a promise to strengthen security on all transactions while making the customer journey simpler and frictionless. For banks, there is no need to systematically request authentication for each transaction. The transaction process is now anchored in a risk analysis based upon the exploitation of additional data, and by the system being able to put the payment in context.

The risk of fraudulent payments is thus better assessed, as the new 3D Secure system allows the merchant to share nearly 150 additional data that are in turn sent to the customer’s bank during the payment process. This new approach therefore eliminates the need for a strong and systematic authentication (Strong Customer Authentication – SCA *), the latter being performed only upon decision of the issuing bank, and for the riskiest transactions.

In order to comply with the Payment Services Directive 2 (DSP2), a payment subjected to strong authentication must incorporate at least two of the following authenticating factors:

  • the knowledge of a particular information by the user
    (e.g. password, secret question, secret code, identification number, diagram…)
  • an object in the user’s possession
    (e.g. mobile phone, connected device, token, smart card, badge)
  • personal characteristic information about the user himself
    (e.g. fingerprint, facial recognition, speech recognition, iris recognition…)

Authentication methods will be subject to gradual changes that will be accompanied over time so as not to deteriorate consumer habits.

How does 3DS 2.0 work?

When paying online, whether via a browser or a smartphone, the cardholder’s bank will conduct a risk assessment based on the contextual analysis of nearly 150 data made available via:

  • the phone itself (in the case of a mobile payment)
  • the browser
  • the market risk

This operation takes place in the background and does not disrupt the payment process, even though the data is sent during the transaction.

More precisely, here is the data that is exchanged and analyzed:

1. For payments made on a smartphone

One or many of the 12 elements common to all mobile platforms, such as:

  • the type of platform used, along with the IP address of the carrier
  • the name and model of the device and the screen resolution
  • the operating system (also includes OS version)
  • the time zone and the location of the device

2. For payments made from a browser

The data that are gathered from the customer’s browser is, in some cases, similar to the data gathered from a smartphone (see above).

The data are divided into 9 categories:

  • Accept Headers: indicates the type of content (MIME) that the browser is able to understand.
  • IP Address: the IP address of the PC on which the browser is running.
  • Java Enabled: indicates if the browser is Java-enabled.
  • Language: indicates the language used by the cardholder’s browser.
  • Screen Color Depth: indicates the depth of the color palette used to display images on the screen.
  • Screen Height: indicates the total height of the cardholder’s screen in pixels.
  • Screen Width: shows the total width of the cardholder’s screen in pixels.
  • Time Zone: shows the time difference between UTC and the local time of the cardholder.
  • User-Agent: specifies the exact content of the HTTP User-agent header.

3. For the merchant risk analysis

In order to improve the accuracy of risk-based authentication, the bank has the ability to collect and use additional information about cardholders, which is provided by the merchant. Although these additional data are not mandatory, they are strongly recommended.

  • The “customer account”:
    Pertains to customer data held by the merchant as part of a registered account. This includes basic information such as the age of the account, the dates of any changes to the account, the delivery address, and the frequency of transactions, including successful and discontinued transactions.
  • Purchases:
    Refers to the customer’s buying habits, whether the goods or services purchased were previously ordered (new item order indicator), if the order is shipped or not (shipping indicator), and whether the order is purchased in upstream (pre-purchase order indicator).
  • Authentication of past transactions:
    Pertains to possible friction during transactions, such as if the cardholder has previously been confronted with an authentication request. Additional information may include the date and time of previous authentication attempts.
  • Cardholder Merchant Account Authentication:
    Refers to the customer login on the merchant account, and to whether the transaction took place on a browser or via a mobile application. Optional information could include credentials relating to the issuer and third-party authentication (e.g. Google). If the existing information is not available to the cardholder, the data is set to Guest mode.

The overall objective is to enrich the transaction process with a maximum of contextual data in order to provide all possible guarantees to the issuer and avoid a strong authentication request.

Deployment Schedule Forecast

1. Europe

Two dates are planned:

  • April 2019: transfer of responsibility related to the new directive. In other words, if a merchant is able to apply the new strong authentication protocol and the bank is not able to accept it, then the merchant benefits from an automatic transfer of liability.
  • September 2019: general enforcement of the directive on strong client authentication. More specifically, all European companies are to have implemented and apply the 3D Secure 2.0 protocol.

2. Canada, LAC (Latin America and the Caribbean), & US

  • Deployment: August 2019

3. CEMEA (Central Europe, Middle East and Africa)

  • Deployment: April 2020
  • By the end of 2020, the 3D Secure 2.0 protocol will therefore be implemented on a global scale.

Transfer of liability

  • 3D Secure 2.0 rules:
    The transaction is fully authenticated with 3D Secure 2.0.
  • Legal responsibility :
    The issuer is responsible for the fraud.

  • 3D Secure 2.0 rules:
    The Merchant is compliant with 3D Secure 2.0, the issuer does not meet the 3D Secure 2.0 metrics.
    An attempt to authenticate 3D Secure 2.0 has been initiated.
  • Legal responsibility:
    The issuer is responsible for the fraud.

  • 3D Secure 2.0 rules:
    The Merchant is fully compliant with 3D Secure 2.0. The transmitter is also in compliance with 3D Secure 2.0.
    The transaction is not authenticated because of a dispute.
  • Legal responsibility:
    The Merchant is responsible for the fraud.

  • 3D Secure 2.0 rules:
    The Merchant satisfies the rules of 3D Secure 1.0 but not those of 3D Secure 2.0.
    A transaction is downgraded to 3D Secure 1.0, which results in full authentication of the cardholder.
  • Legal responsibility:
    The issuer is responsible for the fraud. Note, however, that 3D Secure 1.0 may not be compatible with DSP2 (Strong Client Authentication), which could result in a slight setback during authorization.
  • DSP2 conditions:
    Strong authentication not applied.
    No exemption applied.
  • Legal responsibility (Visa, MasterCard):
    Refused so no authorization.

  • DSP2 conditions:
    Strong authentication applied – 3D Secure 2.0 realized.
    No exemptions.
  • Legal responsibility (Visa, MasterCard):
    The issuer is responsible.

  • DSP2 conditions:
    Strong authentication applied – The transmitter does not support 3DS 2.0.
    No exemptions.
    AAV / CAVV attempts are returned to the acquirer.
  • Legal responsibility (Visa, MasterCard):
    The issuer is responsible.

  • DSP2 conditions:
    The merchant requested a strong authorization exemption via the authentication procedure.
    Exemption accepted by the issuer.
    No friction.
  • Legal responsibility (Visa, MasterCard):
    The merchant is responsible.

  • DSP2 conditions:
    The merchant has requested a strong authorization exemption via an authorization procedure.
    Without friction.
  • Legal responsibility (Visa, MasterCard):
    The merchant is responsible.

  • DSP2 conditions:
    Strong authentication applied by the acquirer.
    The issuer examines the authentication and chooses to apply an exemption.
    Without friction.
  • Legal responsibility (Visa, MasterCard):
    The issuer is responsible.

  • DSP2 conditions:
    Refusal by the issuer of the strong authentication exemption.
  • Legal responsibility (Visa, MasterCard):
    The issuer is responsible.

Possible exemptions

Exemptions of strong authentications are nevertheless foreseen. Examples of the following exemptions include:

1. For payments of less than 30 euros

If a payment is less than 30 euros, an exemption is applied because it is considered a low value transaction.
However, in excess of 5 cumulated exempt transactions, or if the sum of the transactions exceeds 100 euros per day, the strong authentication of the customer may be required.

2. For low risk merchants

As a payment method provider, CentralPay is authorized to perform a real-time risk analysis. It is therefore allowed, if necessary, to impose a strong authentication the client during a transaction.

CentralPay’s fraud rate analysis takes into account behavior, expenses, history of purchase scenarios, customer location and business.

The low-risk exemption applies if the fraud rate thresholds for the amounts indicated are not exceeded.

Fraud rate and amounts:

  • Fraud rate of 0.13% for transactions up to 100 euros
  • Fraud rate of 0.06% for transactions up to 250 euros
  • Fraud rate of 0.01% for transactions up to 500 euros

3. For recurring payments (subscriptions)

In the case of recurring payments, the exemption applies in the following cases:

  • 1st highly authenticated transaction.
  • Subsequent transactions without authentication if they are in the same amount and from the same merchant.
  • Transactions initiated by the merchant as a result from an explicit agreement (a mandate) established between the merchant and the customer regarding the frequency of transactions. It should be noted that this covers recurring transactions. In this scenario, strong authentication is only required when setting the mandate.

4. For trusted beneficiaries, merchants listed on white list

The customer can whitelist traders whom he trusts. Merchants thus authenticated as “trusted beneficiaries” are added to a list which is updated by the customer’s bank. It should be noted that the strong authentication of the client is necessary during the first transaction but not for the following ones. It is also necessary during the creation, confirmation and modification of the whitelist. Using the client’s last strong authentication as a reference, whitelisting, which applies to card payments and bank transfers, allows for greater flexibility with respect to amounts, number of transactions, and payment period.

5. For payments by business card

This exemption covers transactions made by virtual card numbers or business cards used to manage employee travel expenses with online travel agents.

Only the bank of the cardholder is authorized by the regulations in effect to request this exemption, as neither the company nor the payment method provider can identify the ownership of the card.

6. For MOTO transactions

Mail Orders & Telephone Orders (MOTO) transactions do not fall into the category of electronic payments. They are therefore exempted from a strong authentication procedure of the client.

7. For transactions outside Europe

The transaction is exempt if the issuer or acquirer of a transaction is not located in Europe. Once the DSP2 guidelines are implemented, transactions from non-European buyers are likely to be accepted.

Implications for Sellers

CentralPay has integrated all the necessary steps into its processes in order to enable you to take advantage of this new version of 3DS: a more secure, improved payment experience.

Our services are thus 100% compatible with the DSP2 and the 3D SECURE 2.0.

Contact us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text.

Start typing and press Enter to search