Comply with PSD2 and Strong Customer Authentication

In this page we provide you information about how to comply with PSD2 SCA in your integration towards Netaxept. Please note that the information here should not be taken as a legal advice.

PSD2 and SCA overview

The Payment Services Directive 2 (PSD2) is an EU regulation and its key objectives are to minimize fraud and make payments more secure across Europe. There are different aspects of PSD2, but the key article for merchants is called Strong Customer Authentication (SCA) – an extra level of security for transactions initiated by consumers. It means consumers are requested to provide two-factor authentication to identify themselves before they can checkout online. The two factors must be independent of each other and should be from the following categories:

• Knowledge: Something only the consumer knows, e.g. a password or a PIN code.
• Possession: Something only the consumer has, e.g. a secure token or a mobile device.
• Inherence: Something only the consumer is, e.g. a biometric fingerprint or a facial recognition.

To make sure that your transactions comply with PSD2 SCA regulations, you need to implement 3D Secure authentication. For card payments this means using 3D Secure for Visa and Mastercard payments, and the equivalent authentication method for other cards, such as SafeKey for American Express and Dankort Secured by Nets for Dankort payments.

Consequences of not being compliant

SCA rules became effective on the 14th of September 2019, and an extended deadline closed up on the 31st of December 2020.

Depending on how you manage your online payments today, the requirements on SCA can have a noticeable impact on the way you process your online payments and the payment journey your consumers will face. Whilst SCA will reduce fraud and increase security, introducing SCA may challenge the user experience and thus impact your conversion. The consequences of not being PSD2 SCA compliant can result in your transactions being declined and a disruption to your business.

SCA rules cover all online payments including card, account-to-account (A2A) and mobile wallets; the most impacted area being the card payments. The easiest way to meet SCA requirements for card payments is to use 3D Secure (or equivalent) authentication for the relevant part of the payment flow. Today, merchants have generally been able to decide on whether they wish to activate 3D Secure (or equivalent) authentication to their card transactions. However, post SCA deadline, 3D Secure (and equivalent) authentication will become required and consumers will no longer be able to make card payments online simply by typing in their card details, unless a SCA exemption applies or the transaction can be classified being out of scope of SCA.

3D Secure for SCA compliance

SCA is the method of authentication mandated by PSD2. As stated above, SCA for card payments means 3D Secure (or equivalent) authentication used as part of the payment flow. 3D Secure is an authentication protocol developed to protect consumers online through an additional security check. In practice this security check is an action required from the consumer to confirm that they are in fact making the payment. Today, it is usually in the form of using a mobile application provided by the consumer's card Issuer or SMS One Time Password (OTP) to the consumer's mobile phone containing a code that they need to type in to complete the payment. The exact form varies by country and is selected by each card Issuer. For example in Denmark it is SMS OTP or NemID, whereas in Sweden and Norway consumers use Mobile Bank ID and in Finland a bank-specific authentication. The authentication is also recognizable to consumers with the brands like Visa Secure (formerly known as Verified by Visa), Mastercard SecureCode, American Express Safekey and Dankort Secured by Nets.

Benefits of 3D Secure version 2

The version 1 of 3D Secure has been around for a long time. It was created by Visa and adopted by other card schemes to be used their equivalent authentications. The new 3D Secure version 2 (also known as EMV 3DS) is standardized across the card schemes worldwide and currently all major card schemes are moving towards it. The version 2.0 is already deprecated and replaced with version 2.1, followed by the latest version 2.2. 3D Secure version 2 has additional benefits over version 1 in terms of user experience, conversion and approval rates. Below are listed the most important improvements in 3D Secure version 2 which aim to make payments more secure and promote more frictionless user experience for consumers, which ultimately leads to higher conversion for merchants.

• More transaction and consumer data passed through to card Issuers. Some of the data is collected by 3D Secure version 2 itself, for example MCC and payer's IP address, whereas some of the data need to be provided from your webshop if you want to utilize it, for example consumer's contact information. Card Issuers will use this additional data for better decision making and performing risk-based authentication, so the consumer is asked for SCA only when needed and low-risk payments can be approved without SCA.
• Common authentication standard. This lowers abandonment rate and creates better user experience.
• Movement away from static passwords to more dynamic authentication methods.
• Compatibility with biometric authentication factors. For example the use of fingerprint.
• Support and optimisation for app-based payments with no redirect. This makes it possible to maintain the solid user experience throughout the checkout, since the SCA process can be initiated and executed inside your app without redirecting the consumer to a separate ACS page for SCA.
• Support for new payment scenarios when saving card details. With non-payment authentication (NPA) capability it will be possible for you to implement "Add Card" and "Recurring with Trial Period" type of scenarios fluently in your payment flow so that the consumer can clearly see they will not pay anything when registering their card and performing SCA.
• Support for SCA exemptions. For example to bypass SCA for low-value payments.
• Possibility to accept cards registered only to version 2 of 3D Secure. Some card Issuers have decided to add their new cards only to version 2 which in turn requires you to have version 2 enabled as well.

