Get Started

TABLE OF CONTENTS
Introduction Signup and Login Application creation Subscribe to the APIs PSD2 APIs Authentication and authorization Sandbox sample data Supported flows and features Account Information Service Providers Consent model Payment Initiation Service Providers Authorization flows Card Based Payment Instrument Issuers

Introduction

Welcome to the Developer Portal!

This developer portal provides you a ready-to-use environment for accessing our APIs where you can find documentation, specifications, sandboxes and register to the services provided through a SaaS delivery model.

To start developing within the Sandboxes, you only need a valid email address.

Note that for PSD2 API, the Sandbox access is restricted to authorized third party providers that have already received their QWAC and QSeal or providers that can prove that they have already submitted their application form to become an authorized third party provider in a member state of the European Union. After creating your account, you might be asked to provide such evidence to keep your Sandbox account accessible.

If you already have a QWAC, registration on the developer portal is optional to access both sandbox and production APIs.

Upon the first API call using your QWAC, an API consumer account is automatically created with the email address contained in the QWAC.
If you would like to log in to the developer portal using that account, use the ‘Forgot password’ link on the login page to reset your password.

If you need access to sandbox without the QWAK certificate, follow the procedure below:

Fill the small registration form
- Username: Will be used to sign in
- Email Address: All emails from the system will be sent to this address. The email address is not made public and will only be used if you wish to receive a new password or certain notifications by email
- Consumer organization: The name of the organization under which all the users and the client applications will be grouped. If you want to join an existing consumer organization, you need to be invited by an existing member.

2. Complete your registration by clicking on the activation link sent to your email address.

3. That's it, your are now registered and you can create an application in order to subscribe to APIs.

Once you have completed this sign-up process, you just need to subscribe to an API using an application to be able to use the related Sandbox environment.

Application creation

In order to be able to call APIs, you will need to create an "Application". The credentials that you need to call an API are bound to an application, you can see the key (or client-id) in the application management section, but the secret (client-secret) is only showed once when you create the application. You need both client-id and client-secret when you call an API.

1. Create an application through the "Apps" menu

2. Keep your client-id (key) and client-secret (secret) in a safe place, these are the application credentials. The client-secret is only displayed once on this screen.

3. That's it, you can now subscribe to an API plan with this application.

Explore the API marketplace and find the API of your interest, then you can subscribe to defined plans.

Once subscribed, you can use the application credentials to call the API.

PSD2 APIs

The API provides an implementation of the Berlin Group version 1.3 API, which might be updated when new versions of the specification are released. Details about implementation choices and supported features are listed in the paragraphs below.

You can try the simulated version of the PSD2 available flows in the Sandbox environment. In order to authenticate to the Sandbox API endpoints you need to have either the credentials of your client application or an eIDAS certificate.

The future production environment will only be accessible to fully authorized third party providers that can present a valid QWAC in the TLS mutual authentication setup of the connection to the API endpoint.

Authentication and authorization

Berlin Group APIs that give access to PSU data require explicit consent of the end-user (PSU) that is authorized to access the given payment account. Berlin Group is proposing three different models to provide PSU credentials to the API out of which the Redirect Flow is by far the most flexible and provides support for any type of strong customer authentication method already used by the ASPSP.

All APIs provide support for the Redirect Flow. The optional OAuth2 flow as a pre-step defined by Berlin Group does not follow a proper Authorization Code Grant flow and is therefore not supported by the Sandbox.

During the authorization procedure, the PSU is required to provide his consent by performing a strong customer authentication. The Sandbox environment allows you to simulate the PSU authentication flows with sample data given hereunder.

Sandbox sample data

In order for you to simulate real scenarios, we provide you some representative data that you can use in the sandbox environment.

For some flows you might indeed need to have an account identifier, a user identifier and a user password that allow you to simulate a full PSU experience according to your use cases.

Username	Password	BBAN	Currency
3100120000001000	3100120000001000	218314318619011	EUR
3100120000001001	3100120000001001	218312431861902	EUR
3100120000001002	3100120000001002	218312431861903	EUR
3100120000001003	3100120000001003	218312431861904	EUR

Supported flows and features

Here are the supported features offered by the PSD2 API. As a general rule, consider that a feature not present in this table is not available through the API.

Feature	Supported
AIS	Y
PIS - Single Payment	Y
CBPII	Y

Account Information Service Providers

AISPs can access API endpoints tagged as such in the Berlin Group API specifications. These methods provide access to account lists of a PSU, their respective balances and transaction history.

Berlin Group defines two different consent models, both of which are supported by the Berlin Group APIs provided in this portal.

Global consent: the TPP requests access to all of the PSUs data
Detailed consent: the TPP requests access to a specific subset (accounts, balances, transactions) of the PSU's data

Payment Initiation Service Providers

PISPs can access API endpoints tagged as such in the Berlin Group API specification. These methods allow TPPs to initiate payments on behalf of the PSU.

Authorization flows

Berlin Group defines two different authorization approaches:

Implicit: The TPP doesn't explicitly call the /authorizations API endpoints to create one or more authorizations for payment
Explicit: The TPP always explicitly calls the /authorizations API for each created payment

Only explicit authorizations are generic enough to provide support for single and multiple authorizations for a payment and are hence the only supported model.

Note that even if the payment products of type "Cross-Border" and "TARGET2" are not present in the list of supported features, the backoffice might however use the most suitable settlement channel when the payment is received. This complexity is therefore abstracted from the PSU / PISP who only have to create a payment (with Berlin Group Sepa CT payment product endpoint) and then the backoffice will be responsible for determining the right settlement channel.

Card Based Payment Instrument Issuers

The CBPII can access API endpoints tagged as such in the Berlin Group API specifications. These methods allows issuing card-based payment instruments that can be used to initiate a payment transaction from a payment account held with another payment service provider.