Payment Initiation

Decoupled Model B: ASPSP Generated Identifier

This version is:

Published 4 months ago 07 Apr 2022

Customers will use Open Banking products and services if their experience matches their expectations for ease of use, to inform their financial decisions. So the interface between TPPs and ASPSPs only introduce enough friction to provide the customer with control and trust.

Other Journeys in ‘Payment Initiation’.

User Journey

PSU provides an ASPSP generated unique identifier to the TPP (AISP/PISP/CBPII) which is then passed back to ASPSP to identify the PSU

A decoupled authentication flow where the PSU provides a dynamic identifier generated by the TPP (AISP/PISP/CBPII), which is then used by the ASPSP to identify the PSU through the ASPSP app to authenticate and action the TPP request.

This model is best suited to an ASPSP app that can “capture” the code from the TPP app (e.g. by scanning a QR code). Alternatively, the PSU can be prompted to type in an identifier in the ASPSP App. This may be a long series of characters and may result in a sub-optimal customer experience.

To demonstrate Model C based decoupled we have used one variation of PIS journey (Single Domestic Payments – a/c selection @ PISP) as an example, where the ASPSP receives all the details of the payment order via the code generated by the PISP.

This flow applies to other variations of PIS journeys covered in detail under section Payment Initiation Services (PIS). AISP journeys covered under section Account Information Services (AIS) and CBPII journeys covered under section Card Based Payment Instrument Issuers (CBPIIs).

This content is best viewed on a desktop browser.

1

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

2

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

3

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

4

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

We have illustrated an example where the dynamic identifier is a QR code and is scannable by the TPP. The code generated by the ASPSP is however not limited to QR code. The general guidance is that the code generation with the ASPSP should not introduce friction in the journey.

CEG Checklist Requirements & CX Considerations
CEG Checklist Reference

1

Not shown in the diagram but as in 1 & 2 in Model A.

22

2

Not shown in the diagram but as in 1 & 2 in Model A.

22

3

If PISPs and ASPSPs support Model B then the PISP should provide the PSU information on how the identifier can be generated with their ASPSP and make the PSU aware about how this identifier will be used.

n/a

4

PSUs use the ASPSP app to generate the unique identifier.

6

5

PSUs should be able to easily provide the identifier to the PISP application (e.g. scan the code into the Kiosk in this instance).

n/a

6

After the PSU provides the ASPSP app generated identifier to the PISP, then the ASPSP must display the payment request within the same session of the ASPSP app and clearly mention the amount and the payee.

28

7

ASPSPs must apply SCA which should have no more than the number of steps that the PSU would experience when directly accessing the ASPSP mobile app (biometric, passcode, credentials).

1

8

ASPSPs must make the PSU aware that they have been logged off from the ASPSP app and notify them to check back on the originating PISP app.

n/a

9

The PISP must confirm successful confirmation of payment initiation.

26

“Consumer research has shown that 64% of customers prefer to be shown confirmation that the payment has been received at the TPP. This would provide reassurance that the process has worked.”

Click for customer research