Documentation

This is where you will get background and supplementary information about security model and other pre-requisites for accessing the APIs. This serves as a supplement and additional background to the information available in the API documentation. Also refer to the in-detail sections on TPP Onbarding and Prod environment

 

 

The following questions and answers have been published in categories to make it easier to find the relevant topics. Please use the search functionality in your browser to search for specific words.
If you are new to the PSD2 API you are advised to read all of the topics below to get a better understanding of the implementation. Please also see the general documentation

Please also read the full API specification as the FAQ does not describe the implementation from A-Z.

 

Payment

Production environment

Production is a live environment working on real production data. Access to production APIs is strictly enforced and limited to authorized TPPs with proper license to operate as a AISP, PISP or CBPII under PSD2 in Denmark. An onboarding must have been completed as a prerequisite for consuming the PSD2 API's. The onboarding includes register of certificates and validate license to operate as an AISP, PISP or CBPII.

 

On top of TPP validation - e.g. validation that TPP is properly

Sandbox environment

Note: As of September 2019, the isolated, purely mocked sandbox environment has been replaced by a new environment with support for security solution, consents and SCA flows. The new sandbox still works on mocked data, but the infrastructure now much more resembles the production environment and it allows a TPP to test full E2E integration - including onboarding using EiDAS certificates - prior to moving to production. The old sandbox will be decommisioned. TPPs that have previoously signed

In order to ensure that we have the correct information and that we can trust the certificates that are used for TPP authentication and message sealing, we need to perform an enrollment of TPP. This will be a 1 step process, where the TPP sends a signed request, in the same form as expected from Berlin Group, to an enrollment API. This process will ensure:

  1. That we receive all the required certificates, including root and intermediary certificates, in a sealed and authenticated request

All API communication in the context of PSD2 will be handled by using a combination of certificates. There are 2 distinct flows that 3rd party clients need to use in every transaction:

  1. Identification and Authentication
    1. This is achieved by establishing a mutual TLS connection, using a QTSP issued QWAC certificate
  2. Non-Repudiation and Message Integrity
    1. This is achieving by signing each request, according to the documentation, using a QTSP issued QSEAL certificate.

Not

The diagram below depicts an overview of the flow, taking place during the creation and authorisation of a payment, including who plays what role. The respective banks responsibility is limited to the actions happening between the TPP and ASPSP. All parts of the flow are described except the SCA, which has been depicted below.
 

Payment flow


The SCA processes are confined to the general national authentication solutions; MitID and NemID.
NemID is in the process of being phased out as a general

The NemID applet is implemented as customizable. At the same time, it is possible to select the NemID mode limited/standard.

The solution is implemented as parameters to each SCA URL. See example below:


/Authorize/payment?id=6a9ed6b3-dab2-4554-947b-51ecab02352b&lwidth=500&aheight=800&awidth=700&lheight=400&clientmode=limited&lang=en

 

Below is a table describing the different possible variables:

Name

Value

The diagram below depicts an overview of the flow, taking place during the creation of consent, including who plays what role. BEC's responsibility is limited to the actions happening between the TPP and ASPSP. All parts of the flow except the SCA, which has been depicted below.
 


 

The SCA processes are confined to the general national authentication solutions; MitID and NemID.
NemID is in the process of being phased out as a general national authentication solution.

 

MitID -

The scope of this portal and the associated APIs is an implementation of the services described and specified under the PSD2 RTS:

  • Account Information Services (AIS) + Consents
  • Payment Initiation Services (PIS)
  • Fund Confirmation Services (FCS)

The implementation of the APIs as well as the security model follows the Berlin Group XS2A version 1.3 framework. Differences from the Berlin Group specification as well as our choice of alternatives and optional features are documented in the

The APIs are made available to TPPs authorized by a local NCA (in Denmark Finanstilsynet) to operate as an AISP, PISP or PIISP under the PSD2 directive. For TPPs registered under a different national CA, they will need to passport their TPP status to operate in Denmark.


Access to production APIs is restricted to TPPs who are fully approved and authorized by their NCA to operate in the relevant roles (AISP, PISP, PIISP) in Denmark. Access to sandbox APIs is available to authorized TPPs as