Payment Flows

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.