Single Domestic Payment

Account Selection at PISP

This version is:

This is the latest version Published 5 months ago 28 Jun 2024

Where all information for a complete payment order is passed from PISPs to ASPSPs, once authenticated, PSUs must be directed back to the PISP domain without any further steps taking place in the ASPSP domain.

Other pages in this section


User Journey

Main content image

PSUs can initiate, by providing their consent to PISPs, an instruction to their ASPSPs to make a one-off payment for a specific amount to a specific payee.

Where all information for a complete payment order (including the PSUs’ account details) is passed from PISPs to ASPSPs, once PSUs have been authenticated, PSUs must be directed back to the PISP domain without any further steps taking place in the ASPSP domain.

This excludes the cases where supplementary information is required to be provided to PSUs as described in section Single Domestic Payments – Supplementary info. 

Wireframes

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
Minimum Set of Parameters PISPs must either allow PSUs to specify the below minimum set of parameters or pre-populate them for the PSUs: Payment Amount and Currency (GBP for UK implementations). Payee Account Name. Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN). Payment Reference – This is optional but it is good practice to be populated for a payment. Any supplementary information required which the ASPSP has published as required and is specific to that ASPSP.

2

CEG Checklist Requirements 2
PSU payment Account Selection PISPs must provide PSUs at least one of the following options: Enter their Payer’s payment Account Identification details. PISPs must allow PSUs to enter their payment Account Identification details in at least one of the ways specified in the Open Banking V3 Read/Write API Specifications (e.g. account number and sort code – with additional roll number if required, IBAN, PAN, Paym and other formats). Select their Account Identification details (this assumes they have been saved previously). Select their ASPSP in order to select their PSU payment Account from there later on in the journey. Note 1: In some of the above cases, PISPs may also need PSUs to provide their ASPSP name so that PISPs can check whether ASPSPs will be able to match the account identifier to the underlying PSU payment account. Note 2: The use of IBAN as an identification of the payer account for UK ASPSPs is not expected to be heavily used as account and sort code are the main account identifiers used in the UK. IBAN however will be used by non UK ASPSPs implementing OBL standards and offering their services in the UK.

3

CEG Checklist Requirements 3
PSU Consent to PISP PISPs must request for the PSUs’ consent to the payment in a clear and specific manner. PISPs must display the following information in the consent screen: •Payment Amount and Currency (GBP for UK implementations). •Payee Account Name. •Payment Reference, and any supplementary info, if it has been entered by PSUs or pre-populated by PISPs in item #1. •PSU payment Account Identification and/or the selected ASPSP (based on item #2 options). •Note: if PSU payment Account identification is provided by PSUs in item #2, PISPs could use this to identify and display the ASPSP without having to ask PSUs. For Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN): •If this has been provided by PSUs in item #1, then PISPs must also display this in the consent screen to allow PSUs to check and verify correctness. •If this has been pre-populated by PISPs (e.g. in a eCommerce payment scenario) PISPs could choose whether to display this information or not.

6

CEG Checklist Requirements 6
ASPSPs must display as minimum the Payment Amount, Currency and the Payee Account Name to make the PSU aware of these details (unless an SCA exemption is being applied). These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info. ASPSPs’ Authentication screen (recommended). ASPSP to PISP redirection screen These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section 4.1.2)

8

CEG Checklist Requirements 8
SCA Authentication (including dynamic linking) must be the only action required at the ASPSPs (unless supplementary information required, refer to section Single Domestic Payments – Supplementary info). The ASPSP authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP channel.

10

CEG Checklist Requirements 10
PISP Confirmation PISPs 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, PISPs 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).

12

CEG Checklist Requirements 12
Further Payment Status Update PISPs should follow up with ASPSPs in order to check and update the PSUs with the most updated information that can be received by ASPSPs in relation to the execution of the payment. For more details on Payment Status, please also refer to section Payment Status.

CEG Checklist Requirements & Customer Experience Considerations
CEG Checklist Reference

1

Minimum Set of Parameters

PISPs must either allow PSUs to specify the below minimum set of parameters or pre-populate them for the PSUs:

• Payment Amount and Currency (GBP for UK implementations).
• Payee Account Name.
• Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN).
• Payment Reference – This is optional but it is good practice to be populated for a payment.
• Any supplementary information required which the ASPSP has published as required and is specific to that ASPSP.

22

2

PSU payment Account Selection

PISPs must provide PSUs at least one of the following options:

  • Enter their Payer’s payment Account Identification details.
  • PISPs must allow PSUs to enter their payment Account Identification details in at least one of the ways specified in the Open Banking Standard V3 Read/Write API Specifications (e.g. account number and sort code – with additional roll number if required, IBAN, PAN, Paym and other formats).
  • Select their Account Identification details (this assumes they have been saved previously).
  • Select their ASPSP in order to select their PSU payment Account from there later on in the journey.

