ob-p-a2a-flow
There are 3 main types of payment flows:
1. Redirect
In the Redirect Approach the browser session of the payer is redirected from your software to payer's bank. In that case the bank provides all the pages required for Strong Customer Authentication (SCA). Once the authorisation is complete, the payer is being redirected back to your software.
2. Decoupled
In the Decoupled Approach no redirection takes place. Instead the payer's bank notifies the payer, for example using mobile banking app. The authentication is executed by the app. Since this approach is asynchronous, you need to check payment status to know when the authentication process has been finished.
3. Embedded
In the Embedded Approach you have to provide all the screens required for the authentication process and to communicate all necessary steps over the API of the Open Banking Service to the ASPSP.
Authorization Steps
Depending on the payment flow you will need to implement a different sequence of API call. Please check below sequence diagrams to understand each flow.
You can indicate your preferred SCA method by using PreferredScaMethod (Embedded, Decoupled, Redirect) parameter, but there is no guarantee that the bank will actually use it to authenticate the payer. You can check what payment method is supported by each bank from Reach API.
For faster integration and better user experience we offer the Bank Selection Interface, it will then always become a redirect flow from you to this interface. This interface can be customised with your branding allowing to choose the payer's bank and handling the complexity of different PSD2 authorization flows, so that you will be able to focus on your product and leave the boring stuff to us.
The selected flow with which authentication will go through, is being identified by the name of a hyperlink, provided in the response.
Redirect Flow
Below is a sequence diagram showing a typical redirection payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).
Redirect back to the Initiating Party
Once the PSU has interacted with the ASPSP, the session will be redirected back to the Initiating Party. Here, the Open Banking Service appends the Initiating Party Return URL with the Service Name and the payment ID so that the session can be recognised. This enables the Initiating Party to display the correct screen to the PSU.
An example of a return URL is as follows: https://www.example.org/?scope=UElTOjE1NjQzMTYw
The Initiating Party would need to base64 decode this string : UElTOjE1NjQzMTYw
The example above results in: {ServiceName}:{paymentId}, i.e. PIS:15643160
Decoupled Flow
Below is a sequence diagram showing a typical decoupled payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).
Embedded Flow
Below is a sequence diagram showing a typical embedded payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).
Flow steering by links
The table below includes every possible step with the corresponding approach. In the response of each request the named link informs about the next request to be sent according to the actual state in the flow.
| SCA approach | Hyperlink name | Hyperlink URL API | Description |
|---|---|---|---|
|
Redirect |
RedirectUrl |
Redirect link Can be white labeled in case Worldline Bank Selection Interface is used |
URL of PSU’s authentication or authorisation on APSPS side, or towards the Initiation Service |
|
Redirect/Embedded/Decoupled |
ConfirmationRequired |
POST /confirmation |
Confirmation of the transaction after authorisation is being done or being exempted. |
|
Redirect/Embedded |
PostAuthorisationForExplicit |
POST /authorisation |
Mostly is being used when multi-sca should be done with Redirect Approach. Nobody required in the request. |
|
Decoupled |
PostIdentificationForDecoupled |
POST /identification |
Requires PSU’s identification at ASPSP for Decoupled Approach. |
|
Embedded |
PreAuthenticationForEmbedded |
POST /pre-auth |
Pre-Authentication is required and will be made with Embedded Approach. |
|
Embedded |
PostAuthorisationForEmbedded |
POST /authorisation |
Start of Authentication with PSU’s credentials at ASPSP. |
|
Embedded |
SelectAuthenticationMethod |
PUT /authorisation |
The update of the authorisation resource where selected SCA method should be provided |
|
Embedded |
AuthorizeTransaction |
PUT /authorisation |
The update of the authorisation resource where challenge response (OTP) should be provided. |
|
Embedded |
PutAuthorisationForEmbedded |
PUT /authorisation |
The update of the authorisation resource with PSU’s credentials, when some other authorisation steps have been done before. |
