PSD2 SCA compliance and implementation guide

Get ready for PSD2 and Strong Customer Authentication

 

In this page we provide you information about how to prepare for PSD2 SCA compliance and make the adjustments to your integration towards Netaxept. We recommend you to check this page frequently since new sections and topics will be added frequently. Please refer to the changelog below for detailed changes. Please note that the information here should not be taken as a legal advice. If you have any further questions, please contact your acquirer or Netaxept Customer Support for your country >

The following topics are covered in this guide:

- Changelog
- PSD2 and SCA overview
- Consequences of not being compliant
- 3D Secure for SCA compliance
   Benefits of 3D Secure version 2
   Liability shift rules
- SCA out-of-scope transactions
- SCA exemptions
- Actions you as a merchant need to take
   1. Activate 3D Secure into your webshop
   2. Optimize your payment flow to comply with SCA
- SCA requirements based on business models
- Questions and answers

Read also about our tokenization services > and Nets PSD2 SCA overview >

Changelog

The following list contains a summary of the changes made to this page content.

  • 3.11.2020: Page reconstructed and updated with more information about 3D Secure, SCA out-of-scope transactions and exemptions. Added detailed instructions what you as a merchant need to take to comply with SCA and the parameters you can utilize per business model. Also, added Questions & Answers section.
  • 12.11.2020: If you are non-callcentre merchant and have saved card details for recurring payments and/or other merchant initiated transactions (MIT), we recommend you to use serviceType="A" instead of "C" in subsequent transactions. This site has been now updated to reflect this recommendation: 1) serviceType="C" for native app merchants is removed from the section "Implementing 3D Secure version 2 to your existing Netaxept integration", 2) serviceType="A" is added for subsequent recurring transactions alongside the existing "C" option in section "SCA requirements based on business models", 3) description of serviceType="A" is updated in section "SCA requirements based on business models".
  • 18.11.2020: Reconstructed and added information to 3D Secure related chapters. Corrected the answer to question 8.
  • 23.11.2020: If you save card details for recurring payments and/or other merchant initiated transactions (MIT), we recommend you to use force3DSecure="true" in initial transaction to make sure Issuer doesn't apply exemption and thus leave your initial transaction without SCA. The sections "New SCA related parameters" and "SCA requirements based on business models" have been now updated to reflect this recommendation.
  • 25.11.2020: Revised 3D Secure version 2.1 go-live to be in late Q4/2020 or early January 2021. Added question 23 to cover summary of required actions for 3D Secure (any version) readiness. Updated the supported values for scaExemption in section "New SCA related parameters".

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.

SCA rules became effective on the 14th of September 2019, however, an extended deadline has been given for online transactions. The new dates for full compliance vary by country, however, for all Nets countries, we have the same deadline, and merchants need to be PSD2 SCA compliant by the 31st of December 2020.

Consequences of not being compliant

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. However, it should be noted that the card Issuers hold the ultimate responsibility for SCA and thus decide if the exemption is granted or not. So, even if a transaction qualifies for an exemption, the consumer might still have to go through SCA if the card Issuer requires it. Also be aware that you may need to get a permission from your acquirer before using certain exemption. 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.

Actions you as a merchant need to take

To be prepared for PSD2 SCA compliance 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.
  • 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.
  • 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.

1. Activate 3D Secure into your webshop

We strongly recommend that you implement 3D Secure version 1 for your online business as soon as possible regarding both browser sales channels and mobile applications, if not already done. Currently, 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. 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).

Implementing 3D Secure version 2 to your existing Netaxept integration

We are in a process of finalisizing 3D Secure version 2.1 integration towards all major card schemes and running a live pilot with selected merchants. Full go-live in Netaxept with version 2.1 is expected to be in late Q4/2020 or early January 2021. Version 2.2 is expected to be supported in Netaxept in late Q1/2021. Once 3D Secure version 2.1 is available in Netaxept, Nets will automatically activate the new version for merchants who already have the 3D Secure version 1 activated. Similar to a 3D Secure version 1 flow, Netaxept will redirect the consumer from the terminal to the 3D Secure version 2 authentication to complete the authentication flow.

