Description

For the purpose of carrying out a payment initiation with the XS2A APIs, it is necessary to establish a consent between the TPP, the PSU and the ASPSP. In order to do that, comdirect offers two different transaction flows. One follows a Redirect OAuth2 approach, the other one follows a Decoupled approach.

Redirect OAuth2

In this approach, the PISP has to proceed with an OAuth2 authorization. The consent is established and validated thanks to a redirection of the PSU towards the ASPSP Authentication platform.
See How to Perform a Strong Customer Authentication for details.

Decoupled

The decoupled approach is similar to the redirect one. The difference is that the ASPSP asks the PSU to authenticate e.g. by sending a push notification with transaction details to a dedicated mobile app or via any other application or device which is independent of the online banking frontend.
In difference to the redirection flow, there is no impact on the PSU/TPP interface during the technical processing.
See How to Perform a Strong Customer Authentication for details.

Payment Initiation
Initiate Payment Resource
POST /berlingroup/v1/{payment-service}/{payment-product}

Creates a payment resource at the ASPSP for a given payment service and product. Specificities for this API and available services and products are listed in the dedicated HowTo.

Create an authorisation resource on a given payment
POST /berlingroup/v1/{payment-service}/{payment-product}/{paymentId}/authorisations

Create an authorisation sub-resource of the payment resource and start the authorisation process.

The usage of this access method is only necessary if the TPP has asked to start the authorisation process separately from the payment initiation (using the “TPP-Explicit-Authorisation-Preferred” Header).

Authorization request
GET /berlingroup/authorization/authorize/{authorisation-id}

Requests an authorisation from a PSU following the OAuth2 protocol. Details of the authentication workflow and user interfaces are described in the dedicated HowTo section.
Our specificities regarding the OAuth2 protocol are listed below.

response_type : code
code_challenge_method : S256

After successful authorisation, the user will be redirected to the redirect URI provided in the request with the following parameters :

https://your_redirect_uri?code=authorization_code&state=test
Payment with no IBAN/ Combined Service.

The PIS with no IBAN / Combined Service is a feature of the AIS consent. It allows the combination of AIS and PIS workflows in order to start a PIS transaction without having to manually fill the debtor IBAN.

Thanks to an AIS Combined Service Consent given to the PISP, the TPP can retrieve the list of account and offer a smooth PIS workflow where the PSU select a debtor IBAN from his/her account list instead of entering the IBAN manually.

Prerequisite

TPPs with both roles AISP/PISP can create AIS combined service consents on all PSD2 scopes. The property combinedServiceIndicator has to be set to true in the body of the request.

However, TPPs with only the PISP role are allowed to create AIS combined service consents only with the scope availableAccounts: allAccounts

Payment initiation

The TPP must fill the header Authorization header in the payment initiation request with the AIS access token of the combined Service consent in order to skip the login phase. Depending on the consent validity and creation date, the PSU might not have to log in again before performing the SCA.

The payment will not be rejected if the consent is not valid. It will be considered as a standard payment with a full authentication (Login + SCA).

The combined service AIS consent is not supported for a multi authorization payment.

NB: A PSU can have a maximum of one active AIS consent (no matter if the consent is combined service or not). Its duration is 90 days, which means that for a TPP with the PISP role, the account list will be retrievable for 90 days and will always get the same result.

Specific BerlinGroup Implementation on Payment Initiation Service

For specific BerlinGroup Implementation on the Payment Initiation Service, please refer to specific implementation How To.