User Journey

...

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. 

7. UC015 - Refunds

...

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. This use case addresses The functionality relates to refunds of Open Banking PISP Finance TPP initiated payments, which are required as a result of the merchants' commercial relationship with the customer (PSUi.e. User). Refunds are to be fulfilled via Open BankingFinance, and a refund payment would require the submission of a refund payment request via the merchant's PISP TPP to the merchant's PASPLFI, to facilitate the refund back to the payer (PSUi.e. User) of the original transaction.

The use case Refund bank service request deals purely with PISP TPP related refunds required as a result of the merchant’s commercial relationship with the customer based on the merchant - customer commercial relationship and does not cover refunds for unauthorized, defective, late or non-executed payment transactions. Moreover, the use case considers Refund service request provides the applicable functionality to enable a payer (PSUi.e. User) to receive a refund amount (full or partial) when a both payer and a payee (merchant) have both agreed to a 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:

1.2 Refund - Example User Story

2. User Journey

2.1 Journey Summary

The PSU User buys goods or services from the merchant. Within the agreed period of time and under the terms & conditions, the PSU 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 PISP TPP initiates a refund payment from the merchant's PASP LFI account with the merchant's consent using the original Transaction ID. This is a return payment order to the PASP.There are 2 different ways refund payments can be initiated:.

...

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.

...

...

...