In the table below we describe in detail how 3D Secure version 2 is handled across different integrations and whether the implementation requires any action from you as a merchant.

Your existing Netaxept integration What you need to do to support 3D Secure version 2

Netaxept API with existing 3D Secure version 1 integration.

Nets hosted payment window (serviceType="B").

Do nothing. 3D Secure version 2 will be supported through a redirect.

If you want to promote more frictionless user experience for consumers, add optional customer information parameters to the Register call. See the parameters below.

Netaxept API with existing 3D Secure version 1 integration.

Merchant-hosted payment window (serviceType="M").

Do nothing. 3D Secure version 2 will be supported through a redirect.

Note that Netaxept will not immediately forward the consumer to the authentication page. There is a preceding step called "3DS Method" where Netaxept will let ACS (Access Control Server) to collect the browser cookies using hidden iFrame. These cookies might be enough for ACS to skip SCA, when no authentication page will be displayed and Netaxept will return the consumer back to your website.

If you want to promote more frictionless user experience for consumers, add optional customer information parameters to the Register call. See the parameters below.

Merchant using the Nets in-app SDK.

Do nothing. 3D Secure version 2 will be supported in iOS and Android SDKs through a redirect.

SDK allows your app to load a framed webview of the authentication page, as defined by each card Issuer.

If you want to promote more frictionless user experience for consumers, add optional customer information parameters to the Register call. See the parameters below.

Support for a specific native in-app 3D Secure version 2 will be introduced during 2021.

Netaxept API with existing 3D Secure version 1 integration.

Native mobile application.

Do nothing, unless you save card details to process subsequent transactions. 3D Secure version 2 will be supported through a redirect.

If you save card details to process subsequent transactions, you can either use 1) serviceType="M" which utilizes BRW channel and opens an authentication window in webview or 2) serviceType="A" which requires a certified EMV 3DS SDK software.

If you want to provide more frictionless user experience for a native app consumers by utilizing an app channel, you may consider buying a certified EMV 3DS SDK software which allows you to use app channel.

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.

Soft decline

Soft decline means that authorization is rejected, but it would been approved if proof of SCA is provided. You can receive soft decline error code "1A" in the Process response and it indicates that 3D Secure (or equivalent) authentication is required for the transaction. 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 even after SCA with a challenge flow where the consumer is asked to provide additional input to authenticate the payment. Many of the current 3D Secure version 2 authentications are based on 3D Secure version 1 authentication pages, so ACS may perform a risk-based assessment using a challenge flow and just show a progress bar.

We are in a process of implementing soft decline support towards all our acquiring connections. Soft decline is expected to be supported in Netaxept by the end of 2020. As an interim solution, you may need to adjust your payment flow so that you are able to perform 3D Secure (or equivalent) authentication for the transaction that has been soft declined.

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.

Important information
The use of MIT flagging, SCA exemptions and soft decline 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. We in Netaxept are in a process of integrating the different capabilities and verifying the end-to-end readiness towards all our supported acquiring connections.

With the information published in this page you can familiarize yourself with the SCA requirements and new parameters and prepare your integration to comply with PSD2 SCA. However, since the readiness vary swiftly, we highly recommend that, unless otherwise stated below, before starting to use any of the below mentioned parameters or new values in production, consult Netaxept Customer Support for your country to ensure the full end-to-end readiness.
  • 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. This is supported towards all our acquiring connections.

  • 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. This is supported towards all our acquiring connections.
  • 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. The new value "M" is not yet supported towards all our acquiring connections.

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. Not all these values are yet supported towards all our acquiring connections.

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. This isn't yet supported towards all our acquiring connections.

1 = Low value transaction

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.

Business model and scenario SCA requirements Required parameters
One-time online payment

Consumer enters card details in the checkout and pays the purchase.

Card details are not saved.

SCA required on every transaction.

Ensure 3D Secure (or equivalent) is activated for your business.

Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

 
Easy payment: Card details saved for faster checkout next time

Initial transaction: Consumer saves card details for faster checkout next time.

