Please wait ...


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


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


The following table contains a summary of any changes made to the documentation, so it is possible to know if you are compliant with the latest changes.

October 22, 2020Deployed API changes
October 18, 2020General information and terminology have been updated
Stored card details limitations, no additional API changes has been posted
Table for “Role out of PSD2 updates” has been added
July 31, 2019Published PSD2 documentation

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.


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.

Account Information Model

{ "accountinformation": { "authentication": { "data": "", "method": "NoAuthentication", "timestamp": "2016-04-30T00:00:00.000Z" }, "prior3dsauthentication": { "data": "", "method": "FrictionlessAuthenticationOccurredByAcs", "reference": "0a137f3d-9fcf-4040-b6c7-e596cb79d953", "timestamp": "2016-04-30T00:00:00.000Z" }, "createdindicator": "CreatedDuringTransaction", "createddate": "2016-04-30T00:00:00.000Z", "changedindicator": "ChangedDuringThisTransaction", "changeddate": "2016-04-30T00:00:00.000Z", "nameidenticaltoshippingaddressname": true, "shippingaddressfirstusedindicator": "ThisTransaction", "shippingaddressfirstuseddate": "2016-04-30T00:00:00.000Z", "shippingaddressidenticaltobillingaddress": true, "transactionspast24hours": 1, "transactionspastyear": 17, "transactionsapprovedpastsixmonths": 34, "passwordchangedindicator": "NoChange", "passwordchangeddate": "2016-04-30T00:00:00.000Z", "paymentaccountcreatedindicator": "CreatedDuringTransaction", "paymentaccountcreateddate": "2016-04-30T00:00:00.000Z", "provisionattemptspast24hours": 3, "suspiciousactivity": false } } 

The accountinformation model allows general information regarding when the cardholders account was created and change, when the password was changes, transaction activity and more. The accountinformation.authentication refers to how the cardholder was authentication with his/her account in your system, while accountinformation.prior3dsauthentication refers to how cardholder was authentication during 3D Secure for a previous payment, if available.

For more information about the specific parameters in the model, and for which endpoints in our APIs that the information can be included, please refer to the API Changes.

Merchant Risk

Any risk you as a merchant have in relation to an order is also relevant to the issuer for risk assessment. 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.

Merchant Risk Model

{ "merchantrisk": { "shippingmethod": "ShipToAnotherVerifiedAddress", "deliverytimeframe": "SameDayShipping", "deliveryemail": "", "reorderitemsindicator": "FirstTime", "orderavailability": "MerchandiseAvailable", "preorderavailabilitydate": "2016-04-30T00:00:00.000Z", "giftcard": { "currency": "SEK", "amount": 123, "count": 1 } } } 

The merchantrisk model allows general information regarding about the order, shipping method, delivery and more. The merchantrisk.giftcard can be used to indicate if gift cards is used or not to pay the order.

For more information about the specific parameters in the model, and for which endpoints in our APIs that the information can be included, please refer to the API Changes.

Browser Information

In addition to account and merchant risk information, 3DSv2 also adds support for browser related information from the cardholder's browser during payment. This is both used for risk assessment by the issuer, but also for deciding which authentication challenge solution that is best supported and provides the best user experience in the cardholder's browser.

The browser information is required for any payment that is subject to SCA. If you are using the Payment Window or Payment Request, this is handled automatically, and the necessary browser information will be collected during payment.

For direct integration to the authorize API (AUTH endpoint), the browser information is required from 31st of December in most cases.

Browser Information Model

{ "browserinformation": { "acceptheader": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "javaenabled": true, "language": "en-US", "colordepth": 32, "screenheight": 800, "screenwidth": 600, "timezoneoffset": 180, "ip": "", "useragent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1" } } 

Dictating SCA

It is possible to force SCA for a payment, should you for instance suspect potential fraud or other reasons where you want to ensure cardholder goes through SCA and not leave that decision to the issuer. The securitylevel parameter has been added to accommodate this, as shown here for a payment request through the Payment window:

Security level example request


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

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:

Subscription Type example

{ 'subscriptiontype': "recurring" } 

In addition, it is possible to include the two new optional parameters recurringfrequency and recurringexpiration in the payment request:

Recurring Frequency and Recurring Expiration

{ 'recurringfrequency': 1, 'recurringexpiration': "2016-04-30T00:00:00.000Z" } 

The recurringfrequency indicates the minimum number of days between each recurring payment, and the recurringexpiration indicates the date after which no more recurring payments will be made on the subscription. Although these two values are optional, and we will assume suitable values if not supplied, we strongly encourage you to supply values for these to increase issuer acceptance.

A complete example of a Payment Window request creating a subscription as recurring:

Payment Window Request


Please note that the subscription id for a subscription of type recurring can never be used for card-on-file type payments.

More information for recurring payments are available in the Recurring section.

Merchant Initiated Transaction (MIT)

MITs are not subject to SCA because they are considered out of scope for PSD2, see General information PSD2 and SCA. However, SCA is still required during creation of the subscription where cardholder saves card details as card-on-file. We will handle this for you automatically and all card-on-file payments will go through SCA during creation from January 1st 2021.

A complete example of a Payment Request creating a subscription as card-on-file:

Card-On-File example


Please note that a subscription id for a subscription of type card-on-file can never be used for any other recurring type payments.


Roll out of SCA updates

BamboraNovember/December 2020A more specific date will be communicated shortly
Nets Visa/MCNovember/December 2020A more specific date will be communicated shortly
Nets Dankort November/December 2020A more specific date will be communicated shortly
SwedbankNovember/December 2020A more specific date will be communicated shortly
HandelsbankenNovember/December 2020A more specific date will be communicated shortly
ElavonNovember/December 2020A more specific date will be communicated shortly
ClearhausN/A 2020Will not be available as an acquirer from 1/1-2021