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 Account Selection at PISP Account Selection at PISP – Supplementary Info Account Selection at ASPSP Scheduled Payments – Future Dated Standing Orders International Payments Bulk / Batch Payments Multi-authorisation Payments Confirmation of Funds for PISPs Payment Refunds VRP Payments with SCA exemption VRP Payments under Sweeping Access VRP Payments with delegated SCA
This content is best viewed on a desktop browser. 1 CEG Checklist Requirements 1Minimum 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 2PSU 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 OBIE 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 OBIE standards and offering their services in the UK. 3 CEG Checklist Requirements 3PSU 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. 4 CX Considerations 4PISPs should provide messaging to inform PSUs that they will be taken to their ASPSPs to complete the payment. Example wording: %22We will securely transfer to YOUR ASPSP to authenticate and make the payment“. 5 CX Considerations 5Generic PISP to ASPSP redirection screen and message. Please refer to Sections Browser based redirection – PIS, App based redirection – PIS and Effective use of redirection screens. 6 CEG Checklist Requirements 6ASPSPs 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) 7 CX Considerations 7ASPSPs 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: %22Authenticate 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 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 CEG Checklist Requirements 8SCA 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. 9 CX Considerations 9Generic ASPSP to PISP redirection screen and message. Please refer to Section Effective use of redirection screens. 10 CEG Checklist Requirements 10PISP 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). 11 CX Considerations 11If 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 Using an available exemption with a customer identifier. 12 CEG Checklist Requirements 12Further 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. Select to scroll left Select to scroll right
CEG Checklist Requirements & Customer Experience Considerations 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 OBIE 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 OBIE standards 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 4 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“. 5 Generic PISP to ASPSP redirection screen and message. Please refer to sections Browser based redirection – PIS, App 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 7 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: ASPSPs’ Authentication screen. ASPSP to PISP redirection screen. Displaying the balance in this instance need not require any additional strong customer authentication. ASPSPs must ensure that they comply with their obligations relating to the FCA’s High Cost Credit Review: Overdrafts consultation paper and policy statement (CP18/42). 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 9 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 11 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
Payment Initiation Services Previous Related articles Please select API specifications Domestic Payments Consents Domestic Payments Domestic Payment Usage Examples Account Selection at PISP – Supplementary Info Next