The first transaction can be either card registration only (account verification with zero-value) or the actual purchase.

SCA required.

Ensure 3D Secure (or equivalent) is activated for your business.

Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

1. Call REGISTER with

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

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

3. Call PROCESS with
- operation="VERIFY" // account verification
OR
- operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

Subsequent transaction: Returning consumer pays with saved card with or without CVV/CVC security code.

SCA required.

Ensure 3D Secure (or equivalent) is activated for your business.

To get consumer redirected to SCA, send recurringUse3DS="true" in the Register call in each subsequent transaction, and perform the Terminal call after the successful Register call.

For CVV/CVC entry, send serviceType="B" or "M".

1. Call REGISTER with
- recurringUse3DS="true" // redirection to SCA
- recurringType="S" // Easy payment
- panHash=[stored token]
- serviceType="B" // terminal displayed for CVV/CVC entry
OR
- serviceType="M" // terminal bypassed, no CVV/CVC entry

2. Call TERMINAL to get SCA triggered.

3. Call PROCESS with
- operation="AUTH" and "CAPTURE" or "SALE"

Recurring payment: Card details saved for subscription payments done with same amount and frequency

(Note! Both amount and time interval are fixed and won't change over time)

Initial transaction: Consumer saves card details to sign up for subscription payments.

The first transaction can be either card registration only (account verification with zero-value) or the actual purchase.

SCA required.

Ensure 3D Secure (or equivalent) is activated for your business.

Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

To make sure Issuer doesn't apply exemption and thus leave your initial transaction without SCA, send force3DSecure="true" in the Register call.

1. Call REGISTER with

- force3DSecure="true" // SCA required to complete transaction
- updateStoredPaymentInfo="true" // card registration (if omitted, the actual purchase is made)
- recurringType="R" // card details saved for Recurring payment
- recurringFrequency="X"
- recurringExpiryDate="YYYYMMDD"

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

3. Call PROCESS with
- operation="VERIFY" // account verification
OR
- operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

Merchant charges saved card with the same amount and time frequency according to the agreement made with the consumer.

SCA not required.

To get SCA bypassed, send recurringType="R" and serviceType="A" or "C" in the Register call in each subsequent transaction, skip the Terminal call and continue with the Process call after the successful Register call.

1. Call REGISTER with
- recurringType="R" // Recurring payment
- panHash=[stored token]
- serviceType="C" // terminal bypassed
OR
- serviceType="A" // terminal bypassed, required for app payments, but recommended to be used also for other non-callcentre payments


2. Call PROCESS with
- operation="AUTH" and "CAPTURE" or "SALE"

Merchant initiated transaction (excl. recurring payment): Card details saved for future payments done with changing amount and/or frequency

(Note! Either amount or time interval, or both change over time)

Initial transaction: Consumer saves card details for later charges initiated by merchant.

The first transaction can be either card registration only (account verification with zero-value) or the actual purchase.

SCA required.

Ensure 3D Secure (or equivalent) is activated for your business.

Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

To make sure Issuer doesn't apply exemption and thus leave your initial transaction without SCA, send force3DSecure="true" in the Register call.

1. Call REGISTER with

- force3DSecure="true" // SCA required to complete transaction
- updateStoredPaymentInfo="true" // card registration (if omitted, the actual purchase is made)
- recurringType="S" // card details saved for MIT transactions
OR
- recurringType="R" // use this only if you have an existing recurring solution and you are in a process of changing it to PSD2 compliant

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

3. Call PROCESS with
- operation="VERIFY" // account verification
OR
- operation="AUTH" and "CAPTURE" or "SALE" // actual purchase

4. Call QUERY to fetch token / panHash.

 

Subsequent transaction: Merchant charges saved card with the changing amount and/or time frequency according to agreement made with the consumer.

SCA not required.

To get SCA bypassed, send recurringType="M", recurringTransactionType with the valid value and serviceType="A" or "C" in the Register call in each subsequent transaction, skip the Terminal call and continue with the Process call after the successful Register call.

1. Call REGISTER with
- recurringType="M" // MIT transaction
- recurringTransactionType="1/2/3" // COF / Delayed charge / No-show
- panHash=[stored token]
- serviceType="C" // terminal bypassed
OR
- serviceType="A" // terminal bypassed, required for app payments, but recommended to be used also for other non-callcentre payments

2. Call PROCESS with
- operation="AUTH" and "CAPTURE" or "SALE"
Payment through call centre

Consumer calls to the merchant and gives card details via phone. Merchant representative initiates the transaction.

SCA not required.

Call centre transactions (MOTO) are out of scope of SCA.

Payments created through Netaxept Admin's call center page are automatically marked as MOTO and SCA is bypassed. Transactions are passed directly to authorization after merchant representative has entered card details.

 

Questions and answers

Below you will find some of the frequently asked questions about PSD2 SCA compliance at Netaxept. If you can't find what you are looking for, feel free to reach out to Netaxept customer support for your country >

The following questions are answered below:

1. Why are my transactions being declined post SCA deadline?
2. What is in and out of scope of SCA?
3. What is the difference between CIT and MIT?
4. Do all CIT and MIT need to go through SCA?
5. Are transactions where card details are saved in-scope of SCA?
6. Can I avoid using SCA on subsequent transaction by flagging it as MIT?
7. I use recurringType="R", do I need to make changes to be PSD2 compliant?
8. Can I change the amount or time interval if I use "Recurring"?
9. Do I need to re-enrol the tokenized cards post SCA deadline?
10. Can I use saved card details for different purposes?
11. Can I migrate my tokenization subscriptions to / from Netaxept?
12. Can I sign up for recurring payments at the payment terminal in-store?
13. I receive hotel bookings from OTAs. How to avoid declines post SCA deadline?
14. Does Netaxept auto-flag my transactions based on SCA rules?
15. Can I request several exemptions to one transaction?
16. Can I request exemption to out-of-scope transaction?
17. What does 3DS fallback mean?
18. I ask for passcode in-app on each subsequent payment, do I need to make changes to be PSD2 compliant?
19. Are iFrames supported in 3D Secure version 2?
20. Can I test 3D Secure version 2 in Netaxept test environment?
21. Can I use 3D Secure version 1 until version 2.2 is supported in Netaxept?
22. For which schemes does Netaxept support SCA?
23. I don’t use 3D Secure currently, what actions I need to take to be PSD2 compliant?

1. Why are my transactions being declined post SCA deadline?

There are several reasons why a transaction may be declined, however, you may see a rise in declines for example due to following reasons:

  • Reason for decline: Transaction is unauthenticated when it should be.
  • What to do: Transactions without SCA are likely to be declined by card Issuers if those are in-scope of SCA. Activate and use 3D Secure (or equivalent) for these transactions.
  • Reason for decline: Transaction is incorrectly flagged.
  • What to do: Ensure you pass the correct parameters to Netaxept. If you process recurring transactions, ensure your transactions are compliant with the revised definition of recurring payments: Recurring is permitted only if subsequent transactions are made on the regular intervals with the same amount. Merchant initiated subsequent payments done with non-fixed time intervals, should not be flagged as "Recurring".

2. What is in and out of scope of SCA?

As a general rule, SCA is required for online transactions initiated by the customer. It covers all online payments including card, account-to-account (A2A) and mobile wallets. SCA is not required for orders placed through call centre (MOTO) and for transactions initiated by the merchant (MIT).

3. What is the difference between CIT and MIT?

Customer initiated transaction (CIT) is a transaction where consumer plays an active role in the initiation of the transaction. For example: One-time online payment and Easy payment.

Merchant initiated transaction (MIT) is a transaction where consumer plays no active role. Instead, the MIT is initiated by the merchant by using saved card details based on the agreement done between the consumer and merchant. For example: Recurring Payment, Unscheduled card-on-file (UCOF), Delayed charge and No-show. MITs have the following key characteristics:

  • Based on a mandate/agreement between merchant and consumer for the delivery of goods/services over time.
  • Payment is based on the mandate and is in a sequence/chain of requested payments from the merchant.
  • The transaction initiated by the merchant do not need to be preceded by a specific action of the consumer.
  • The mandate must be signed using SCA (the initial transaction of MIT), thereafter no SCA is required.

4. Do all CIT and MIT need to go through SCA?

No. Customer initiated transactions (CIT) are required to go through SCA unless they can be exempted. However, merchant initiated transactions (MIT) are out of scope of SCA, except the initial transaction of MIT, i.e. when the consumer registers their card and creates a mandate for ongoing payments, which is in-scope of SCA and needs to go through SCA.

5. Are transactions where card details are saved in-scope of SCA?

Not always. The fact that card details are saved makes no difference to the classification of the transaction, i.e. if it is a customer initiated or merchant initiated. As a general rule, customer initiated transactions (CIT) need to go through SCA unless they can be exempted, whereas merchant initiated transactions (MIT) are out of scope so SCA can be bypassed (except the initial transaction of MIT).

6. Can I avoid using SCA on subsequent transaction by flagging it as MIT?

No. You are not allowed to circumvent the SCA rules by flagging your transactions as MIT if these are clearly customer initiated (CIT) and thus in-scope of SCA. Card Issuers will scrutinise 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.

7. I use recurringType="R", do I need to make changes to be PSD2 compliant?

You may need to make changes into your integration towards Netaxept. recurringType="R" refers to recurring payment and the key things to ensure are:

  • Ensure that you have activated 3D Secure (or equivalent) authentication to your online business and the initial transaction, i.e. when the consumer registers their card and creates a mandate for recurring payments, goes through SCA.
  • Ensure that your transactions are compliant with the latest definition of recurring payment: Recurring is permitted only if subsequent transactions are made on the regular intervals with the same amount. Merchant initiated subsequent payments done with non-fixed time intervals, should not be flagged as "Recurring". Instead, check if other MIT types are applicable for your transactions, such as unscheduled card-on-file (UCOF). If you have an existing tokenization solution where card details are saved with recurringType="R", and you are in a process of flagging these as other MIT to comply with PSD2, the initial transaction can remain "R" but the subsequent transactions need to be flagged as "M" and applicable MIT type needs to be indicated in recurringTransactionType parameter.

8. Can I change the amount or time interval if I use "Recurring"?

No. If you use recurringType="R" in your subsequent payments, the purchase amount and time interval need to remain the same. Only the initial transaction amount can be different than the subsequent one.

If you run recurring payments and wish to make an uplift in your regular pricing, for example when increasing the monthly price or if the consumer changes the service, you need to sign a new agreement with the consumer, ask them to enter their card details again and redirect them to 3D Secure (or equivalent) authentication for SCA.

9. Do I need to re-enrol the tokenized cards post SCA deadline?

Existing agreements set up before the 14th of September 2019 will not require SCA, so you don't need to re-enrol the cards / re-authenticate your recurring agreements. 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. When you use Netaxept, transferring and storing of these identifiers are handled by Nets on behalf of you, so no actions are required on your side regarding this.

10. Can I use saved card details for different purposes?

Yes. You can use saved card details (the same panHash) for several purposes. For example, you can charge your customers the same amount on a regular basis (merchant initiated transaction, MIT Recurring) and your customers can make additional purchases (customer initiated transaction, CIT) with saved card details.

Ensure you flag your transactions correctly as CIT or MIT on per transaction level and pass the relevant parameters to Netaxept. Depending on the combination you want to use, flag the initial transactions as recurringType="S" or "R".

11. Can I migrate my tokenization subscriptions to / from Netaxept?

Yes. If you are moving to Netaxept from a competitor or moving to a competitor, an order for subsequent payments to work, also the transaction identifiers (Trace ID for Mastercard and Transaction ID / TID for Visa) need to be imported / exported together with the card details. Contact Netaxept Customer Support for your country > for more instructions of the process.

12. Can I sign up for recurring payments at the payment terminal in-store?

Yes. Visa and Mastercard have confirmed that recurring payment can be set up at the payment terminal. Usual MIT requirements apply, but there is no issue with the MIT agreement being started at the payment terminal in-store.

13. I receive hotel bookings from OTAs. How to avoid declines post SCA deadline?

Ensure that all Online Travel Agents (OTAs) you are partnered with perform SCA whenever collecting card details on your behalf. Transactions should be correctly flagged as either MIT or call centre (MOTO) when applicable. If you currently process these transactions as MOTO, we recommend keeping the current solution until an alternative is in place.

14. Does Netaxept auto-flag my transactions based on SCA rules?

No. Netaxept doesn't auto-flag any of your transactions as CIT or MIT. Also , we don't automatically apply any SCA exemption for your transactions. You as a merchant can decide this on per transaction level by passing the relevant parameters to Netaxept to get SCA triggered or bypassed for the relevant part of the payment flow. However, note that your acquirer may do certain auto-flagging on your behalf.

15. Can I request several exemptions to one transaction?

No. Only one exemption can be requested per transaction.

16. Can I request exemption to out-of-scope transaction?

In most scenarios, it is not feasible. The transaction can be either exempted or out-of-scope, but not both.

17. What does 3DS fallback mean?

In cases when 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), for example status "A" (Attempted authentication, such as ACS maintenance work or SMS service provider unavailability), 3D Secure version 1 is tried to use. This rerouting from version 2 to version 1 is called 3DS fallback.

