PSD2 Introduction

• Introduction
• General information on PSD2 and SCA
• 3D Secure v2 and Frictionless flow
• Stored card details
• Roll out of SCA updates
• API changes

Introduction:

On January 1st the new regulation regarding strong customer authentication (“SCA”) is taken into effect. SCA is a requirement which stems from the EU’s Second Payment Services Directive (PSD2) which entered into force in Sweden on the 13th of January 2018.

Below you can find what solutions and integrations that are a subject for change for this platform, consequently SCA.

In the menu above you can find a deep dive on key topics such as “General information on SCA”, “3DS v2.0 and Frictionless flows”, “Stored card details”, as well as a summary of the API Changes section that have been made as a result of SCA (we encourage you to look there to see how specific endpoints are changed). In above list you can also find a link to a page where we will be specified what date we will upgrade our different acquires to support the SCA requirements.

Solutions and integrations subject to change:

Stored card details:

Recurring transactions and Merchant Initiated Transactions (MIT) will be supported after “the acquirer used by you” has been updated to support the new PSD2 requirements, while Cardholder initiated transactions (CIT) with stored card details will no longer be supported. Merchants with an API integration will have to update their integration in order to continue to do Recurring transactions and MIT. To learn more about transactions with “stored card details” and what API changes that are need please click here.

Webpay:

If you use Webpay, our web terminal/MOTO solution you must ensure that you use a valid MOTO Acquiring agreement. If you don’t have a valid MOTO agreement all your transactions will be declined. Please contact support support@bambora.com if you need to double check if you have a valid MOTO agreement.

Important: The information provided here regarding SCA may change at some point, since other parties (acquirers etc.) are still working on and haven't finalized their changes yet. This can potentially affect us as a PSP and also you as a consumer of our services. We strongly encourage you to frequently check back here and refer to the Changelog for any updates.

General information PSD2 and SCA

PSD2 is the EU’s new payment service directive, a law intended to further strengthen security and innovation for payment services in the EU. Strong customer authentication (SCA) is a requirement that steams from PSD2 and enforces customers to verify their identity before carrying out an electronic transaction.

With strong customer authentication (SCA) becoming a requirement, online payments will go through 3D Secure, which is the solution the major card schemes´ uses to accommodate this requirement. Local card schemes might have their own solution, like “Secured by Nets” which is used for the Danish Dankort, but the general customer experience will be similar no matter the card scheme and solution. During payment, the customer will be redirected to the issuer's authentication solution, which could be a SMS code, BankID or similar authentication challenge.

PSD2 recognizes that not all online payments carry the same risk factor and for some use cases, SCA requirement is simply not possible because the cardholder will never be present for authentication. Because of this, some payments are considered to be out of scope and certain exemptions to SCA have also been made available.

Out of Scope

If a payment is considered to be out of scope, there are no requirement for SCA. Currently, there are three different transaction types that are out of scope.

• Merchant Initiated Transaction: Merchant Initiated Transactions (MIT) are a type of transaction where the merchant performs a payment with stored card details when the cardholder is not present and cannot carry out SCA. Please refer to the stored card details section further reading.
• MOTO Mail Order/Telephone Order (MOTO) transactions allow merchants to receive card details from cardholders by mail, telephone or letter and handle the payment on the cardholders behalf.
• One-leg PSD2 only applies to transaction in the European Union and European Economic Area. Unless both the issuer and acquirer are based in EU/EEA, the payment is considered to be one-legged, and there is no SCA requirement by PSD2. No action is required by you, and we will automatically detect one-legged payments and handle them according to the general security requirements in your agreement with us and the acquirer.

Exemptions

PSD2 allows for exemptions from SCA in some specific cases. However, today it is only the exemption flagging for recurring payments that is supported on this platform. See the stored card details section for further details. Other Bambora articles on PSD2 and SCA

• PSD2 article - general PSD2 information

• PSD2 interactive guide - discover PSD2 and how it affects you through an interactive guide

3D Secure v2 and Frictionless flow

3D Secure 1.0 (3DSv1) has been around for many years and is already supported by our platform. Recently, major card schemes have developed 3D Secure v2 (3DSv2) which is a more secure and future proof SCA solution compared to 3DSv1. Issuers are not required to support 3DSv2 for January 1st, 2020 since 3DSv1 is sufficient to meet SCA requirement of PSD2. However, we expect that many issuers will move to 3DSv2 during the near future since it offers better security and user experience to cardholders.

The advantage of 3DSv2 is that it is designed to be less intrusive. Issuers can decide for frictionless flow, meaning cardholder will not have to pass an authentication challenge with the issuer, making for a more seamless user experience. In order for issuers to assess the risk of a payment, and thus the need for an authentication challenge, 3DSv2 allows more contextual data to be sent to the issuer during initialization of the 3D Secure flow. Specifically, data regarding Account Information, Merchant Risk and Browser Information (through the AUTH endpoint) can be sent, as described below.

We will support both 3DSv1 and 3DSv2, and for each payment we will automatically detect and use the most recent version for SCA depending on card scheme and issuer support.

Account Information

If the cardholder has an account in your shop, app, e-commerce platform or similar, you may have account information available that the issuer can use to assess the risk factor of the payment. The information is optional but we recommend that it is included if available. The more information provided to the issuer, the better are the chances that the issuer decides that the cardholder doesn’t have to perform SCA.

Stored card details

Stored card details can be used in three different contexts:

• Recurring payments: a transaction series where each transaction is of the same amount and is debited with the same frequency e.g. charging for a membership
• Merchant initiated transactions (MIT): a transaction where you as a merchant need to charge a customer that is not present e.g. for mini-bar expenses after the merchant has checked out.
• Cardholder initiated transactions (CIT) with stored card details: a transaction where the customer/cardholder is present and uses his/her “stored card details” (instead of entering the card details) to be able to do a “one-click payment” in e.g. a app.
  
  

This platform will NOT support Cardholder initiated transactions (CIT) with stored card details from the day we roll out the updates required for SCA. If you wishes to continue to use CIT transaction please contact sales so we can help you to migrate to our new payment platform https://developer.bambora.com/europe.

Recurring payments and Merchant initiated transactions (MIT) will be supported but updates to the API will be needed. Please see below and API changes, to see what updates that will be needed. Important: Recurring payments or MIT can be used on the same account.

Recurring payments

PSD2 defines a recurring payment to be of the same amount for each payment, and there must exist an explicit agreement between the cardholder and the merchant on both the subscription in general, the amount and the frequency of the recurring payments.

When creating a subscription as recurring, parameter subscriptiontype should be set to “recurring”. However, this is also the default value if the parameter is omitted. This will ensure that the subscription created is used for authorizing subsequent transactions:

Roll out of SCA updates