Redirection with TPP Generated QR code

PSU uses a TPP (AISP/PISP/CBPII) generated QR code to redirect to their ASPSP app on a different device

User Journey

It is well known that desktop browser journeys that require the PSU to authenticate on their ASPSP desktop website have significantly lower consent success rates than app-to-app redirection. As a result, it is becoming increasingly common in the market for TPPs to provide PSUs using a desktop browser with a way to authenticate using their ASPSP mobile app.

This is a variant of a decoupled redirection flow whereby a TPP presents the PSU with a QR code as an identifier. This allows the TPP to redirect the PSU from a desktop browser to their ASPSP’s mobile app to authenticate.

The TPP generates a QR code on the desktop prior to redirection. The PSU scans this using a smartphone camera on a device that has the ASPSP mobile app installed. Once the QR code is scanned, the PSU is redirected to the ASPSP app for authentication. Note that the TPP still offers the PSU the option to continue the desktop browser authentication journey in the event they do not wish to use their ASPSP app e.g. they do not use mobile banking or do not have their device to hand.

This model does not require any implementation on the ASPSP side for the decoupled redirection to work. However, it is recommended that the TPP creates a seamless experience whereby the desktop automatically refreshes once the PSU has authenticated on their mobile app. It is also recommended that TPPs prevent mobile-browser interstitials from being generated where possible.

Wireframes

This journey demonstrates decoupled redirection where the journey starts on a desktop allowing the PSU to smoothly redirect to their ASPSP app on another device.

We have used the (Single Domestic Payments – a/c selection @ ASPSP) as an example, where the PSU starts the journey on a desktop browser and scans the QR code using a smartphone with their ASPSP app installed. This redirects the PSU to their ASPSP app to complete authentication on a mobile device.

This flow can be used for all Payment Initiation Services (PIS), Account Information Services (AIS) and  Card Based Payment Instrument Issuers (CBPIIs) journeys. As a general rule, this journey is designed to reduce rather than increase friction to the customer journey and should be designed and tested to ensure this is the case.

CEG Checklist Requirements 1

For this step, please refer Section Single Domestic Payments – a/c selection @ PISP), step 1 & step 2.

CX Considerations 2

If PISPs support this model then they must display QR code generated in the browser to the PSU and information on how the PSU can scan the QR code on another device.

CX Considerations 3

PSUs should be able to easily use the QR code presented by the PISP application (e.g. scan the code on their mobile device from the Desktop in this instance) without much friction (e.g manually entering an alphanumeric code).

CEG Checklist Requirements 4

After the PSU scans the QR code on their mobile device, the PSU must be automatically redirected to their ASPSP mobile app to authenticate and complete the journey.

ASPSPs performs SCA. The ASPSP app-based authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP mobile app (biometric, passcode, credentials).

CEG Checklist Requirements 5

Additional Parameters

ASPSPs must allow PSUs to select the payment account to complete the payment order for execution.

It is up to ASPSP to consider relevant obligations relating to the FCA’s High-Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42) & (PS19/16)”.

The ASPSP must display the payment request and clearly mention the amount and the payee and payment account.

CX Considerations 6

ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after pressing the Proceed button. Example wording: “Press Proceed to make payment“.

CEG Checklist Requirements 7

PISP Confirmation: As per Single Domestic Payments – a/c selection @ PISP, item #10.

We have illustrated an example where the TPP generated QR code is scannable by the PSU on mobile device.  The general guidance is that the use of the code within the journey should not introduce friction in the journey.

CEG Checklist Requirements & CX Considerations

For this step, please refer Section Single Domestic Payments – a/c selection @ PISP), step 1 & step 2.

22 & 24

If PISPs support this model then they must display QR code generated in the browser to the PSU and information on how the PSU can scan the QR code on another device.

PSUs should be able to easily use the QR code presented by the PISP application (e.g. scan the code on their mobile device from the Desktop in this instance) without much friction (e.g manually entering an alphanumeric code).

After the PSU scans the QR code on their mobile device, the PSU must be automatically redirected to their ASPSP mobile app to authenticate and complete the journey.

ASPSPs performs  SCA. The ASPSP app-based authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP mobile app (biometric, passcode, credentials).

1

Additional Parameters

ASPSPs must allow PSUs to select the payment account to complete the payment order for execution.

It is up to ASPSP to consider relevant obligations relating to the FCA’s High-Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42) & (PS19/16)”.

The ASPSP must display the payment request and clearly mention the amount and the payee and payment account.

23

ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after pressing the Proceed button. Example wording: “Press Proceed to make payment“.

What the research says

Click for Customer Research