1. Description
This bank service functionality enables original payees (or their TPPs) to refund payers (i.e. Users), where the original payees are merchants receiving payments for purchase of goods/services. The Refund capability relates to Open Finance TPP initiated payments, and is required as a result of the merchants' commercial relationships with customer (i.e. Users). The Open Finance Refunds functionality does not cover payment refunds for unauthorized, defective, late or non-executed payment transactions. Instead, it enables merchants (or their TPPs) to refund payers (i.e. Users) with the payment amounts (full or partial) when both payer and a payee (merchant) have agreed the refund and no dispute exists between them.
The Refunds scope is targeted to domestic payee accounts (i.e. payee accounts offered by LFIs located in UAE) and payments in local currency as used by the local payment systems infrastructure for domestic payments.
The Refunds capabilty allows merchants (or their TPPs) to acquire the payers' bank account details used to make the original payment. The Refund is then fullfiled by the merchants (or their TPPs) using any of their preferred or existing BAU payment methods.
1.1 Payer and Payee Segments
The scope of the Refunds functionality related to the segments of payers and payees is shown below:
Payer (Merchant) | Payee (Customer) | ||||
|---|---|---|---|---|---|
Consumers | SME | Corporates | Consumers | SME | Corporates |
|
|
|
|
|
|
1.2 Refund - Example User Story
User Story
As a User (Business or Corporate),
I want to be able to initiate a partial or full refund of a payment received via an Open Finance,
so that I can fulfil the requirement to refund customers in case of returns and undisputed complaints for goods or services.
2. User Journey
2.1 Pre-conditions
The User buys goods or services from the merchant. Within the agreed period of time and under the terms & conditions in relation to the commercial transaction, the User requests a refund for the goods or services previously purchased from the mercahnt. Both User and Merchant agree to a refund and no dispute exists between them, thus making the refund part of a BAU process.
2.2 Original Payment Account selected at TPP
In cases where Users provided their payment account (or payment proxy) to a TPP for initiating Open Finance payments to a merchant for the purchase of goods or services, the TPP has all the available information required to facilitate the merchants' refund payments, when requested by Users. The TPP can provide to the merchant the original payment details including the payment amount, payments account details, payment reference, date and transaction ID. The merchant can then use this information to initiate refund payments as new credit transfers using their existing BAU processes. For more details, please refer to section https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1draft3/pages/70811733/Payment+Refunds#5.-Fulfilment-of-Refund-Payments.
2.3 Original Payment Account selected at LFI
However, in cases where Users select their account at the LFI, the TPP is does not obtain the Users' payment account details from the Users directly within their Consent journey. This creates challenges for the TPP when Users request refunds for their transaction at a later stage. Accordingly, the TPP would need to obtain these details from either from the Users, the merchants or the User’s LFIs in order to facilitate a refund, if requested.
This information gap is solved by modifying the original payment journey of the Single Instant Payment as shown below, which is referred to as Asynchronous Refund Information.
During the payment Consent journey, when the User provides explicit consent to the TPP for initiating a payment order, the User simultaneously provides their permission for the TPP to request the payment account details from their LFI for the purposes of providing a refund, if required in the future. This permission is included as a flag within the payment Consent payload which is submitted to the LFI as part of the payment initiation request. When a refund is required, the TPP will request the User’s payment account details from the LFI and the LFI will respond providing the details so that the refund for the transaction can be fulfilled.
Similarly for the Consent of the Multi-Payments payment jounrey.
3. Wireframes
3.1 Consent Setup
# | Step | Rules & Guidelines |
|---|---|---|
REF-1 | Single Instant Payment Consent with Refund Permission | |
User Consent to TPP In addition to Users’ consent to the payment initiation: TPPs MUST: 1.1 Request Users' explicit consent before they are able to request the Users' payment account details from the LFI for the purpose of refunds, as part of the payment initiation process. 1.2 Present the User consent for payment initiation and Asynchronous Refund Information in a single step. 1.3 Make it clear to Users that they will share these details with the payee or use the details for refund processing, if the User requests and agrees a refund with the payee (i.e. the merchant)
“If you ask for a refund, we will request your LFI to share your payment account details with us. These details may be shared with the payer or may be used by us to process your refund request. We will not use these details for any other purpose and we will not retain these details after your refund request has been processed.” 1.4 NOT request the Users' consent for Asynchronous Refund Information of their payment account details from the LFI, in cases where there is no realistic chance the refund information data (i.e. the User account details) to be used (e.g. where the merchant business model does not offer refunds). 1.5 Set the appropriate Refund Information flag in the payment Consent payload that the User has provided explicit consent for Asynchronous Refund Information request. | ||
REF-2 | Consent Staging | |
REF-3 | Hand-off to LFI | |
REF-4 | Authentication | |
REF-5 | Confirmation/ Authorization | |
LFIs MUST: 5.1 Provide clear messaging to the Users in relation to the consent provided to TPPs for requesting their payment account details for refund purposes. Example wording may be as follows: “TPP will be permitted to request your account details for refund purposes.” | ||
REF-6 | Payment Initiation | |
REF-7 | Payment Status Update | |
REF-8 | Hand-off back to the TPP | |
REF-9 | Confirmation to User | |
TPPs MUST: 9.1 Confirm to Users that they have received permission to request their payment account information in the future for the purpose of refunds. 9.2 Provide clear messaging to the Users confirming the permission provided to them for requesting payment account details for refund purposes. Example wording may be as follows: “We have saved your permission to request your payment account details from your LFI for refund purposes. If you ask for a refund, we will request these detaisl and share them with the payee or use them to process your refund request. We will not use these details for any other purpose.” 9.3 Additionally consider displaying some of the following information points, which would be of value in relation to refunds:
Note: This list is not intended to be exhaustive and TPPs should adapt it to include the information relevant to their service offering. User details usage and retention should be covered by the TPPs' Privacy Policy. | ||
REF-10 | Payment Notifications |
4. Requesting Asynchronous Refund Information
# | Step | Rules & Guidelines |
|---|---|---|
REFREQ-1 | Pre-condition | 1.1 Both User and Merchant MUST have agreed to a refund and no dispute exists between them. |
REFREQ-2 | Request Asynchronous Refund Information | TPPs MUST: 2.1 Submit to OFP a Refund Information Request specifying the payment Consent ID related to the original payment for which a refund has been requested. |
REFREQ-3 | Processing of Refund Information Request | OFP MUST: 3.1 Allow the TPPs to submit the Refund Information Request in relation to a single-use or long-lived Payment Consent authorized by the User, without any additional MFA or authorization from the User. 3.2 Check that the received Refund Information Request relate to a valid Payment Consent authorized by the User. 3.3 Check that the Refund Information flag in the Payment Consent has been set confirming that the User has provided permision for this payment account details to be provided for the purpose of Refund payments. 3.4 Send the Refund Information Request to the LFI for acquiring the User’s payment account in relation to the Cosnent ID specificed. |
LFIs MUST: 3.5 Allow the OFP to submit the Refund Information Request without any additional MFA or authorization from the User. 3.6 Search their records for the User payment account in relation to the payment Consent ID specified in the Refund Information Request. 3.7 Search their records for the User payment account in relation to the payment Consent ID specified in the Refund Information Request. 3.8 Provide the OFP with the User payment account details in relation to the specified payment Consent ID as response to the Refund Information Request. The format of the User payment account is as per as per Common Rules and Guidelines | 2. User Payment Account Selection. | ||
OFP MUST: 3.9 Send an appropriate error response to the TPPs in case the Refund Information Request is rejected due to an invalid payment Consent. 3.10 Provide the TPP with the User payment account in relationall to the payment Consent ID used to make the original payment, which has been requested to be refunded. | ||
REFREQ-4 | Refund Information Received | TPPs MUST: 4.1 Confirm to PSUs using notifications that they have received their payment account information to be used for the purpose of refunds. Note: Using, accessing and storing the User account details is the responsibility of the TPP. TPPs would need to ensure that if required to be stored, these details are stored securely and in line with relevant regulatory obligations.
|
5. Fulfilment of Refund Payments
Fulfilment of refund payments 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 TPP, their systems' capabilities and the way they are integrated. In addition, refund fulfilement can be implemented using existing or new business processes at the merchant/service provider’s side.
The CBUAE Open Financen Standards aim to support the communication between TPPs and LFIs, but they do not intend to define the parameters of the relationship and the mechanisms used between the merchants/service providers and TPPs, in relation to refunds. However, we have summarized below models that are being considered within the industry today. These models are intended to be for illustrative purposes 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 for refund fulfilment:
Example 1: Merchants/Service Providers receive User payment account details from their LFIs
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 Financen APIs to initiate refund payments from the merchant/service provider’s LFI account
Example 5: Use of the Merchant/Service Provider’s LFI host-to-host solution – (Under consideration)
Example 6: Use of ‘assisted’/’shared’ SCA model for Refund Payments – (Under consideration)
Note 1: As refunds are expected to be fulfilled with new payments to the Users' payment 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.
Note 2: The refund payment (initiated by the TPP, 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 User. Thus, in addition to using the same payee payment reference as the original payment, where possible, the refund transaction payment reference should 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 the prefix must must be used without truncating the original payment reference as this could make reconciliation of the refund payment against the original transaction more difficult.