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.
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.
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.
Date | Change |
October 22, 2020 | Deployed API changes |
October 18, 2020 | General 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, 2019 | Published PSD2 documentation |
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.
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 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.
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.
{ "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.
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.
{ "merchantrisk": { "shippingmethod": "ShipToAnotherVerifiedAddress", "deliverytimeframe": "SameDayShipping", "deliveryemail": "john.doe@example.com", "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.
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.
{ "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": "217.186.204.84", "useragent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1" } }
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:
Stored card details can be used in three different contexts:
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:
In addition, it is possible to include the two new optional parameters recurringfrequency and recurringexpiration in the payment request:
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:
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.
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:
Please note that a subscription id for a subscription of type card-on-file can never be used for any other recurring type payments.
Acquirer | Date | Change |
Bambora | November/December 2020 | A more specific date will be communicated shortly |
Nets Visa/MC | November/December 2020 | A more specific date will be communicated shortly |
Nets Dankort | November/December 2020 | A more specific date will be communicated shortly |
Swedbank | November/December 2020 | A more specific date will be communicated shortly |
Handelsbanken | November/December 2020 | A more specific date will be communicated shortly |
Elavon | November/December 2020 | A more specific date will be communicated shortly |
Clearhaus | N/A 2020 | Will not be available as an acquirer from 1/1-2021 |