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.

If you have a PSD2 licence but don’t want to connect to every bank in Slovenia, we are offering HUB, so you can reach all Slovenian banks with only one connection via openbanking.bankart.si/hub.

Account Information Services

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

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

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.

ATM Information

»ATM information« offers two API calls which provide to the user retrieving of information of all ATMs included in the Bankart network, as well as supported services and the status of each ATM.

Currency Exchange Calculator

»Currency Exchange Calculator« offers an API call which provide to the user retrieving of information of the currency exchange rate.

Merchant API

»Merchant API« offers two API calls that provide to the user the retrieval of information of list of reports available for download as well as the download of the file that the user selects by calling the first method.

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
• ATM Information API
• Currency Exchange Calculator API
• Merchant API

The plan for PSD2 APIs determines the environment (production/simulation) and status of the user (TPP or not). We are offering:

• Default Plan – production
• Premium Plan – production
• Simulation Plan
• Non-TPP Default Plan
• Non-TPP Premium Plan
• Non-TPP Simulation

In Bankart API portal mandatory PSD2 APIs are available. API specification is available as a Swagger file, in the "API Product" section in the menu. All APIs follow Berlin standard, JSON format is supported.

For the non PSD2 APIs (ATM Information, Currency Exchange Calculator and Merchant API) we are offering:

• Default Plan

For subscription you select the desired product and make a subscription to one of the plans. In the next step you select an existing application or create a new application. Once your application is subscribed, you use received credentials to test all APIs included in the subscribed products.

API products

It is possible to test an API from this developer portal with static data in the sandbox environment by subscribing to the sandbox API. Before using test cases below, please read the API documentation and swagger definitions under "API Product" tab.

In Bankart API portal mandatory PSD2 APIs are available. All APIs follow Berlin standard, JSON format is supported. APIs published on the portal are sandbox versions and return static answers. All data in the tables below is intended for testing and has no relation to real data. Data in tables can change at any time without prior notice.

Consents Service API

Account Information Service

Payment Initiation Service API

Payment Instrument Issuing

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.

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 for the simulation and production environment:

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

Example for the sandbox environment:

https://api.bankart.si/psd2/hub/sandbox/oauth2/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/hub/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.

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. We support only one IBAN per consent. 

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. After a successful consent creation (POST Create Consent), the TPP must redirect the PSU to the authorization server using the URL provided in the response. This redirect enables the PSU to complete Strong Customer Authentication (SCA) and confirm the consent authorization.

Important: Consent can be created to obtain account data, transaction data, and/or balance data with a single method.

• To obtain account data only, "accounts" must contain valid account identifiers.

• To obtain transaction data, both "accounts" and "transactions" must contain valid account identifiers.

• To obtain balance data, both "accounts" and "balances" must contain valid account identifiers.

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

This method retrieves the current status of an account information consent resource. When the response returns "consentStatus": "valid", it indicates that the consent was successfully authorized by the PSU 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: A valid consent (see Create consent) with a valid IBAN included in "accounts" during consent creation. 

Steps to get account data details:

1st step: GET /accounts – Read Account List

Retrieve the identifiers (resource ID) of available payment account along with booking balance information, depending on the consent granted. This method requires the consentId to be provided as a header parameter and will return the account authorized by that consent.

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

Retrieve detailed information about a specific account identified by account-id, which is obtained from the Read Account List method. This includes balances where applicable.

Prerequisite: A valid consent (see Create consent) with valid IBAN included in both "accounts" and "transactions" during the consent creation. 

Steps to get transaction list and details data:

1st step: GET /accounts – Read Account List

Retrieve the identifiers (resource ID) of the available payment account along with booking balance information, depending on the consent granted. This method requires the consentId to be provided as a header parameter, which determines the account returned.

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

Retrieve transaction reports or transaction lists for the specified account (account-id), optionally filtered by the query parameter "bookingStatus", along with balances.

Important: The Read Transaction List call supports query parameters that can be used to narrow down the returned data. Please refer to the API specifications for details.

Transaction list requests are limited to a period of 90 days from the time the request is made. However, during the first 5 minutes of an AIS consent lifecycle, any GET /transactions request is not subject to this limitation. After this initial period, requests for transactions older than 90 days will be rejected.

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

Retrieve detailed information for a specific transaction identified by transactionId within the given account (account-id). This call returns transaction details in JSON format and is only available for transactions reported in that format.
 

Prerequisite: A valid consent (see Create consent) with a valid IBAN included in both "accounts" and "balances" fields during the consent creation. 

Steps to get balance data:

1st step:  GET /accounts – Read Account List

Retrieve the identifiers (resource ID) of the available payment account along with booking balance information, depending on the consent granted. This method requires a consentId to be provided as a header parameter, which determines the account returned.

2nd step:  GET /accounts/{account-id}/balances – Read Balance

Retrieve account balance data for the specified account identified by account-id.

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

Steps to initiate a payment:

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

This method is used to initiate a payment at the ASPSP. Detailed parameters for this call are described in the method specification.

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} – Get Payment Information

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

Prerequisite:
A valid consent must exist (see Create Consent) with the following conditions:

• The accounts field must include a valid IBAN.

• The parameter confirmationOfFundsAllowed must be set to true.

• The parameter validUntil must be set to 9999-12-31.

• The accounts field must contain valid account data.

• The transactions and balances fields must be empty in the Create Consent request.

Steps to check if funds are available for payment execution:

1st step:POST /funds-confirmations – Confirmation of Funds Request

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