Note, that all above mentioned capabilities require full value chain support and are not necessary yet available for merchants. Besides that, some of the features will be supported starting from version 2.2.

Liability shift rules

The general rules for chargeback liability shifts apply no matter which version of 3D Secure you use. For example for Visa and Mastercard, you are protected from chargeback liability if the transaction is 3D Secure (any version) or equivalent authenticated. This liability protection can differ for other local and international card schemes. Transactions flagged as merchant initiated (MIT) do not have the liability protection, and the same is if you request for the SCA exemption and it is accepted by the card Issuer. However, if the exemption is applied by the card Issuer, the liability shifts to the card Issuer. Also, if you apply "Delegated authentication" to your transactions, you will carry the liability for these transactions.

SCA out-of-scope transactions

SCA rules state that all online transactions initiated by consumers require SCA, therefore there are certain types of transactions that are out of scope of SCA and thus not require to go through SCA. Out of scope transactions include:

• Phone sales (MOTO): Transactions where consumer calls to the merchant and gives their card details via phone, after which merchant representative initiates the transaction.

• Anonymous transactions: Transactions made with payment cards that are not directly linked to the individual consumer, for example transactions made with prepaid cards and gift cards.

• One-Leg-Out transactions: Cross border transactions where either the card Issuer or your acquirer is located outside the European Economic Area (EEA).

• Merchant initiated transactions (MIT): Transactions where consumer plays no active role. Instead, the transaction is initiated by the merchant by using saved card details based on the agreement made between the consumer and merchant. The most common MITs include:
  • Recurring Payment: A transaction in a series of transactions using saved card details for a fixed amount and that are processed at regular time intervals, and where the consumer has provided consent for the merchant to initiate one or more future transactions. For example TV streaming subscription with the same monthly bill.

  • Unscheduled card-on-file (UCOF): A transaction using saved card details for a fixed or variable amount and/or that are processed at regular or variable time intervals, and where the consumer has provided consent for the merchant to initiate one or more future transactions. For example a mobile phone subscription where the bill changes depending on the usage of minutes or an automatic top-up agreement for a railcard when the consumer drops below a certain stored value.

  • Delayed charge: A transaction performed to process a supplemental account charge after original services have been rendered and respective payment has been processed. For example when a hotel charges minibar expenses from the consumer after they have already paid the original bill and checked out from the hotel.

  • No-show: A transaction occurring when merchant and consumer have an agreement for a purchase, but the consumer does not meet the terms of the agreement. For example when the consumer has booked a hotel room but doesn't show up and cancel the reservation according to the hotel's cancellation policy. The hotel may then perform a no-show transaction to charge the consumer a penalty for a guaranteed reservation.

Note that the initial transaction of MIT, i.e. when the consumer registers their card and creates a mandate for ongoing payments, is in-scope of SCA and needs to go through SCA. Also be aware that MITs will be scrutinised for misuse and only merchants whose business require to flag their transactions as MIT are entitled to use it.

SCA exemptions

Whilst PSD2 sets rules on when SCA is required, it has also defined cases where exemptions can be applied to the transactions that fall into the scope of SCA. The most common exemptions include:

• Low value transactions: Transactions under 30 EUR. However, note that the card Issuers keep track on certain counters; SCA must be applied again after 100 EUR of cumulative spending or on every 5 low-value transactions.
• Low risk transactions: Transactions where the card Issuer or your acquirer carries out a real-time Transaction Risk Analysis (TRA) and assesses a transaction to have a low risk of fraud.

• Delegated authentication (DA): Merchants can be granted the role of SCA authenticator on behalf of the card Issuer. Ideal for merchants having in-app payments. Note that DA is not an actual exemption, but just passing the authentication responsibility to the merchant and technically SCA will happen on every single transaction.

