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:

1.2 Refund - Example User Story

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 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, to allow on demand refund information, which is referred to as Asynchronous Refund Information.

Open

SIngle Instant Payment Journey modified for Refunds

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

Open

3.1 Consent Setup

4. Requesting Asynchronous Refund Information

5. Fulfilment of Refund Payments

5.1 Fulfilment Models

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 Finance 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 worldwide. 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 potential models for refund fulfilment:

• Model A: Multi-licensed TPPs Services: TPPs holding the multiple licenses (such as authorized Payment Institutions), including license which enables them to hold funds, can offer Refund Services to Merchants/Service Providers. Industry research identifies 2 different potential options for this model:

  • Option 1: Multi-licensed TPPs offer “merchant accounts” to Merchants/Service Providers

    • There are worldwide industry models where TPPs holding multiple licenses (such as authorized Payment Institutions) have contractual agreements to offer “merchant account” services, similar to the acquirers’ model in card payments, holding incoming payment funds on behalf of the merchants/service providers. These TPPs also provide reconciliation and settlement services with the merchants for their receivables on regular intervals (e.g. daily or every few days). In these cases, when a refund is requested by the User to the merchant/service provider, and the multi-licensed TPP receives the refund request from the merchant/service provider, the TPP will search its records for the original Open Finance Service Initiation transaction and identify the User’s account details. It will then be able to initiate the refund payment from the funds holding account of the merchant/service provider to the User as a credit transfer using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing etc). In circumstances where the multi-licensed TPP does not have the User’s original account details (such as when the User selected their debit account at the LFI during the original Bank Service Initiation payment), the organisations can use the Asynchronous Refund Information capability mentioned above to acquire the User’s original payment account details for the purpose of refund. The details of the model will be covered under the contractual agreements between the multi-licensed TPPs and the merchants/service providers. Please note that this model assumes that the original payment to the merchant/service provider was initiated from the User’s original payment account by the same multi-licensed TPP as the one requested to process the refund payment.  

  • Option 2: Multi-licensed TPPs offer “refunds accounts” to Merchants/Service Providers

    • Worldwide industry research also identifies a variation of Opton 1, where TPPs holding the multiple licenses (such as authorized Payment Institutions), including license which enables them to hold funds, may have contractual agreements to offer “refund account” services to merchants/service providers. These refund services involve providing or holding specific funds to be solely used for the purposes of refunds. When requested by merchants/service providers, the multi-licensed TPPs will be initiating refund payments from these refunds accounts using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing etc). Finally, the multi-licensed TPPs will be settling with the merchants/service providers as would be described in the contractual agreement between them. As above, the multi-licensed TPPs may use the Asynchronous Refund Information capability to receive the Users' original payment account details, provided that the original payments to the merchants/service providers were initiated from the Users' payment accounts by the multi-licensed TPP.

• Model B: Use of Open Finance APIs to initiate credit transfers as refund payments from the merchant/service provider’s LFI account: The Asynchronous Refund Information capability provides solution to the information gap of the missing Users' original payment account details necessary for merchants/service providers and TPPs to initiate refund payments back to the Users. This can then be used in conjunction with other Open Finance Bank Service Initiation APIs to initiate credit transfers as refund payments from the merchants/service providers' LFI accounts to the Users' accounts. The following options exist:

  • Option 1: Single Instant Payments API:

    • This can be used to send a single credit transfer as a refund payment to a User. Please note that, that the merchant/service provider’s LFI will apply MFA for these refund payments to customers (unless the LFI decides to apply an exemption). An additional implication is that there may be a multi-authorization process flow implemented at the LFI for the merchant/service provider’s account since it is a business/corporate account. Therefore, this option is only expected to be acceptable in cases of very small businesses/startups that will have a small volume of refund payments to process during each day.

  • Option 2: Bulk and Batch Payments API

    • This can be used to send multiple credit transfers as refund payments to a number of Users. The refund requests will be processed as a batch and will be submitted to the merchant/service provider’s LFI in a single file. Please note that, similarly to Option 1 above, the merchant/service provider’s LFI will apply MFA for the file of refund payments customers (unless the LFI decides to apply an exemption). However, submitting the refund payments in a file reduces the ‘call to action’ required by the merchant/service provider Users to initiate the refund payments. In addition, the same implications with the multi-authorization process flow apply for the Bulk and Batch Payments.

  • Option 3:Payments with Delegated Authentication/VRP Multi-Payments to Variable Beneficiaries APIs

    • This can be used to allow any authenticated merchant/service provider User, to initiate a credit transfer as a refund payment using the TPP without performing any additional MFA with the merchant/service provider’s LFI. This is the most flexible mechanism to facilitate refund payments by initiating new credit transfers and it suitable for most types and sizes of merchant/service provider organisations. Details of these models can be found in https://openfinanceuae.atlassian.net/wiki/x/GIotB and Multi-Payments | 1.5 Multi Payments to Variable Beneficiaries.

• Model C: Alternatives

  • Merchants/Service Providers receive User original payment account details from their LFIs

    • There are cases where merchants/service providers, especially large corporate organisations, receive information services files from their servicing LFIs, which include details of payments in and out of their bank accounts. These details very often include the payment account details of the payers of incoming payments. In these cases, the merchants/service providers already have the User original payment account details and when a User requests a refund payment, merchants/service providers can fulfill the refund request by using any existing payment channels (e.g. their business online banking, host-to-host payment solutions, batch/bulk file processing etc). These merchants/service providers do not require the Asynchronous Refunds Information functionality to support refund payment fulfilment as they already have the required refund information.

5.2 Fulfilment Rules for TPPs

5.2.1 Partial Refunds

As refunds are expected to be fulfilled with new payments to the Users' original payment accounts with the same payment reference, initiating a partial refund 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.

5.2.2 Refund Payment Reference