Page Comparison

S. No.

Requirements and Considerations

 Participant

Implementation Requirements

1

Minimum Set of Parameters

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

• Payment Amount and Currency (BHD for Bahrain implementations)

• Payee Account Name

• Payee Account Identification details (e.g. IBAN, PAN)

• Payment Reference (optional)

 PISP

 Required

2

User/Customer payment Account Selection

PISPs must provide User/Customers at least one of the following options:

• Enter their Payer's payment Account Identification details

• Select their Account Identification details (this assumes they have been saved previously and a user/customer is required to verify/authorize the account identification details in a PISP before storing it in PISP)

 PISP

 Required

3

User/Customer Consent to PISP

PISPs must request for the User/Customers' consent to the payment initiation in a clear and specific manner. PISPs must display the following information in the consent screen:

• Payment Amount and Currency (BHD for Bahrain  implementations)

• Payee Account Name

• Payment Reference, if it has been entered by User/Customers or prepopulated by PISPs in item #1

• User/Customer payment Account Identification

o    Note 1: if User/Customer payment Account identification is selected in item #2, PISPs should mask the User/Customer payment Account details on the consent screen. Otherwise, or if the User/Customer payment Account identification has been input by User/Customers in item #2, PISPs should not mask these details to allow User/Customers to check and verify correctness

o    Note 2: if User/Customer payment Account identification is provided by User/Customers in item #2, PISPs may use this to identify and display the ASPSP without having to ask User/Customer

For Payee Account Identification details (e.g. IBAN, PAN):

• If this has been provided by User/Customers in item #1, then PISPs must also display this in the consent screen to allow User/Customers to check and verify correctness

• If this has been pre-populated by PISPs (e.g. in an e-commerce payment scenario) PISPs may choose whether to display this information or not

• PISPs must provide messaging to inform User/Customers that they will be taken to their ASPSPs to complete the payment

Example wording: "You will be securely transferred to your ASPSP to authenticate and make the payment"

PISP

Required

4

CX consideration:

• Generic PISP to ASPSP redirection screen and message

SCA-Strong Customer Authentication

ASPSPs must apply SCA, unless an exemption applies

The ASPSP authentication must have no more than the number of steps that the User/Customer would experience when directly accessing the ASPSP channel

ASPSP

Required

5

Additional Supplementary Information

ASPSPs must be able to introduce a step as part of the authentication journey to display supplementary information associated with that payment if required

ASPSPs must display to User/Customers all the payment instruction information received from PISPs together with the supplementary information. This information may include the following:

• Payment Amount and Currency (BHD for Bahrain implementations)

• Payee Account Name

• Payment Reference, if it has been entered by User/Customers or prepopulated by PISPs in item #1

• User/Customer payment Account Identification

ASPSPs must allow User/Customers to review as a part of the authentication process any supplementary Information. The User/Customer can either proceed with the payment or cancel it on the same screen with supplementary information details, using options with "equal prominence“

CX consideration:

• ASPSPs should inform User/Customers 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"

• Generic ASPSP to PISP redirection screen and message

ASPSP

Required

6

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 from ASPSP, PISPs must display the following additional information:

• The expected payment execution date & time

• The expected settlement date & time (i.e. the value date of the payment)

• The ASPSP charges (where applicable)

In case of payment cancellation,

PISP may update the User/Customer with reason for payment cancellation. The payment cancellation might be due to technical or non-technical scenarios. The messaging format for technical scenario may be simplified to make it easy for User/Customer to understand. Non-technical reasons such as fund availability, incorrect payee information, etc. may be detailed out.

CX consideration:

If User/Customers provide their payment account identification details (as per item #2 options), the PISP may, with the consent of the User/Customer, save the account details for future transactions (such as making further payments or initiating refunds back to User/Customers) where this is part of the payment initiation service explicitly requested by the User/Customer. For example, a merchant, upon request from the User/Customer, may initiate a refund back to the User/Customer, by instructing the same PISP that initiated the initial User/Customer transaction to use the saved User/Customer payment account identification details as the beneficiary details for the refund. This will be dependent on the same PISP being used by both the User/Customer and the merchant, their specific contractual terms and the existing regulations

PISP

Required

7

Further Payment Status Update

PISPs must follow up with ASPSPs in order to check and update the User/Customers with the most updated information that can be received by ASPSPs in relation to the execution of the payment

PISP

Required