Note that the card Issuers hold the ultimate responsibility for SCA and thus decide if the exemption is granted or not. Even if a transaction qualifies for an exemption, the consumer might still have to go through SCA if the card Issuer requires it. In case you request an exemption, ensure you have implemented the soft decline functionality to get the consumer redirected to 3D Secure (or equivalent) authentication if the card Issuer soft declines your transaction. Also note that you may need to get a permission from your acquirer before using certain exemption.

Actions you as a merchant need to take

To comply with PSD2 SCA and ensure that your payment journey is not negatively impacted, check the following steps and make the needed adjustments to your payment flow and integration towards Netaxept.

1. Activate 3D Secure into your webshop: Activate 3D Secure (or equivalent) authentication into your online business for both browser sales channels and mobile applications, if not already done. From the 1st of January 2021, card payments made online in the European Economic Area (EEA) without 3D Secure (or equivalent) are likely to be declined by card Issuers. Contact Netaxept Customer Support for your country for activation.
2. Optimize your payment flow to comply with SCA: Make sure your payment flow redirects the consumer to SCA when relevant. This may require you to make technical changes to your integration towards Netaxept.

• Customer vs. merchant initiated transactions: Identify whether your transaction are in-scope or out-of-scope, and ensure you flag them correctly and pass the relevant parameters to Netaxept to get SCA triggered for the relevant part of the payment flow.
• SCA exemptions: If you conclude certain SCA exemption would be relevant for you to reduce friction in your payment flow, ensure you pass the relevant parameters to Netaxept to get us notified you wish to bypass SCA for the transaction. Note that the SCA exemption is not guaranteed since the card Issuer ultimately decides on approvals and declines of transactions so you need to be prepared for soft decline.

3. Prepare for soft decline: If the card Issuer soft declines your transaction, ensure you have implemented the soft decline functionality to get the consumer redirected to 3D Secure (or equivalent) authentication.

1. Activate 3D Secure into your webshop

Make sure you have implemented 3D Secure (and equivalent) for your online business for both browser sales channels and mobile applications. Contact Netaxept Customer Support for your country for activation.

Call centre business is out of scope and no actions are required there. For merchants using the Nets in-app SDK, 3D Secure (and equivalent) authentication is handled by the SDK which allows your app to load a framed webview of the authentication page, as defined by each card Issuer. The SDK can also switch to third party authentication applications, like Mobile Bank-ID in Sweden and Norway. 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).

3D Secure version 2

We are currently supporting 3D Secure version 2.1 in Netaxept. In the table below we describe how 3D Secure version 2 is handled across different integrations and whether the implementation requires any action from you as a merchant. If you want to test your payment flow with 3DS authentication, you can find test cards here.

Optional customer information parameters

Compared to version 1, the version 2 of 3D Secure will collect and transmit more transaction and consumer data to card Issuers to promote more frictionless user experience for consumers, which ultimately leads to higher conversion for merchants.

Besides this, you as a merchant can also promote more frictionless user experience by passing the following optional customer information parameters to Netaxept in the Register call. This optional customer information is sent all the way from your webshop to the card Issuer to give them more confidence that the consumer is known to you. However, it should be noted that the card Issuers hold the ultimate responsibility for SCA and thus sending these parameters doesn't automatically lead to more frictionless flow.

• customerEmail - Customer.Email
• customerPhoneNumber - Customer.PhoneNumber
• customerAddress1 - Customer.Address1
• customerAddress2 - Customer.Address2
• customerPostcode - Customer.Postcode
• customerTown - Customer.Town
• customerCountry - Customer.Country

3DS fallback

Once 3D Secure version 2 is activated for you, the version 1 remains still activated for you and you will be able to utilize it when needed. In case a consumer's card is not enrolled in 3D Secure version 2 or in any other case when 3D Secure version 2 authentication could not be completed (except when authentication is failed), Netaxept tries to use 3D Secure version 1. This rerouting is called 3DS fallback.

2. Optimize your payment flow to comply with SCA

SCA is required unless the transaction is out of scope of SCA or can be exempted. The way you need to implement SCA into your business will vary based on your current payment flow and integration you have towards Netaxept. If SCA is required, ensure 3D Secure (or equivalent) authentication is activated for your business and ensure you pass the relevant parameters to Netaxept to get SCA triggered for the relevant part of the payment flow. Netaxept doesn't auto-flag any of your transactions or automatically apply any SCA exemption for your transactions.

While optimizing your payment flow to support SCA rules, note that you are not allowed to circumvent the rules by flagging your transactions as MIT if these are clearly customer initiated and thus in-scope of SCA. Card Issuers will scrutinize transactions flagged as MIT for misuse by analysing for example the merchant's category code (MCC) to make sure that only the merchants whose business require the use of MIT are entitled to use it.

