SafeConnect PIS UX Guidelines

Yapily guidelines for SafeConnect PIS UX

Any PIS authorisation is a request to initiate a payment from the PSU's bank. Unlike an AIS authorisation, the authorisation generate a consent that can only be used once and only for the payment requests used in the authorisation.

Step 1: Capture the Payment Intent

Within your application, you will need a way to capture the PSU's intent to initiate an open banking payment e.g. a button or menu item with the text "pay" or "new payment".

Step 2: Capture the Payer Bank

Present the PSU with the option to select which bank they wish to make the payment from. If the PSU has already added an account through the AIS journey and they wish to use this existing account, the bank selection process can be bypassed.

This screen does not need to be branded with SafeConnect

Step 3: Display the Payment Request Summary

The following guidelines have been raised by the OBIE in relation to the details that need to be presented to the PSU when building up the payment request.

Capturing the payment details

The TPP must either allow PSUs to specify the following payment details or pre-populate them for the PSUs:

  • The payment amount and currency
  • The payee account name
  • The payee account identification details (e.g. account number and sort code or additionally roll number or full IBAN)
  • The payment reference (this is optional but it is good practice to be populated for a payment)

In certain scenarios, the PSU's payer account identification details (e.g. account name, account number and sort code) are required in order to initiate the payment authorisation request. In order to specify this information, the TPP must provide PSUs at least one of the following options:

  • Enter their payer account identification details for the payment
  • Select their payer account identification details assuming that they have been saved previously
  • Select their ASPSP in order to select their PSU payment Account from there later on in the journey

Displaying the authorisation summary

The key SafeConnect requirement is that the PSU is made aware who SafeConnect is, with appropriate logos and legal details, before being redirected to their bank. This will help assure the PSU when they see SafeConnect as the entity requesting to initiate the payment on their bank screens (and why it's not the TPP who is providing the service they are using) along with all of the relevant details should they wish to cancel the consent or understand who SafeConnect is and our legal responsibilities.

The TPP must clearly display the following information to the PSU summarising the payment authorisation request before redirecting to the bank:

  • The payment amount and currency
  • The payee account name
  • The payer account identification details and/or the bank (if specified)
  • The payment reference (if specified by the PSU or the TPP)

Consider the following for both Payee and Payer account identification details (e.g. account number and sort code or additionally roll number or full IBAN):

For the Payer account identification details:

  • If this has been input by the PSU, then the TPP must also display this in the authorisation request summary screen to allow the PSU to verify its correctness
  • If this has been pre-populated by a previous action by the PSU to link the account, the TPP can decide whether to display this or not
  • If this has been pre-populated and the TPP decides to display this information, this should be masked

For the Payee account identification details:

  • If this has been input by the PSU, then the TPP must also display this in the authorisation request summary screen to allow the PSU to verify its correctness
  • If this has been pre-populated by the TPP (e.g. in a eCommerce payment scenario), the TPP can choose whether to display this information or not

Payment Type Considerations

Select an applicable payment type below for examples of how to display the payment request summary:

Step 4: PSU Authenticates with the Bank

The PSU is redirected to their bank (through the browser or the corresponding online banking mobile app) and neither Yapily or the TPP can control this part of the flow. The PSU is asked to login using the same credentials as their online banking which can be any combination of SCA e.g. fingerprint scanning, face ID, temporary codes or secure passwords/pass-phrases.

Step 5: PSU Selects an Account

The bank will request the user to select an account if the payer is not specified. If the payer account is specified, the PSU will typically be taken directly to the Step 6.

Step 6: PSU Redirected Back to TPP

Now that the PSU is authenticated, they will be prompted to authorise the payment request SafeConnect is making on behalf of the TPP. Once the PSU authorises (or rejects the request), the bank session will automatically close and the PSU will be redirected to the redirect url configured for the application within Yapily.

Step 7: Display Payment Confirmation

TPPs must display the information received from the ASPSP. This information may include:

  • The unique identifier assigned to the payment instruction by ASPSPs
  • The payment status (and status update date & time) - Confirmation of successful payment initiation if received by ASPSPs, TPPs must display any of the following information regarding initiation and execution of the payment:
  • The expected payment execution date & time.
  • The expected settlement date & time (i.e. the value date of the payment).
  • The ASPSP charges (where applicable).

This confirmation screen does not need to have SafeConnect branding.

OBIE Standards do not currently support the amendment or cancellation of Domestic Standing Orders (Domestic Periodic Payments) or Future Dated Payments (Scheduled Payments) via PISPs. Once initiated the PSU will need to contact their bank to make changes to it. Cancellation of these payments must be consistent with available capabilities on ASPSP's existing online platform, as well as, in accordance with the provisions of the PSRs relating to revocation of payment orders