Authorisation flow types

Depending on which bank they are paying from, the functionality that your user needs to authorise their payment might be different. These are known as authorisation flow types.

The three types of authorisation flow are:

• redirect
• embedded
• decoupled

If you're using one of our prebuilt UIs for web or mobile, we handle all authorisation flows for you, so you don't need to build anything.

If you build your own authorisation UI, especially in Europe, you need to take all the possible flows into account when you integrate. To do this, use actions. Actions are a sequence of API requests which move you between steps in the authorisation flow. Different flows require different actions to complete the

Redirect flow

The redirect flow is the most common type of user flow for authorisation. It is used by all UK banks.

In a redirect flow:

1. The user begins the payment flow
2. The user is redirected to their provider's website or app
3. The user inputs their bank credentials to authorise the payment
4. The bank redirects the user to the return URI that you set in Console

Embedded flow

The embedded flow is used by some German providers. In an embedded flow, the customer inputs their credentials within the flow rather than being redirected to their bank app or website to log in.

Unless you are regulated as a PISP, to support embedded flows you must use a hosted or embedded payment page, or one of our mobile SDKs.

In an embedded flow:

1. The user begins the payment flow
2. The user inputs their banking credentials within a TrueLayer UI
3. The user completes the payment

Decoupled flow

In a decoupled flow, the user authorises their payment in another app or channel, such as an email or a notification within their bank app. Very few EU providers support a decoupled flow.

The hosted payment page, embedded payment page and mobile SDKs support all auth flows by default. We recommend using these, especially if you are integrating in the EU.

If you are building a direct API integration, you can see which auth flow a provider supports with the /providers endpoint.

In a decoupled flow:

1. The user begins the payment flow
2. The user is shown a screen which tells them to go to a different app or website to complete authorisation
3. The user approves the payment within that other app or website
4. The user goes back to the TrueLayer payment flow to complete the authorisation process