The second EU Payment Services Directive (EU 2015/2366), PSD2, regulate payment services and payment service providers throughout the European Union and European Economic Area. The Directive's purpose was to increase competition and participation in the payments industry, strengthen consumer protection and clarify the rights and obligations for payment providers.

Amongst other things, it means that Third Party Providers (TPPs) must be allowed to access payment accounts, initiate payments and get confirmation of funds, on behalf of the customers, in their own infrastructure by using the banks APIs. 

The main objectives of the regulation are:
• to increase competition.
• a more integrated and efficient European market for payments.
• to improve and create the same conditions for all new and existing payment providers.
• to increase security for online payments and access to accounts within the EU and EEA to strengthen consumer protection.

Read more about PSD2

Our APIs follow PSD2 regulations and in order to use them, you have to be an authorised TPP. You must be registered as either a Payment Initiation Service Provider (PISP), an Account Information Service Provider (AISP) or a Card Based Payment Instrument Issuer (CBPII), authorised by the competent authority in your country.

We have modelled our API structure to the Berlin Group Technical Standard but made some deviations to better fit our markets. You can test the APIs in our Sandbox or by using a Postman environment, but first we recommend that you read the Technical Guidelines.

Account Information API v2

Payment Initiation API v1 

Confirmation of Funds API v1

All PSD2 APIs have REST-endpoints and HTTP-verbs GET, POST and PUT are used. The endpoints will consume and respond with JSON-structures with UTF-8 encoding.

The PSD2 APIs have mandatory HTTP-headers. Please note that our APIs might also have additional specific headers.

Our APIs have major and minor versions, a major version represents a breaking change in the API, such as removing a field in the JSON response of an endpoint or a major new feature of the API. A minor version represents a non-breaking change, such as adding a non-mandatory field. There is also a patch version used for documentation changes that shall not affect the service endpoint communication.

Versioning example:
Accounts Information API v1.1.0

The release of a new minor version of an API will override the implementation of the previous one (within the same major version). Example: when version 1.2.0 is released, 1.1.0 of that API will have the same implementation as the new one. The plan is to support two parallel major versions of an API in the Live environment; one current and one deprecated. When a new major version is released the previous deprecated one will be removed.

Before you start testing our APIs, please read our guidelines where you can find all the technical details you'll need. It will provide you with an overview of requests and responses to all endpoints for the AISP, PISP and CBPII flows.

Technical Guidelines

We have developed a service that works in real time which allows you (as an authorised TPP) to self-onboard once ready to connect to our live data. This means you shouldn't experience any specific delays when you are ready to go live. We'll provide you with more details about this onboarding process in a later stage.

Necessary steps before accessing live data:

1. Contact your Local Competent Authority and apply to become an authorised Third Party Provider (TPP). You must receive authorisation to act as a Payment Initiation Service Provider (PISP), an Account Information Service Provider (AISP) or a Card Based Payment Instrument Issuer (CBPII).

2. Contact a Qualified Trust Service Provider (QTSP) to receive an eIDAS certificate. 

Please visit the link below for more information about our contingency mechanism.

Fallback solution