Strong Customer Authentication (PSD2)

 

What is SCA?

On September 14, 2019, a new requirement for all online payments is being introduced in the EU, stating that all transactions should be verified by the buyer, only a few types of payments are exempt. The verification of payments is made by the consumer, who has to approve the payment with two-factor authentication. For example for Visa and Mastercard, that is done by using 3D Secure (3DS) authentication.

The change is part of an initiative to harmonize European payments and ensure consumers are protected. This requirement is known as SCA (Strong Customer Authentication) and is part of the EU regulation called PSD2 (Payment Service Directive 2).

 

What does SCA mean for eCommerce?

An eCommerce transaction will be defined as having gone through SCA, if at least two of the following three factors have been provided by the consumer:

  • Knowledge: Something only the user knows, e.g. a password or a PIN code.
  • Possession: Something the user has, e.g. mobile device or a token.
  • Inherence: Something the user is e.g. biometric markers such as facial recognition or fingerprints.

For Visa and Mastercard, the SCA protocol is called 3DS. In the 3DS process, the consumer is often requested to perform an action to confirm that they are making the transaction.

 

How to ensure SCA on transactions?

Please evaluate whether your transactions need SCA or not. Call Centre transactions (MOTO) are considered out of scope of SCA.

3DS authentication

If you are eCommerce merchant (not call centre), please ensure your Netaxept integration supports 3DS authentication. We generally recommend activation of 3DS well in advance of PSD2 activation date to ensure no issues are discovered when it's too late to fix them before the deadline.

Please do not wait until the new 3DS protocol is supported. EMV 3DS (3DS 2) or 3DS 1.0 does not matter unless you have a native application or similar. It will still be handled as a redirect to the Issuer's page where two-factor authentication is done (if Issuer decides to step up). Even when the new protocol is in place, some transactions will be routed to the old version if the new version is not supported by the Issuer. Due to this, native mobile applications may have to change how their app works to allow app switching to 3DS authentication, for example a Mobile Bank-ID application or Tupas authentication.

Unfortunately, testing of 3DS authentication is not possible in Netaxept test environment.

Easy payment

If you are using Easy payment (recurringType=S), please ensure that 3DS is used also on subsequent transactions. This is because Easy payment transactions are considered as cardholder-initiated transactions (CIT) where consumer plays an active role in the initiation of the transaction. CIT transactions are required to go through SCA.

To get SCA implemented on every transaction, send serviceType=B and recurringUse3DS=true along the Register call in subsequent transactions. After the successful Register call, perform the Terminal call to send the customer to the payment window.

Recurring payment

If you are using the Recurring flag (recurringType=R), the subsequent transactions are considered as merchant-initiated transactions (MIT) where the consumer plays no active role. The MIT transaction is always initiated by the merchant based on the agreement done between the customer and merchant. MIT transactions are out of scope of SCA, however, the initial transaction for the MIT transaction must always be “signed” with SCA.

When using Recurring flag, please ensure that it is compliant with the new definition of recurring payments based on the European Banking Authority's (EBA) RTS (Regulatory Technical Standards). Merchant initiated subsequent payments that don't occur on a scheduled or regularly occurring transaction date, should be flagged as "MIT unscheduled COF", instead of "Recurring". We are working on to make sure Netaxept supports the needed MIT capabilities before the deadline and shortly inform you about the changes needed.

Please note, that if the subsequent payment can be seen as preceded by a specific action of the consumer, it should be considered as CIT and not MIT transaction.

Dynamic 3DS

Please make sure Dynamic 3DS is not in use in your Netaxept implementation after the deadline.