Payment authorisation basics

An introduction to payment authorisation and TrueLayer's tools for building an effective user flow.

What is payment authorisation?

After you create a payment, you must enable your user to authorise it.

In this process, the user is typically prompted to the bank and account they want to pay from. They then give consent for TrueLayer to make open banking payments from the chosen bank account.

This applies to all pay-ins. A user must also authorise a mandate, but does not authorise subsequent payments on that mandate. A user does not authorise payouts or refunds.

Overview of an authorisation flow

The authorisation flow starts as soon as the user has begun the payment at checkout. Within the auth flow:

  1. The user selects the provider they want to pay with in a provider selection screen, if applicable.
  2. The user selects the scheme they want to pay with, if applicable.
  3. The user inputs any additional information the provider needs for them to complete the payment, for example an IBAN or a branch name.
  4. The user is redirected to their provider to log in with their banking credentials.
  5. The user gives explicit consent for the payment.
  6. The user is redirected to a page that you choose, which confirms whether the payment succeeded or failed.

Below is an example of an authorisation flow where the user can select their provider, and logs in to their provider with face recognition.

An example of a payment flow, where a user specifies the payment value, selects their bank, and authorises the payment with the bank they selected.

An example of a payment flow, where a user specifies the payment value, selects their bank, and authorises the payment with the bank they selected.

Which authorisation UI should I use?

The authorisation UIs you should use depends on a variety of factors such as:

  • Whether you can accommodate a complex integration.
  • How quickly you need to go live.
  • If you already use an ecommerce platform that TrueLayer offers a plugin for.
  • Whether you have a mobile app, and whether it supports using our SDKs.
This flow shows which authorisation UI you should use based on what integration options you support.

This flow shows which authorisation UI you should use based on what integration options you support.

Generally, we recommend the embedded payment page (EPP) if your website can use an SDK. This displays as part of your site, and supports all payment requirements across different regions.

The hosted payment page (HPP) is very simple to integrate, as you just need to redirect your users to a page to authorise the payment.

The simplest integration paths are to use payment links, or an ecommerce plugin if you use the associated ecommerce platform.

Our mobile SDKs offer a seamless integration with Android, iOS, and React Native applications. However, you can use the HPP or EPP in a mobile app too.

🚧

You can build a direct API integration to completely whitelabel your integration, but this is far more complex than other integration options.

Authorisation flow UI options

This table provides an overview of the three main types of authorisation UI: web, mobile, and direct API integration.

Web authorisation UIsMobile SDKsDirect API integration
DescriptionFully functional web UIs for accepting payments.Prebuilt UIs for iOS, Android, and React Native.Directly integrating with Payments by configuring authorisation flow actions.
Why choose this?All providers and countries supported out of the box, with new ones added by default (no additional integration needed).

UIs designed to be compliant and drive conversion rate.

New features and improvements require no or minimal integration.
All providers and countries supported out of the box, with new ones added by default (no additional integration needed).

UIs designed to be compliant and drive conversion rate.

New features require minimal integration.
We do not generally recommend this option, but you can completely white-label your user flow this way.