Strong Customer Authentication (PSD2)

New regulation is changing online payments in Europe

 

What is changing?

A new requirement for online payments is being introduced in the EU, stating that all online card payments need to be verified by the buyer, only a few types of payments are exempt. The requirement for verification is called Strong Customer Authentication (SCA). SCA mandate is a legal requirement and part of the EU regulatory framework PSD2 (Payment Services Directive 2). It aims to harmonize European payments and ensure consumers are protected. Officially SCA requirements came into effect on September 14, 2019.

An online 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 transactions, SCA is facilitated through 3D Secure. In the 3D Secure process, the consumer is often requested to perform an action to confirm that they are making the transaction. For American Express transactions the equivalent authentication service is known as SafeKey and for Dankort transactions it is Dankort Secured by Nets.

 

What do I need to do?

Make sure your integration towards Netaxept is PSD2 SCA compliant. The implications of not being compliant can result in transactions being declined, and a disruption to your business.

  1. Activate 3D Secure and equivalent into your business (both browser sales channels and mobile applications), if not already done. Contact Netaxept Customer Support for your country for activation.
  2. Ensure your payment flow is correctly set up and API integration supports SCA when necessary. See the most common business scenarios below.

Activate 3D Secure

We highly recommend you to activate 3D Secure and equivalent authentication services into your online business as soon as possible: both browser sales channels and mobile applications. Call centre business is out of scope and no actions are required there. Please be advised that 3D Secure and equivalent authentication cannot be tested in Netaxept's test environment, so it is recommended to execute a proper testing in production environment before going to full production with the authentication services.

For merchants using the Nets in-app SDK, the 3D Secure authentication is handled by the SDK which allows your app to load a framed webview of the 3D Secure authentication page, as defined by each card issuing bank. The SDK can also switch to third party authentication apps like Mobile Bank-ID in Sweden. This allows to avoid a redirection to an external browser and improves the user experience. However, the authentication page can then look different from one bank to another or from one mobile platform to another (iOS or Android).

We are in the process of integrating EMV 3DS version 2.1 in Netaxept. More information to come in Q1/2020.

Make sure your API integration supports SCA

The way you need to apply SCA to your business will vary based on your current payment flow and integration you have towards Netaxept. Below you can find the instructions for the most common scenarios. If SCA is required, ensure 3D Secure and equivalent authentication services are activated and used for that part of the payment flow.

In order to know whether the transaction is required to go through SCA or not, you need to identify if it is initiated by the cardholder (consumer) or the merchant:

  • Cardholder-initiated transaction (CIT) is a transaction where consumer plays an active role in the initiation of the transaction. CIT transactions are required to go through SCA.
  • Merchant-initiated transaction (MIT) is a transaction where consumer plays no active role. Instead, the MIT transaction is initiated by the merchant based on the agreement done between the customer and merchant, and as such are out of scope of SCA. When evaluating whether your transactions could be marked as MIT, please be advised that if the transaction can be seen as preceded by a specific action of the consumer, it should be considered as CIT and not MIT transaction.

If you currently process recurring payments (recurringType=R) in your business, ensure these are 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 "Unscheduled Credential on File", instead of "Recurring". We are working on to make sure Netaxept supports the needed capabilities and shortly inform you about the changes needed.

 

Business model Scenario SCA required? API integration

One-time online payment

Customer enters card details in the terminal and pays the purchase. Card details are not saved.

Yes, this is CIT.

3D Secure and equivalent need to be activated on every transaction.

Make integration according to our API guide. Netaxept redirects customer automatically to authentication after card details are entered.

Easy payment

Card details saved for faster checkout (CVV/CVC entry)

Initial: Customer saves card details for faster checkout next time. Transaction can be account verification or actual purchase.

Subsequent: Returning customer pays with saved card and enters CVV/CVC in the terminal.

Initial: Yes, this is CIT.

Subsequent: Yes, this is CIT.

3D Secure and equivalent need to be activated on every transaction.

Initial:

