...
In cases where Users provided their payment account to a TPP to initiate 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 the merchant with the original payment details, including the payment amount, debtor identification details, creditor 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 the section. https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final8f0faec0e6b142f9a297da314b668b93/pages/210799277277941233/Payment+Refunds#5.-Fulfilment-of-Refund-Payments.
...
# | 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 Refund Information in a single step. 1.3 Make it clear to Users that they will share these details with the Creditor or use the details for refund processing, if the User requests and agrees a refund with the Creditor (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 creditor 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 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 Refund Information request. | ||
REF-2 | Consent Staging | |
REF-3 | Hand-off to LFI | |
REF-4 | Authentication | |
REF-5 | 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 details and share them with the payee or use them to process your refund request. We will not use these details for any other purpose.” | ||
REF-10 | Payment Notifications |
...
# | Step | Rules & Guidelines |
|---|---|---|
REFREQ-1 | Pre-condition | Both User and Merchant MUST have agreed to a refund and no dispute exists between them. |
REFREQ-2 | Request Refund Information | TPPs MUST: 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 permission 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 Consent ID specified. |
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 Provide the OFP with the User payment account details in relation to the specified payment Consent ID in response to the Refund Information Request. The format of the User payment account is as per as per https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final8f0faec0e6b142f9a297da314b668b93/pages/210800446277942495/Common+Rules+and+Guidelines#2.-User-Payment-Account-Selection. | ||
OFP MUST: 3.8 Send an appropriate error response to the TPPs in case the Refund Information Request is rejected due to an invalid payment Consent. 3.9 Provide the TPP with the User payment account in relation 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: 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. |
...
| Panel | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
TTPs MUST: 5.1.3.1Ensure that the refund payments, initiated by themselves or their customer Merchant/Service Providers, depending on the fulfillment model used, MUST be popullated with the Payment Purpose code that identifies them as refund payments. This code is currently set to be ‘POR’ as defined in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final8f0faec0e6b142f9a297da314b668b93/pages/210800530277942588/Limits+and+Constants#Payment-Purpose-Codes. |
...
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. 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. 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: 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 organizations. Details of this model can be found in https://openfinanceuae.atlassian.net/wiki/spaces/standardsv1dot1final8f0faec0e6b142f9a297da314b668b93/pages/210798542277940444/Multi-Payments#1.5-Multi-Payments-to-Variable-Beneficiaries.
...