Support

Open banking is the secure process of sharing financial account data between banks and third-party providers, as well as initiating payments. It promotes innovation, competition, and efficiency—making financial services quicker, simpler, and more secure.

The Second Payment Services Directive (PSD2) provides the legal foundation for the development of open banking and a better-integrated internal market for electronic payments within the European Union. PSD2 requires banks to allow third-party providers to access information from payment accounts, with the goal of establishing harmonized rules for the provision of payment services across the EU and ensuring a high level of consumer protection.

PSD2 APIs are primarily designed for Third-Party Providers (TPPs), which fall into two main categories:

• Account Information Service Providers (AISPs): These providers can access customer account data (with consent) to offer services like budgeting tools, financial dashboards, and credit checks.

• Payment Initiation Service Providers (PISPs): These providers can initiate payments directly from a customer's bank account, offering alternatives to traditional card-based payments (e.g., online checkout solutions).

TPPs are licensed and regulated entities, possessing the specific eIDAS certificate, that can access banking data or initiate payments on behalf of users, provided the user gives explicit consent. You can apply for an AISP/PISP license at your national financial authority. Once you have a valid license, you need to obtain valid TPP certificates for production access. 

Other stakeholders who use or benefit from PSD2 APIs:

• ASPSPs (Account Servicing Payment Service Providers):These are mainly banks or financial institutions that hold and manage user accounts. Under PSD2, they are required to expose certain functionalities and data via APIs to authorized TPPs, when the user consents.

• End Users (Consumers and Businesses):These are not the direct users of PSD2 APIs, but benefit from greater control over financial data, innovative financial services and potentially lower fees due to increased competition.

Account Information Services (AIS) give consumers and businesses an overview of their financial situation by consolidating information from the different payment accounts they hold with one or more payment service providers. The Account Information Service offers the following features:

• A list of available accounts or card accounts

• Account details for a specific account or card account, or for all accessible accounts or card accounts related to a granted consent

• Transaction reports for a given account or card account, including balances where applicable

• Details of specific transaction

• Balances of a given account or card account

Payment Initiation Services (PIS) help consumers make online payments and notify the merchant immediately when a payment is initiated, allowing for the prompt dispatch of goods or instant access to purchased online services. The Payment Initiation Service offers the following features:

• Initiation and update of payment request

• Status information of a payment

Payment Instrument Issuing Service (PIIS) checks whether a specific amount is available at the time of the request on an account linked to a given card issuer (TPP)/card number, or addressed by IBAN and TPP, respectively.

Take a look at our banking APIs to explore the available options. Is there an API you can leverage in one of your applications? Use the provided APIs to quickly build a fully featured application.

Explore our APIs

Creating an account is free. Click "Create an account", then enter your name, email address, consumer organization, and password. We'll send you an email with an activation link — just click it, and you’ll be ready to start developing.

Create an account

Before you can use an API, you need to register your TPP application. Log in to the developer portal and navigate to the "Apps" section in the menu. Then, click the "Create New App" button.

Enter the "Title" of your application, and optionally provide the "Certificate" (X.509 PEM format), Description, and "OAuth Redirect URL". Click the "Save" button to complete your application registration.

When you register an application, it is assigned a unique client ID/key and client secret. You must use the client ID when calling APIs that require application identification, either with the client ID alone or alongside the client secret. Check the API documentation for details.

Make sure to note your API Secret, as it is only shown once. Since your API Secret is stored encrypted, we cannot retrieve or display it again if you forget it.

You can reset your API Secret, which will update the stored value and provide you with a new one. To do this, click "Apps" in the main menu, select the application in question, and then click the "Reset API Secret" link in the "Subscriptions" section.

Register app

Invite other members of your organization.

Invite developers

After your application is registered, you need to subscribe to API Product and choose a plan.

We are offering:

• Account Information
  • Consents Service API
  • Confirmation of funds Service API
  • Account Information Service API
• Payment Initiation
  • Payment Initiation Service API

The plan you select determines the environment — either simulation or production. Available plans on the Developer Portal include:

• Simulation
• Default Plan

All plans on the Developer Portal are free of charge. The Bankart API portal provides mandatory PSD2 APIs. API specifications are available as Swagger files in the API Product section of the menu. All APIs follow the Berlin standard and support JSON format.

To subscribe, select your desired product and choose a plan. Next, select an existing application or create a new one. Once your application is subscribed, you can use the provided credentials to access all APIs included in the subscribed products.

