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:
Authentication methods will be subject to gradual changes that will be accompanied over time so as not to deteriorate consumer habits.
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:
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:
One or many of the 12 elements common to all mobile platforms, such as:
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:
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 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.
Two dates are planned:
Exemptions of strong authentications are nevertheless foreseen. Examples of the following exemptions include:
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.
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:
In the case of recurring payments, the exemption applies in the following cases:
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.
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.
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.
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.
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.