Recurring agreements and SCA

If you are processing subsequent payments, you may have wondered how SCA rules affect to already started subsequent payment agreements. Here is more info about this.

So called Grandfathering principle states that all existing agreements set up before the 14th of September 2019 don't require SCA so you don't need to re-enrol the cards. However, the agreements set up with the consumers after the 14th of September 2019 should be created with an SCA when the consumer signs up for a series of transactions, i.e. when the initial transaction is executed.

According to SCA rules, the transaction identifier needs to go along all subsequent transactions to reference the previous transactions in the chain and prove that the transaction you are processing is PSD2 compliant. On subsequent transactions Netaxept will send a reference to the initial or a previous transaction as a proof that SCA has been performed. If Grandfathering principle applies, Netaxept will use an interim value as a transaction identifier.

New SCA related parameters

Below you can find the new parameters implemented to Netaxept to accommodate the PSD2 SCA requirements. Check from the API section the exact specifications of these parameters and below how to use them in different business models. The use of these parameters requires full value chain support from your webshop via Netaxept to your acquirer and the consumer's card Issuer. It is expected some time before all PSD2 SCA rules become widely implemented across the value chain so issues and changes might happen.

• force3DSecure: If you save card details for recurring payments and/or other merchant initiated transactions (MIT) and wish to make sure Issuer doesn't apply any exemption to your initial transaction and thus leave your initial transaction without SCA, use the parameter force3DSecure and the value "true" to indicate SCA is required to complete the transaction.

• recurringUse3DS: If you wish to get SCA triggered for the subsequent transaction, use the parameter recurringUse3DS and the value "true", and perform the Terminal call after the successful Register call.
• recurringType: If you wish to save card details for future transactions or are using saved card details to perform a subsequent payment on a card, use the parameter recurringType to indicate the tokenization type. Besides the existing values "S" and "R" we have introduced the new value "M" to incidate subsequent MIT transaction.

S = The meaning differs depending on whether the transaction is initial or subsequent:

Initial: Card details will be saved for future Easy payment or MIT transactions (excl. recurring payment).

Subsequent: Saved card details are used to perform subsequent Easy payment on a card. RecurringType of the initial transaction needs to be "S".

R = The meaning differs depending on whether the transaction is initial or subsequent:

Initial: Card details will be saved for future recurring payments or MIT transactions.

Subsequent: Saved card details are used to perform subsequent recurring payment on a card. RecurringType of the initial transaction needs to be "R".

M = Can be used only if the transaction is subsequent:

Subsequent: Saved card details are used to perform MIT transaction (excl. recurring payment). RecurringType of the initial transaction can be either "S" or "R".

• recurringTransactionType: If your subsequent transaction can be classified as MIT, use the parameter recurringTransactionType to indicate the MIT type. In this case the recurringType needs to be "M". Supported values are listed below.

1 = Unscheduled card-on-file (UCOF)
2 = Delayed charge
3 = No-show

• scaExemption: If you wish to apply an exemption to your SCA in-scope transaction, use the parameter scaExemption to indicate the exemption type. Supported values are listed below. Note that you may need to get a permission from your acquirer before using this exemption. Exemptions are not allowed to be used in connection with initial transactions when card details are saved for subsequent transactions.

1 = Low value transaction. The parameter should only be used for transactions equal to or below 30 EUR.

Other SCA exemptions are not currently supported. Please speak to your acquirer if you would like to utilize any of the other exemptions. It is your acquirer's legal right to decide which SCA exemptions to support.

Note that in case you request an SCA exemption, you must implement the soft decline functionality to get the consumer redirected to 3D Secure (or equivalent) authentication if the card Issuer soft declines your transaction.

3. Prepare for soft decline

Soft decline means that authorization is rejected, but it would have been approved if proof of SCA had been provided. Soft decline may happen for example if the card Issuer declines the exemption you requested, if the transaction was flagged as merchant initiated (MIT) or as call centre, or even after 3D Secure (or equivalent) authentication with a challenge flow where the consumer was not asked to provide additional input to authenticate the payment. If soft decline happens after 3D Secure version 1 authentication, no new SCA round can be initiated, because it is not possible to insist 3DS challenge in version 1.

In the table below we describe how soft decline is handled in relevant payment methods and whether the implementation requires any action from you as a merchant.

SCA requirements based on business models

Below you can find the instructions on how to comply with PSD2 SCA rules for the most common business models.