For the purpose of carrying out a payment cancellation with the XS2A APIs, it is necessary for the TPP to ask for the cancellation to the ASPSP. In order to validate the cancellation, 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 cancellation request 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.
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.
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. |
Asks for payment cancellation at the ASPSP for a given payment (giving id, service and product). Specificities for this API and available services and products are listed in the dedicated HowTo.
Creates an authorisation sub-resource of the payment resource for its cancellation and start the authorisation process.
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 :
For specific BerlinGroup Implementation on the Payment Initiation Service, please refer to specific implementation How To.