API products

To access the simulation or production APIs, you must have a valid eIDAS certificate (X.509 PEM format) uploaded to the developer portal for your application. You can upload the certificate either when creating a new app or later by editing an existing app.

After adding your certificate and redirect URL, you are able to use all PSD2 APIs, according to your given role.

If you want to test APIs with your TPP application, we recommend choosing the Simulation plan. The functionality is the same as in the production environment.

To access the simulation APIs, you must upload a valid eIDAS certificate (X.509 PEM format) to the developer portal for your application.

Once you’ve added your certificate and redirect URL, you can use all PSD2 APIs according to your assigned role in the simulation environment. Please note that your application type should still be set to Development.

You will also need a simulation payment account, which you can request by contacting psd2admin@bankart.si.

Before accessing the production environment, we recommend that you perform relevant tests: see "Use APIs in simulation environment".

To access the production APIs, you must upload a valid eIDAS certificate to the developer portal for your application.

When you subscribe to a PSD2 API, you initially use the simulation plan connected to the simulation environment. You can identify this by the "Development" badge shown on your app card. When you’re ready, you can upgrade to production by clicking the "Upgrade to production" button.

In order to retrieve a user’s account data, explicit consent has to be created and confirmed by the user. User’s account data are provided only for valid consents. 

Prerequisite: Authorization flow

Begin with an oauth/authorize request, during which the Payment Service User (PSU) is redirected to their bank’s login page. The PSU logs into their bank account and selects the IBAN they wish to use (if multiple IBANs are available). After the selection is made, an authorization code will be redirected to the URL you have provided.

Using the obtained authorization code, call the oauth/token endpoint to retrieve the access_token. The access_token is a JWT token. The sub claim within this token contains the IBAN selected by the PSU.

With the valid access_token and the IBAN information, you can proceed to call the POST /consents endpoint to initiate the consent creation process.

For more information, see section API authorization and authentication

By following the below listed steps a valid consent would be created:

1st step: POST /consents – Create consent

This method creates a consent resource that defines access rights to dedicated accounts associated with a given PSU-ID. For details, please refer to the description of the call parameters. The TPP is required to redirect the PSU to the authorization server using the data received from a successful initial call (POST Create Consent). The response contains a URL for redirecting the PSU to complete Strong Customer Authentication (SCA), where the consent authorization can be confirmed.

Important: Consent can be created for account data, transaction data, balance data with a single method. To obtain only account data, "accounts" has to contain valid account data in this method. To obtain transactions data, "accounts" and "transactions" in the method Create consent has to contain valid account data. To obtain balance data, "accounts" and "balances" in the method Create consent has to contain valid account data.

2nd step: GET /consents/{consentId}/status – Consent status request

Read the status of an account information consent resource. Once the »Consent status request« returns the "consentStatus": "valid", the consent was properly authorised by the user and can be used in further flows for retrieving account data.

Optional methods:

• GET /consents/{consentId} – Get Consent Request
• DELETE /consents/{consentId} – Delete Consent
• GET /consents/{consentId}/authorisations – Get Consent Authorisation Sub-Resources Request
• GET /consents/{consentId}/authorisations/{authorisationId} – Read the SCA status of the consent authorisation

Prerequisite: valid consent (see Create consent) with valid IBAN in "accounts" in the method »Create consent«

Steps to get account data details:

1st step: GET /accounts – Read Account List

Read the identifiers (resource ID) of the available payment account together with booking balance information, depending on the consent granted. This method requires to provide the consentID as a header parameter, and will return the correct account according to the provided consent.

2nd step: GET /accounts/{account-id} – Read Account Details

Returns details about an account based on the provided resource ID, obtained with the method Read Account List, with balances where applicable.

Prerequisite: valid consent (see Create consent) with valid IBAN in "accounts" and "transactions" in the method »Create consent«

Steps to get transaction list and details data:

1st step: GET /accounts – Read Account List

Read the identifiers (resource ID) of the available payment account together with booking balance information, depending on the consent granted. This method requires a consentID to be provided as a header parameter, according to which the correct account is returned.

2nd step: GET /accounts/{account-id}/transactions – Read Transaction List

Read transaction reports or transaction lists of a given account addressed by "account-id", depending on the steering parameter "bookingStatus" together with balances.
Important: The »Read Transaction List« call has some query parameters that can be used to narrow down the list of returned data, please check the specifications of this call for more details.