Note: In some of the above cases, PISPs may also need PSUs to provide their ASPSP name so that PISPs can check whether ASPSPs will be able to match the account identifier to the underlying PSU payment account. Note 2: The use of IBAN as an identification of the payer account for UK ASPSPs is not expected to be heavily used as account and sortcode are the main account identifiers used in the UK. IBAN however will be used by non UK ASPSPs implementing Open Banking Standard and offering their services in the UK. 

24

3

PSU Consent to PISP 

PISPs must request for the PSUs’ consent to the payment in a clear and specific manner. PISPs must display the following information in the consent screen:

• Payment Amount and Currency (GBP for UK implementations).
• Payee Account Name.
• Payment Reference, and any supplementary info, if it has been entered by PSUs or pre-populated by PISPs in item 1.
• PSU payment Account Identification and/or the selected ASPSP (based on item 2 options).

Note: if PSU payment Account identification is provided by PSUs in item 2, PISPs could use this to identify and display the ASPSP without having to ask PSUs.

For Payee Account Identification details (e.g. account number and sort code or additionally roll number or full IBAN):

• If this has been provided by PSUs in item 1, then PISPs must also display this in the consent screen to allow PSUs to check and verify correctness.
• If this has been pre-populated by PISPs (e.g. in a eCommerce payment scenario) PISPs could choose whether to display this information or not.

8

PISPs should provide messaging to inform PSUs that they will be taken to their ASPSPs to complete the payment.

Example wording: ‘We will securely transfer to YOUR ASPSP to authenticate and make the payment“.

Generic PISP to ASPSP redirection screen and message. Please refer to sections Browser based redirection – PISApp based redirection – PIS and Effective use of redirection screens.

6

ASPSPs must display as minimum the Payment Amount, Currency and the Payee Account Name to make the PSU aware of these details (unless an SCA exemption is being applied). These details must be displayed as part of the authentication journey on at least one of the following screens without introducing additional confirmation screens (unless supplementary information is required, refer to section Single Domestic Payments – Supplementary info.

  • ASPSPs’ Authentication screen (recommended).
  • ASPSP to PISP redirection screen

28

6a

ASPSPs must offer the same minimum and maximum payment limits for payment types, as they offer in their direct online channels.

28f

  • ASPSPs should inform PSUs about their “point of no return” for making the payment and that their payment will be made after authentication occurs. Example wording: ‘Authenticate to make payment”.
  • For recognition based biometrics (e.g. Face ID) which can be more immediate the biometric authentication should be invoked after a delay or through a call to action to allow the PSU the ability to view the details.
  • ASPSPs could display the balance of PSUs payment account (not shown on the user journey) as part of the authentication journey on any of the following screens:
  1. ASPSPs’ Authentication screen.
  2. ASPSP to PISP redirection screen.

Displaying the balance in this instance need not require any additional strong customer authentication.

8

SCA Authentication (including dynamic linking) must be the only action required at the ASPSPs (unless supplementary information required, refer to section Single Domestic Payments – Supplementary info. The ASPSP authentication must have no more than the number of steps that the PSU would experience when directly accessing the ASPSP channel.

19 1

Generic ASPSP to PISP redirection screen and message. Please refer to section Effective use of redirection screens.

10

PISP Confirmation 

PISPs 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, PISPs 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).

25 26

If PSUs provide their payment account identification details (as per item #2 options), the PISP could, with the consent of the PSU, save the account details for future transactions (such as making further payments or initiating refunds back to PSUs) where this is part of the payment initiation service explicitly requested by the PSU. For example, a merchant, upon request from the PSU, may initiate a refund back to the PSU, by instructing the same  PISP that initiated the initial PSU transaction to use the saved PSU payment account identification details as the beneficiary details for the refund. This will be dependant on the same  PISP being used by both the PSU and the merchant, their specific contractual terms and relevant regulatory obligations under GDPR/PSRs. Moreover, PISPs can use this consent to provide a hint of the PSU’s identity using the customer identifier as part of the payment request  to enable the subsequent payment journey contemplated in section Using an available exemption with a customer identifier.

12

Further Payment Status Update PISPs should follow up with ASPSPs in order to check and update the PSUs with the most updated information that can be received by ASPSPs in relation to the execution of the payment. For more details on Payment Status, please also refer to section Payment Status.

27

Note

This core journey will result in a single domestic payment which will be processed by the ASPSPs as a Single Immediate Payment (SIP) via Faster Payments. Single domestic payments through other payment schemes can be initiated as described in section Single Domestic Payments – BACS and CHAPS.

What the research says

“Consumer research has shown that 64% of customersprefer 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