1. Description
...
This user journey requires a Single Use Consent of type Single Refund Consent.
1.1 Payer and Payee Segments
The scope of the Refund bank service initiation related to the segments of When the PSU provides their explicit consent to the PISP to initiate a payment order; the PSU also provides permission for the PISP to request their account details from their ASPSP for the purposes of providing a future refund.
1.1 Payer and Payee Segments
The scope of the Refund bank service initiation related to the segments of payers and payees is shown below:
...
The User buys goods or services from the merchant. Within the agreed period of time and under the terms & conditions, the User requests a refund for goods or services previously purchased. Both agree to a refund and no dispute exists between them (refund as BAU process). The merchant’s TPP initiates a refund payment from the merchant's LFI account with the merchant's consent using the original Transaction ID. This is a return payment order to the PASP..
...
In cases where the PSU selects their account at the ASPSP as shown in the journey Single Domestic Payments – a/c selection @ ASPSP, the PISP may not be able to obtain the PSU’s account details (sort code and account number) from the PSU directly within their consent journey. This could create challenges for the PISP if the PSU requests a refund for the transaction at a later stage. Accordingly, the PISP would need to obtain these details from either from the PSU, the merchant/service provider or the PSU’s ASPSP in order to provide a refund, if requested.
This information gap is solved by modifying the original payment journey Single Domestic Payments – a/c selection @ ASPSP as shown above, which is referred to as Synchronous Refund Information.
During the consent journey, when the PSU provides their explicit consent to the PISP for initiating a payment order; the PSU would simultaneously provide their permission for the PISP to request their account details (for example sort code and account number for domestic payments) from their ASPSP for the purposes of providing a future refund. This consent is included as a flag within the payload which is submitted to the ASPSP as part of the payment initiation request. The ASPSP then returns the payment details to the PISP for each transaction.
3. Wireframes
3.1 Rules & Guidelines
...
# | Step | Rules & Guidelines |
|---|---|---|
SIP-1 | Single Instant Payment Consent | Basic Consent Parameters TPPs MUST: 1.1 Enable Users to provide and review the parameters related to the SIP they need to consent to. These parameters include:
Note: Depending on the use case, the Payee details may not be displayed to Users in full. However, these still need to be part of the payment Consent request sent by the TPP.
|
Additional Consent Parameters TPPs MUST: 1.2 Set the Accepted Authorization Type (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#7.-Accepted-Authorization-Type). 1.3 Set the Authorization Time Window (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#8.-Authorization-Time-Window) if there are specific timing requirements that must be met for the consent authorization. This is also relevant to cases where multiple authorizers are required to authorize the payment consent (Please refer to https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#18.-Multi-User-Authorization-Flow). 1.4 Set the Consent Expiry Date accordingly if the Authorization Time Window is set to more than 1 day. This is to avoid the consent expiring before all necessary authorizations are completed. Otherwise, the default value of the Consent Expiry Date MUST be set to the same day (i..e current day). The Consent Expiry Time MUST always be set to 23:59:59 of the Consent Expiry Date. 1.5 Set the Risk Information Block (as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#9.-Risk-Information-Block) | ||
TPPs MUST: 1.6 Enable Users to provide explicit consent for the initiation of a SIP payment order from their online payment account held at their LFI as per the payment details specified in the payment Consent. | ||
SIP-2 | Consent Staging | |
SIP-3 | Hand-off to LFI | Example wording to use: ‘We will securely transfer to YOUR LFI to authenticate and make the payment“. |
SIP-4 | Authentication | LFI Authentication Only LFIs MUST: 4.1 Enable Users to perform authentication with their LFIs, as per the following sections: 4.2 Re-direct Users back to the TPPs, with information that the Consent has not been authorized, if User Authentication has failed or Users opted to cancel the authentication/authorization process. |
Centralized Authentication and Authorization (Federated) Only 4.3 As per https://openfinanceuae.atlassian.net/wiki/x/HoBBAw | ||
SIP-5 | Confirmation/ Authorization | Standard Journey LFIs MUST: 5.1 Enable Users to authenticate using Multi-Factor Authentication (MFA) in order to review and authorize the Single Instant Payment (SIP) Consent. 5.2 Retrieve from the OFP the Single Instant Payment (SIP) Consent details staged by the TPP using the unique Consent Identifier and present to Users all the details included in this. 5.3 Allow Users to select a payment account for the initiation of the Single Instant Payment (SIP), if this was not provided in the retrieved staged payment Consent details, as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#12.-Payment-Account-Selection-at-LFI
5.4 Check the authorization status of the selected payment account is in accordance with the TPPs' Accepted Authorization Type as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#13.-Check-Accepted-Authorization-Type. 5.5 Add to the Single Instant Payment (SIP) Consent the IBAN of the Payee returned by the Proxy resolution process, if the Single Instant Payment (SIP) Consent was submitted for User Authorization using a Proxy as the Payee Identification. The Consent is thereafter tied to the IBAN of the Payee rather than the proxy itself.
5.6 Present to Users the following minimum required information for authorizing the Single Instant Payment (SIP) Consent:
5.7 Request Users to authorize the Single Instant Payment (SIP) Consent, so that a single instant payment can be initiated. 5.8 Provide Users the ability to abort the payment journey, if Users decided to terminate the request. The LFI MUST hand-off the Users back to the TPP, providing the necessary error message to the OFP and reject the Single Instant Payment (SIP) Consent. 5.9 Check the Authorization Time window is valid as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70092902/Common+Rules+and+Guidelines#20.-Check-Authorization-Time-Window 5.10 Change the state of the Single Instant Payment (SIP) Consent from Awaiting Authorization to Authorized, when all Authorizers (one or more) have authorized the payment Consent. 5.11 Update the Single Instant Payment (SIP) Consent details stored in the OFP with all the information included in the Single Instant Payment (SIP) Consent authorized by the User. |
LFIs MUST: 5.2.1 Display as minimum the Payment Amount, Currency and the Payee Account Name to make the User aware of these details. 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):
5.2.2 Display the balance of Users payment account (not shown on the user journey) as part of the authentication journey on any of the aforementioned screens (stated in 5.2.1), in the case that Users are redirected to authenticate using an app (thus meeting 1 authentication factoer). Displaying the balance in this instance need not require any additional strong customer authentication. Displaying the balance is other cases is optionaly for LFIs. 5.2.3 Allow the same minimum and maximum payment limits, as they offer in the Standard Journey and their other direct online channels. 5.2.4 Inform Users 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 User the ability to view the details of the payment that needs to be authorized. | ||
OFP MUST: 5.12 Confirm back to the LFIs that the Single Instant Payment (SIP) Consent details have been updated successfully. | ||
Multi-Authorization Journey Only | ||
SIP-6 | Payment Initiation | LFIs MUST: 6.1 Trigger the payment initiation process for the payment Consent immediately after the Single Instant Payment (SIP) Consent has been fully authorized by all required authorizers (one or more). 6.2 Additionally apply all existing BAU payment account controls and limits such as single transaction value limit, total transaction value limit, AML checking (if applicable) and others, as if the payment request has been initiated by the existing channels of the LFI. LFIs MUST send an appropriate error response to the OFP in case the payment is rejected due to violating any of these limits. 6.3 Reject the payment initiation if the payment account selected for the payment has insufficient funds. The OFP MUST be notified about this rejection with an appropriate error message. 6.4 Subject to successful BAU checking, validation and payment processing, proceed with the execution of the payment by either submitting the payment to the underlying payment rails or executing internally as Intra-bank payment. 6.5 Provide the OFP with all the available information in relation to the initiated payment instruction including the payment’s unique identifier Payment Transaction ID. The format of the Payment Transaction ID can be found in the UAE Open Finance Standard specifications. 6.6 Ensure that the Payment Reference provided in the Single Instant Payment (SIP) Consent is made available to the Beneficiary’s account information in the case of Intra-bank payments within the same LFI. |
OFP MUST: 6.7 Return back to the TPP in the Single Instant Payment (SIP) Consent response the IBAN of the Payee identification returned by the Proxy resolution, if the Single Instant Payment (SIP) Consent was submitted for User Authorization using a Proxy as the Payee Identification. 6.8 Send an appropriate error response to the TPPs in case the payment is rejected due to violating any of the LFIs BAU payment accounts checks or limits. 6.9 Send to the TPP the appropriate error message in case the payment initiation was rejected by the LFI due to insufficient funds in the selected payment account. 6.10 Provide the TPP with all the available information in relation to the initiated Single Instant Payment (SIP) instruction including the payment’s unique identifier Payment Transaction ID. | ||
SIP-7 | Payment Status Update | |
SIP-8 | Hand-off back to the TPP | |
SIP-9 | Confirmation to User |
|
TPPs MUST: 9.2.1 Display to Users the information received from the LFIs. This information may include:
9.2.2 Display any of the following information regarding initiation and execution of the payment, if received by the LFIs:
| ||
SIP-10 | Payment Notifications |
4. Fulfilment of Refund Payments
The fulfilment of the refund payment itself can be achieved using a number of different models and depends on a number of options, including the business model and the contractual agreement between the merchant/service provider and the PISP, their systems capabilities and the way they integrate together. In addition to existing or new business processes at the merchant/service provider’s side.
The Open Banking Standards are aimed at supporting the communication between PISPs and ASPSPs, but they do not define the parameters of the relationship and the mechanisms used between the merchant/service provider and the PISP, in relation to refunds. However, as part of the industry research OBL was conducting for the purpose of refund payments, we have included models that are being considered within the industry today. These models reflected below are intended to be illustrative only. Entities wishing to engage in these types of models will need to ensure that they have appropriate regulatory permissions and meet applicable regulatory obligations.
The following are some example of potential models:
Example 1: Merchant/Service Provider receives PSU account details from Merchant ASPSP
Example 2: Organisation with appropriate authorisation to hold funds, offers “merchant account” to Merchant/Service Provider
Example 3: Organisation with appropriate authorisation to hold funds, offers “refunds account” to Merchant/Service Provider
Example 4: Use of Open Banking APIs to initiate refund payments from the merchant/service provider’s ASPSP account
Example 5: Use of the Merchant/Service Provider’s ASPSP host-to-host solution – (Under consideration)
Example 6: Use of ‘assisted’/’shared’ SCA model for Refund Payments – (Under consideration)
For more information in relation to these models, please refer to section Refund Payment Fulfilment. in the appendices.
Note 1: As refunds are expected to be fulfilled with new payments to the PSUs’ debit accounts with the same payment reference, initiating a partial refunds is simply using a different amount for the payment. If multiple partial refunds are to be initiated at different points in time, then it is in the responsibility of the Merchant to reconcile these so that they much their total payment amounts or not.
Note 2: The refund payment (initiated by the PISP, the multi-licensed organisation or the merchant depending on fulfilment model used) should be clearly identified in order to allow easy identification and reconciliation by the PSU. Thus, in addition to using the same payee payment reference (i.e. the 18 character field) as the original payment, where possible, the refund transaction payment reference could also be preceded with the identifier ‘REF ‘ or ‘REFUND ‘ as a prefix, to easily allow the payment to be identified as a refund. Please note however, that due to the limitation of this fields to 18 character across payment systems, the prefix should be used without truncating the original payment reference as this could make reconciliation of the refund payment against the original transaction more difficult.
7.2 Single Refund Payment Consent
...