18. I ask for passcode in app on each subsequent payment. Do I need to make changes to be PSD2 compliant?

If you ask for a passcode in app (knowledge), then app itself provides a second factor (possession) assuming app was securely linked to the device previously (for example with SMS). In that case you can apply for a Delegated authentication exemption to bypass SCA.

Note that the transaction can be soft declined if the exemption is not approved by the card Issuer, so you need to implement the soft decline scenario if you plan to use Delegated authentication exemption.

19. Are iFrames supported in 3D Secure version 2?

Yes. However, we still suggest you to avoid frames including iFrames and encourage you to use our terminal design templates.

The main challenge with iFrames is that password-based ACS servers using 3D Secure version 1 will not work in a frame because of click-jack attack protection. 3D Secure version 2 supports iFrames as part of the protocol, however, it also supports static passwords. Besides, in case of 3DS fallback, authentication will be done through 3D Secure version 1 and then frame solution doesn't work properly.

20. Can I test 3D Secure version 2 in Netaxept test environment?

We are working on setting up a simulator which makes it possible for you to test 3D Secure version 2 in Netaxept test environment. More information coming soon.

21. Can I use 3D Secure version 1 until version 2.2 is supported in Netaxept?

No. When 3D Secure version 2 (any version) is available at Netaxept, Nets will activate the new version for merchants who already have the 3D Secure version 1 implementation in place. New certifications for 3D Secure version 1 are already discontinued by the card schemes so it will be slowly abandoned.

22. For which schemes does Netaxept support SCA?

3D Secure (or equivalent) authentication at Netaxept is supported for Visa, Mastercard and Maestro, American Express, Discover, Dankort and Danish Consumer Card. The exact version number supported differs per card scheme, however, we always aim to support the latest available versions.

23. I don’t use 3D Secure currently, what actions I need to take to be PSD2 compliant?

3D Secure version 1

  • Activation: Actions required. Activate version 1 to your eCommerce browser sales channels and mobile applications as soon as possible. Contact Netaxept Customer Support for your country for activation.
  • Implementation: Actions may be required. Make sure your payment flow redirects consumers to SCA when relevant. Read the chapter "2. Optimize your payment flow to comply with SCA" to find out if you need to make technical changes to your integration towards Netaxept.

3D Secure version 2 (any version)

  • Activation: No actions required. Nets will activate version 2 to the merchants who already have version 1 activated. The exact timeline for version 2 activation will be informed later in December 2020. If you don't have version 1 activated, no version 2 will be activated automatically for you by Nets.
  • Implementation: Actions may be required. Make sure your integration towards Netaxept supports version 2. Read the chapter "Implementing 3D Secure version 2 to your existing Netaxept integration" to find out if you need to make technical changes to your integration towards Netaxept.