1. Description

This bank service request enables original payees (or their TPPs ) to refund a payer (i.e. User), where the original payee is a merchant receiving payments for purchase of goods/services. The functionality relates to refunds of Open Finance TPP initiated payments, which are required as a result of the merchants' commercial relationship with the customer (i.e. User). Refunds are to be fulfilled via Open Finance, and a refund payment would require the submission of a refund payment request via the merchant's TPP to the merchant's LFI, to facilitate the refund back to the payer (i.e. User) of the original transaction.

The Refund bank service request deals purely with TPP related refunds based on the merchant - customer commercial relationship and does not cover refunds for unauthorized, defective, late or non-executed payment transactions. Moreover, the Refund service request provides the applicable functionality to enable a payer (i.e. User) to receive a refund amount (full or partial) when both payer and a payee (merchant) have agreed the refund and no dispute exists between them.

The Refund 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.

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 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 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 Journey Summary

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

7.2 Single Refund Payment Consent

This use case requires a https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#A.-Single-Use-Consent. The consent parameters type for this use case is Single Refund Consent, which MUST be used for a batch of single refunds which will be initiated by the PASP immediately after PSU authorization at the PASP.

PISPs MUST:

7.2.1 Enable the merchant to initiate a refund request with the following details:

The refund payment amount (if different than the full amount of the original payment).
The amount of the original payment.
The date of the original payment.
The Transaction ID of the original payment.
Purpose of the Refund Payment (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.6-Purpose-of-Payment)
The PASP and the IBAN of the payment account to be used for the payment refund.

7.2.2 Check the details provided by the merchant and validate they match their previous records of initiated payments.

7.2.3 Check if any previous Partial Refunds were initiated against the same original transaction and that the cumulative value including the new Partial Refund request does not exceed the value of the original transaction. If it does exceed, then the PISP MUST inform the merchant accordingly and abort the request.

7.2.4 Enable the merchant to review the parameters related to the Refund payment they need to give consent for.

7.2.5 Enable the merchant to provide explicit consent for the initiation of a Refund payment from their online payment account held at their PASP as per the refund payment parameters specified in the consent.

7.2.6 Enable Merchants to initiate Refunds to multiple beneficiaries (original payers) using a single Refund Consent.

7.2.7 Limit the number of Refunds batched together in a single Refund request message to the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Limits+and+Constants#Max-Refunds-per-Message.

7.2.8 Redirect the merchant to the PASP of the payment account to be used for the refund payment.

7.2.9 NOT initiate a new Single Use Refund Consent with bulk Refunds before all the Refunds in a previous bulk Refund Consent have completed processing and have a conclusive payment status.

7.2.10 NOT initiate any Refunds of a payment date older than the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348554507/PIS+Configuration+Parameters#Max-Refunds-Allowable-Time-Window.

7.2.11 Set the Risk Information Block (as per https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.2.13-Risk-Information-Blockexcluding the Destination Delivery Address and the Beneficiary Indicators information groups due to being irrelevant)

PASPs MUST:

7.2.12 Follow the Authentication rules as defined in the https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.4-Authentication.

7.2.13 Use the information included in the Refund Consent to search records and identify the original transaction.

7.2.14 Check and validate that all the information of the Refund Consent matches the parameters of the original transaction.

7.2.15 Check and validate that all the payment account to be used for the Refund payment specified in the authorized Refund Consent matches the Payment Account used to receive the original payment.

7.2.16 Use the original transaction information to identify the account details of the PSU that initiated the original payment.

7.2.17 Display all the parameters of the Full or Partial Refund payment and request the merchant to authorize the initiation of a new single payment payment as a full or partial refund payment with the original payer PSU as the beneficiary.

7.2.18 Reject the request for initiation of refund and respond with an appropriate message for the following scenarios:

the payment account used for the Refund(s)does not have enough balance for the total amount of all Refund(s) in the request.
the Refund request is made after the stated refund allowable period.
the Refund request is made for a transaction that has already been refunded.
the amount in the refund request exceeds the original transaction amount . The amount must be checked against a cumulative value if there were any previous partial refunds made for that transaction.
there are any issues with the originating account that block any transaction initiation from the that account.
the transaction is declined by the recipient’s PASP

7.2.19 Formulate and send to the payment rails for processing the single payment message using the parameters of the authorized refund payment consent.

7.2.20 Confirm to PISP the successful initiation of the Refund payment.

7.2.21 Provide the PISP with the ability to check the status of the Refund payment as per the Rules in https://ksaob.atlassian.net/wiki/spaces/BRS20231101final/pages/348553780/Generic+Business+Rules+for+PIS#4.8-Payment-Status-Update.