Read transaction lists calls are limited to a period of 90 days from the time the request is made. During the first 5 minutes of an AIS consent lifecycle, any GET /transactions request made will not be limited. After this time period, the limitation will apply, and any requests trying to retrieve transactions older than 90 days will be rejected.

3rd step: GET /accounts/{account-id}/transactions/{transactionId} – Read Transaction Details

Reads transaction details from a given transaction addressed by "resourceId" on a given account addressed by "account-id". This call is only available on transactions as reported in a JSON format.

Steps to initiate a payment:

1st step: POST /{payment-service}/{payment-product} – Payment Initiation Request

This method initiates a payment at the ASPSP. Detailed parameters for this call are described in the method specification.

Important: After the initial payment initiation request, the user must be redirected to the authorization URL provided in the scaRedirect element of the response.

2nd step: GET /{payment-service}/{payment-product}/{paymentId}/status – Payment Initiation Status Request

This call is optional but provides essential information about the transaction status of the payment initiation.

Optional methods:

• GET /{payment-service}/{payment-product}/{paymentId}/authorisations/{authorisationId} – Read the SCA Status of the payment authorisation

• GET /{payment-service}/{payment-product}/{paymentId} – Get Payment Information

• GET /{payment-service}/{payment-product}/{paymentId}/authorisations – Get Payment Initiation Authorisation Sub-Resources Request

By definition, certain critical PSD2 APIs require OAuth2 authentication. These APIs are clearly marked in our API documentation and Swagger definitions. OAuth2 is required in both the simulation and production environments.

Examples of APIs requiring OAuth2:

• Consent APIs (all within the PSD2 Account Information product)

• Payment APIs (e.g., payment initiation requests)

In addition, these APIs typically require a Strong Customer Authentication (SCA) step—unless an exemption is defined by business rules. The SCA process is necessary to comply with regulatory requirements and ensure secure access and transaction authorization.

We use the OAuth2 Authorization Code Flow for securing access to protected APIs.

To begin, open the GET /oauth/authorize URL in a browser with the following parameters: response_type, client_id, redirect_uri, scope, iban(optional).

Scope Values:

• For Account Information: psd2:acc

• For Payment Initiation: psd2:pay

Example:

https://api-oauth.bankart.si/psd2/nkbm/oauth/authorize?response_type=code&client_id=db...&redirect_uri=https://www.xyztpp.si&scope=psd2:acc&iban=SI56XXXXXXXXXXXXXXX

Be sure to use your own application's client_id and redirect_uri (registered during app creation).

When the authorization page opens, enter the username and password, on the second screen, click "Allow Access". You will then be redirected to your redirect_uri with an authorization code included as a URL parameter. Extract this code value — you'll need it to get your access token.

To exchange the authorization code for an access token, you’ll need a tool that can perform a POST request (e.g., curl). You need to pass grant_type, client_id and code as x-www-form-urlencoded data.

Example:

curl -d "grant_type=authorization_code&client_id=dbe...&code=AAL7lhdq6k..." \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "accept:application/json" \
     -X POST https://api.bankart.si/psd2/otp/oauth/token

This will return a JSON object containing the access token. You can now use this token to call OAuth2-protected APIs. Add the token in the Authorization header of your requests, prefixed with Bearer. Alternatively, you can paste the token into the "Access token" field in the developer portal to call the API directly from there.

Note: The access token is valid for 5 minutes. 

For more information on endpoints, parameters, and response formats, refer to the published Swagger API documentation.

According to the PSD2 Berlin Group standard, a Strong Customer Authentication (SCA) step is required after certain crucial (i.e., sensitive) API calls, such as:

• Create Consent

• Read transaction lists (to retrieve transactions older than 90 days)*

For this, we use an implicit flow with a simple redirect (no OAuth2). Please check the API response header for the ASPSP/PISP-SCA-Approach value. When present, redirect the end user to the URL provided in the _links/scaRedirect response element.

There is no direct return of information from this redirect to your application, but certain crucial calls are made in the background to complete the authorization and process the payment or create the consent object.

You can verify the outcome of the SCA process using the corresponding API call: GET /consents/{consentId}/authorisations/{authorisationId}. For more details, see the API documentation or Swagger definition.

* Note on transaction list access:
Calls to read transaction lists are limited to a 90-day period from the time of the request. However, during the first 5 minutes of an AIS consent lifecycle, any GET /transactions request will not be subject to this limit. After this initial period, the 90-day restriction applies, and requests for transactions older than 90 days will be rejected.