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.
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.
Note that to access payment resources, you don't need to provide an access token in requests if the payment has been initiated through a redirect Oauth2 workflow
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 application or device independent from 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.
Request Headers | Response Headers | ||||
---|---|---|---|---|---|
TPP-Explicit-AuthorisationPreferred | PSU-ID and PSU-ID-Type | TPP-Redirect-Preferred | TPP-Decoupled- Preferred | ASPSP-SCA-Approach (Response from ASPSP) | Explanation |
true | Decision will be done on POST authorisations API | ||||
false/not provided | not provided | true/false/not provided | true/false/not provided | REDIRECT | |
provided Currently supported PSU-ID-TYPE: "retail" as default value. "" is also accepted. |
true | false/not provided | REDIRECT | ||
true | true | REDIRECT / DECOUPLED | 1. Decoupled workflow is the default process, if PSU is eligible. 2. If PSU is not eligible for decoupled workflow, DECOUPLED will be provided. |
||
false/not provided | true/false/not provided | REDIRECT / DECOUPLED | 1. Decoupled workflow is the default process, if PSU is eligible. 2. If PSU is not eligible for decoupled workflow, DECOUPLED will be provided. |
Request Headers | Response Headers | |||
---|---|---|---|---|
PSU-ID and PSU-ID-Type | TPP-Redirect-Preferred | TPP-Decoupled-Preferred | ASPSP-SCA-Approach(Response from ASPSP) | Explanation |
Not provided | true/false/not provided | true/false/not provided | REDIRECT | |
provided Currently supported PSU-ID-TYPE: "retail" as default value. "" is also accepted. |
true | false/not provided | REDIRECT | |
true | true | REDIRECT / DECOUPLED | 1. DECOUPLED workflow is the default process, if PSU is eligible. 2. If PSU is not eligible for decoupled workflow, DECOUPLED will be provided. |
|
false/not provided | true/false/not provided | REDIRECT / DECOUPLED | 1. DECOUPLED workflow is the default process, if PSU is eligible. 2. If PSU is not eligible for decoupled workflow, DECOUPLED will be provided. |
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 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).
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 :
With the XS2A Product v7, notification callbacks are available on payment status information requests. This is currently available for Instant Payments only. To request this notification callback, the TPP has to provide the following header:
- TPP-Notification-URI : URI for the Endpoint of the TPP-API to which the status of the payment initiation should be sent. This URI must be on the same domain as the CN of the TPP QWAC, otherwise the header will be ignored and the callback will not be sent.
- TPP-Notification-Content-Preferred: This optional header is available to specify which status should trigger a notification. Currently, this header is not supported and will be ignored.
The Payment status notification is sent once with the status received from the CBS upon the payment submission. The TPP can always request for additional status update using the usual payment status request
GET /berlingroup/v1/{payment-service}/{payment-product}/{paymentId}/status
Payment status notification on the Sandbox To test the payment status notification on the sandbox, TPP must use a mock service in order to simulate a Payment Status Notification Event with the followinf endpoint In the body request, TPP must provide the following information
Example:
The Sandbox will then trigger the following callback
|
The PIS with no IBAN / Combined Service is a feature of the AIS consent. It allows a PISP to retrieve the list of account through an AIS request when it should not be able to do so.
Thanks to this feature, a PISP can offer a smooth PIS workflow where the PSU select a debtor IBAN from his/her account list instead of entering the IBAN manually.
TPPs with only the PISP role can only use the global consent scope availableAccounts: allAccounts.
An AIS Combined Service Consent can be one-off.
The property combinedServiceIndicator has to be set to true in the body of the request.
The combined service AIS consent is not supported for a multi authorization payment.
For specific BerlinGroup Implementation on the Payment Initiation Service, please refer to specific implementation How To.