The continuous technological evolution and the increase in the number of online transactions has made it necessary to update the authentication infrastructure in order to increase the reliability of the entire system and, at the same time, improve the customer experience and conversion rates of the shopping carts.

The collaboration between Circuits, European authorities and other players in the sector has led to the definition of the new 3D Secure 2 authentication standard.

The new protocol guarantees continuity as required by current regulations (Revised Payment Services Directive, known as PSD2), reduces the impact on merchants' systems and improves the shopping experience which is optimised on all devices.

3DS2 and the Strong Customer Authentication (SCA)

EMV 3D Secure is the optimal way to comply with the PSD2 RTS legislation.

While with the 3D Secure 1.0 each transaction passed an authentication that required an action from the buyer, the application of 3DS2 can be done in two ways: Challenge Flow or Frictionless Flow.

The PSD2 introduces the obligation for European banks to authenticate buyers within the European economic area (EEA) during the online purchase stage. When a Challenge Flow is needed, the ISSUER requires Strong Customer Authentication (SCA).

The SCA consists of an authentication with at least two of these three factors:

Knowledge: something known by the buyer (e.g. password, pin)
Possession: something owned by the buyer (e.g. smartphone, Token OTC, wearable device)
Inherence: something that distinguishes the buyer (e.g. fingerprints, facial recognition, vocal recognition)

An example of SCA is the authentication made with an OTP (one-time-password) received by the buyer on their smartphone (factor 1: possession) and the pre-determined permanent password (factor 2: knowledge).

The PSD2, therefore, requires the Strong Customer Authentication of the Buyer for remote purchases but some exemptions are applicable.

When an exemption is applied, we talk about Frictionless Flow. The more information is communicated to the ISSUER, the more the probability that the transaction enters into a frictionless flow.

In this scenario, authentication does not require buyer's involvement.

If the cards do not have 3DS2 enabled, the system requires authentication according to 3DS 1.0 standards and if the attempt fails, the transaction will skip the authentication phase by going directly to the payment authorization.

SCA exemptions and exceptions

For some types of transactions, the application of the SCA can be skipped; in these cases we speak of exceptions (out-of-scope) and exemptions.

The exceptions are transactions that are not subject to the legislation, in fact the rules defined by PSD2 are not applied to these payments.

Exceptions are considered the following:

one leg transactions : transactions where the acquirer or issuer are not within the EEA
Merchant-initiated transactions (MIT): online payments sent by the merchant without the presence of the buyer at that moment
M.O.T.O (Mail Order Telephone Order): payment orders made by the buyer by telephone, email or post, in which the merchant manually enters the card details provided.
Anonymous cards : payments made with cards identifiable only by the Issuer.

These transactions can be processed without authentication because, as mentioned above, they are not subject to PSD2.

The exemptions are divided into two categories, depending on whether they are from the Issuer or the Acquirer, and can be applied by the Issuer in these cases:

Microtransactions: low-value transactions, usually equal to or under 30€.
Transaction Risk Analysis: the Issuer carries out a risk analysis of the payment based on the information in their possession and, if the transaction is recognized as secure, they may decide to proceed with a frictionless flow (without authentication).
White listing o trusted beneficiaries: if the Issuer supports this function, they allow the buyer to choose which Ecommerce to add to the whitelist, on which they request not to authenticate transactions, as long as the SCA has been passed at least once.
Secure Corporate Payments : payments initiated by companies that adopt dedicated processes and use security protocols equivalent to those introduced by SCA.

Acquirer's exemptions are requested by the merchant after an agreement with the Acquirer.

While the exemptions described above are applied directly by the Issuer, those of the Acquirer are required in the authentication flow and the Issuer may decide not to accept them. If an exemption from the Acquirer is accepted, the responsibility for this payment passes from the Issuer to the Acquirer who will be liable in the event of fraud.

The following are the Acquirer's exemptions that may be requested:

Low value transactions: low-value transactions, usually equal to or under 30€. If the thresholds are exceeded, the exemption might be denied.
Transaction Risk Analysis: if the fraud rate of the Acquirer falls within certain thresholds, it is possible to request the exemption, which is followed by a risk analysis, carried out by the merchant or by a specific provider of choice.
Recurring transactions: these are periodic transactions attributable to the same product/service sold, and always of the same amount.

Transactions and integration types

The types of transactions described in this chapter refer to Axerve Ecommerce Solutions [transDetails.type]:

Ecommerce: these are the transactions made in the "presence" of the buyer. Card data can be saved inside a token (card on file) that will be used for future transactions. They are subject to SCA, excluding transactions that fall under the exceptions, and may be subject to exemption.
MOTO: this category includes both Mail Order and Telephone Order payments. Since these payments are out-of-scope, strong customer authentication is not enforced.
Recurring transactions: these are recurring payments for the execution of which an agreement is made between the merchant and the cardholder during the first transaction of the series
Recurring First – it is the first transaction in the recurring series and the holder must be authenticated according to the rules of the SCA. At this stage, the minimum days between one payment and another and the deadline of the last payment are also defined.
Recurring Next – are the subsequent payments. They are MIT payments and, therefore, do not require authentication.
Not programmed MIT: there are cases in which the agreement between the merchant and their customer does not define the amount and frequency of recurring payments, for example in pay-per-use business models, this type of MIT allows the merchant to request payments.
- First not programmed MIT - during the first transaction, the buyer must be authenticated with the SCA. The transaction must be authenticated and authorized immediately for the due amount.
- Next not programmed MIT - are the transactions that follow the "First" and do not require authentication.
Authentication only : it is the operation that is carried out to authenticate the buyer.

Depending on the type of interaction with the Payments Service Provider (PSP), the following operations can be carried out:

Virtual POS: all transactions made in this environment are M.O.T.O.
Payment page: are the payments in which the buyer's presence (always meant remotely) is required. Transactions can be carried out from the payment page: recurring first, unscheduled MIT first, Ecommerce and authentication only. If no type of transaction is specified, the system assigns the default Ecommerce value.
Server to Server: this type of integration allows for any type of transaction. If the type is not specified, the system assigns by default the value configured in the merchant's register for the shop login. With server to server integration it is also possible:
- To request authentication for a transaction that will be authorized later by another PSP. In this case, the transTypeReq parameter must be set to "A", and the response message will contain the information for authorization. It is also be possible to authorize the transaction through Axerve.
- To authorize a payment previously authenticated by a 3D Secure service provider threeDSAuthResult. In this case, the response collected by the provider must be sent to Axerve.

Axerve manages each transaction according to the configuration and transaction parameters of the merchant who must express a preference for each transaction regarding:

Willingness to exclude any possibility of exemption from a specific transaction and to request the mandatory SCA [exemption = "SKIP"].
The request for exemption based on the risk analysis of the transaction carried out by a third party or owner [exemption = "FORCE"].

You can find more technical information on integration to the API documentation api link and in the dedicated dedicated infographic external link .

Handling 3D Secure transactions

Exemptions