Skip to content
Netaxept
    Operational status

    SCA checklist

    Overview

    To comply with PSD2 SCA and ensure that your user's payment experience is not negatively impacted, check the following steps and make the needed adjustments to your payment flow and integration towards Netaxept. Each of these steps is explained in more detail below.

    • Activate 3D Secure for your webshop: Activate 3D Secure (or equivalent) authentication into your online business for both browser sales channels and mobile applications, if not already done. 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.
    • Optimize your payment flow to comply with SCA: Make sure your payment flow redirects the customer to SCA when relevant. You may need 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 let us know that 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.
    • 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.

    Activate 3D secure for 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.

    You can enhance the user experience by adding the optional customer information parameters to the Register call.

    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).

    Optimize your payment SCA compliance

    The way you need to implement SCA into your business varies based on your current payment flow and the 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 does not auto-flag any of your transactions or automatically apply any SCA exemption for your transactions.

    Note that you are not allowed to circumvent SCA 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.

    SCA related parameters

    Below you can find the parameters implemented to Netaxept to accommodate the PSD2 SCA requirements and how to use them in different business models. Check the exact specifications of these parameters in our API Reference.

    The use of these parameters requires full value chain support from your webshop via Netaxept to your acquirer and the consumer's card issuer.

    force3DSecure: If you save card details for recurring payments and/or other merchant initiated transactions (MIT) and wish to make sure the 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.

    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.

    For Wallets such as Vipps or MobilePay, Netaxept triggers 3D Secure automatically, if the card issuer has soft declined the transaction.

    For card such as Visa, Mastercard, American Express and others, 3D Secure is not automatically triggered after the card issuer's soft decline.

    Here, when you receive the soft decline error code "1A" in the Process response, you must redirect your customers back to the Payment Window by sending the Terminal call again.

    If you use serviceType="B" or "M", you can avoid the second Terminal call by ensuring the transaction is registered with autoAuth/autoSale. In that case Netaxept will start another round of 3D Secure (or equivalent) authentication while the consumer is still in the terminal phase.

    Once terminal is accessed again, Netaxept will start new 3D Secure (or equivalent) authentication insisting 3DS challenge. After this is completed, Netaxept will redirect to merchant site, and you need to send the Process call with AUTH or SALE.

    Was this helpful?

    What was your feeling about it?