Please wait ...


Loading...

PSD2 Introduction

The Payment Service Directive (PSD2) is an EU Directive that will come into effect on 14th September and it will among other things impose new security regulations for online payments, namely requirement for strong customer authentication (SCA).


The sections below and in the PSD2 submenu describe the API changes made to accommodate PSD2 compliance and allow you as a consumer of our APIs to be compliant from 14th of September. The information contained on these pages mainly focuses on the technical aspects of PSD2, for general information please refer to some of our other PSD2 content:



The information above is for consumers of the Payment Window, Payment Request and the AUTH endpoint through custom integrations or using our SDKs.


As a general note, any API changes discussed below can also be found in the API Changes section. We encourage you to look there to see how specific endpoints are changed, since we do not include examples for all affected endpoints below. Also, please refer to the API Changes section where all PSD2 related changes and parameters including parameter description, type and validation requirements are listed.


Solutions and integrations subject to change:


Payment window v1:

The payment window v1 does not support 3D Secure and will be discontinued by 14 September. Please check the Change log for any updates.


Webpay:

If you use Webpay, our MOTO solution; without a valid MOTO Acquiring agreement, please contact support support@bambora.com.


Hosted solutions:

All hosted solutions currently do not support 3D Secure and will either be upgraded or discontinued by the 14th of September. Please check the Change log for any updates.


Important: The information provided here regarding PSD2 may change at some point, since other parties (acquirers etc.) are still working on and haven't finalized their changes yet. This can potentically 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.

Changelog

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.


DateChange
July 31, 2019Published PSD2 documentation

Strong Customer Authentication

With strong customer authentication (SCA) becoming a requirement, online payments will go through 3D Secure, which is major card schemes´ solution to accommodate this requirement. Local card schemes might have their own solution, like Dankort Secured by Nets for the Danish Dankort, but the general customer experience during payment 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 in Sweden 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 by PSD2. 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 Subscription section below for 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. MOTO is not supported now, and will not be ready for 14th September (also mentioned above in the Solutions and integrations subject to change section).
  • 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. The decision to make exemptions is always up to the issuer, who can allow for transactions to be done without the card holder performing SCA. However, the 3D Secure specification doesn't currently support exemption flagging for any of the allowed exemptions in PSD2, except recurring payments which is described below.

  • Recurring
    Recurring payments is the only exemption that will be directly supported, and this is handled by subscriptions and our Payment Request API. See the Subscription section below for further details.

3D Secure 2.0

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 2.0 (3DSv2) which is a more secure and future proof SCA solution compared to 3DSv1. Issuers are not required to support 3DSv2 for 14th September 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.


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.


3DSv2 is also 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 initilization 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.


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


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 14th September 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,
    "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


Subscription

Subscriptions can be of type recurring payment or of type card-on-file payment (which is a type of Merchant Initiated Transactions described further down).


Recurring payments

Recurring payments are subscriptions in which the card details and other information are stored once for the original subscription and all subsequent subscriptions are using this information based on the original subscription. PSD2 defines a recurring payment to be of the same amount for each payment, and there must exist an explicit agreement between cardholder and merchant on both the subscription in general, the amount and the frequency of the recurring payments. More information for recurring payments are available in the Recurring section.


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.


Card-on-file payments

A Merchant Initiated Transaction (MIT) is a transaction using previously stored details without the cardholder's participation. This can be used to perform payments on cardholder's behalf in situations where it is not possible for cardholder to be present, e.g. a hotel can charge for mini-bar expenses after cardholder has checked out.


The card-on-file subscriptions are used for all Merchant Initiated Transaction (MIT) transactions in which the cardholder is not present when doing the payment.


With card-on-file payments, the merchant only stores payment tokens in their database rather than the actual card number thus reducing the risk and mitigating the impact of malware, phishing attacks and data breaches.

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

Card-On-File example


MITs are not subject to SCA because they are considered out of scope for PSD2. 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 14th September.


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