1. Call REGISTER with

  • updateStoredPaymentInfo="true" // card registration (if omitted, the actual purchase is made)
  • recurringType="S" // card details saved for Easy payments

2. Call TERMINAL to redirect consumer to terminal. Netaxept redirects customer automatically to SCA.

3. Call PROCESS with

  • operation="VERIFY" // account verification
  • operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

 

Subsequent:

1. Call REGISTER with

  • serviceType="B" // terminal displayed
  • recurringUse3DS="true" // redirection to SCA
  • recurringType="S" // Easy payment
  • panHash=[stored token]

2. Call TERMINAL to redirect consumer to terminal and get SCA triggered.

3. Call PROCESS with

  • operation="AUTH" and "CAPTURE" or "SALE"

Easy payment

Card details saved for faster checkout (no CVV/CVC entry, permission from acquirer required)

Initial: Customer saves card details for faster checkout next time. Transaction can be account verification or actual purchase.

Subsequent: Returning customer pays with saved card without being directed to the terminal.

Initial: Yes, this is CIT.

Subsequent: Yes, this is CIT.

3D Secure and equivalent need to be activated on every transaction.

Initial:

1. Call REGISTER with

  • updateStoredPaymentInfo="true" // card registration (if omitted, the actual purchase is made)
  • recurringType="S" // card details saved for Easy payments

2. Call TERMINAL to redirect consumer to terminal. Netaxept redirects customer automatically to SCA.

3. Call PROCESS with

  • operation="VERIFY" // account verification
  • operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

 

Subsequent:

1. Call REGISTER with

  • serviceType="M" // terminal bypassed
  • recurringUse3DS="true" // redirection to SCA
  • recurringType="S" // Easy payment
  • panHash=[stored token]

2. Call TERMINAL to get SCA triggered.

3. Call PROCESS with

  • operation="AUTH" and "CAPTURE" or "SALE"

Recurring payments

Card details saved for subscription payments done by merchant with same frequency, for example gym memberships

Initial: Customer saves card details for subsequent recurring payments. Transaction can be account verification or actual purchase.

Subsequent: Merchant charges saved card on a regular basis according to agreement made with the customer.

Initial: Yes, this is CIT.

Subsequent: No, this is MIT and out of scope of SCA.

3D Secure and equivalent need to be activated on the initial transaction, but it will be bypassed in subsequent transaction.

Recurring payment agreements set up with customers after 14th of September 2019 need SCA when the agreement/subscription is created (initial transaction).

Initial:

1. Call REGISTER with

  • updateStoredPaymentInfo="true" // card registration (if omitted, the actual purchase is made)
  • recurringType="R" // card details saved for Recurring payments
  • recurringFrequency="X"
  • recurringExpiryDate="YYYYMMDD"

2. Call TERMINAL to redirect consumer to terminal. Netaxept redirects customer automatically to SCA.

3. Call PROCESS with

  • operation="VERIFY" // account verification
  • operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

 

Subsequent:

1. Call REGISTER with

  • serviceType="C" // no terminal displayed
  • recurringType="R" // Recurring payment
  • panHash=[stored token]

2. Call PROCESS with

  • operation="AUTH" and "CAPTURE" or "SALE"

Unscheduled Credential on file

Card details saved for future payments done by merchant with non-fixed time intervals, for example auto account top-ups

1. Customer saves card details for later charges. Transaction can be account verification or actual purchase.

2. Merchant charges saved card on an irregular basis according to agreement made with the customer.

1. Yes, this is CIT.

2. No, this is MIT and out of scope of SCA.

3D Secure and equivalent need to be activated on the initial transaction, but it will be bypassed in subsequent transaction.

Instructions will be added shortly

Call centre payment

MOTO (Mail order / Telephone order)

Customer gives card details via phone and merchant representative initiates the transaction.

No. Call centre transactions are out of scope of SCA.

No API changes needed. 3D Secure is bypassed.

 

Read more about our tokenization services>

Read Nets PSD2 overview >

Contact Netaxept Customer Support for your country >