Other Payment Types

Payment Refunds

This version is:

Published 2 years ago 04 Apr 2022

When the PSU provides their explicit consent to the PISP to initiate a payment order; the PSU also provides permission for the PISP to request their account details from their ASPSP for the purposes of providing a future refund.

Other pages in this section

User Journey

Main content image

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. 

Wireframes

The journey shown here is related to the core journey Single Domestic Payments – a/c selection @ ASPSP. However, the same approach applies to refunds of other payment types, such as Single International Payments. Future Dated Payments. Domestic and International Standing Orders. 

This content is best viewed on a desktop browser.

1

CEG Checklist Requirements 1
PSU Consent to PISP In addition to the PSUs’ consent to the payment initiation, PISPs must also request PSUs’ explicit consent before they are able to request their debit account details from the ASPSP for the purpose of refunds, as part of the payment initiation process. PSU consent for payment initiation and Refund Synchronous Information is provided in a single step. In cases where there is no realistic chance of the synchronous refund information data (i.e. PSU account details) to being used (e.g. where the merchant business model does not offer refunds), PISPs should not request the PSU consent for synchronous refund information and the account detains from the ASPSP.

2

CX Considerations 2
PISPs should provide clear messaging to the PSUs in relation to providing consent to PISPs for requesting their debit account details for refund purposes. Example wording may be as follows: “We will ask your bank to share your sort code and account number with us. If you ask for a refund, we will share these details with the payee or use them to process your refund request. We will not share it for any other reason”

3

CEG Checklist Requirements 3
Synchronous Refund Information Sharing ASPSPs must include the PSU debit account details (e.g. sort code and account number) in the response message of the payment initiation performed by the PISP. This information should be in a format that will allow the PISP to initiation a refund payment in the future that can be routed to the PSUs’ account. Note: For international payments this may include IBAN and/or other payment routing information to allow the refund payment to reach its destination account.

4

CX Considerations 4
PISPs should confirm to PSUs that they have received their debit account information to be used in the future for the purpose of refunds. Note: Using, accessing and storing the PSU account details is the responsibility of the PISP. PISPs would need to ensure that details are stored securely and in line with relevant regulatory obligations, specifically the obligations under GDPR. Please see the ICO Guidance on the lawful bases for processing personal data at: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/ We consider the following parameters will be useful for PISPs to consider when storing the sort code and account number, for the purposes of a refund. Security: PISPs must have robust procedures in place to ensure account details are stored in a secure manner, in order to minimise risk of these details being compromised. For additional information, please refer to TPP Operational Guidelines, section TPP Information Security. Note: Under GDPR, account should be taken of the security principle which states that personal data should be processed securely by means of ‘appropriate technical and organisational measures’ – ICO Guidance: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/security/ Duration of storage: PISPs should ensure that the sort code and account number are stored for an appropriate length of time to meet the purpose for which they are required, and should not store these longer than necessary, in line with the refund policy and applicable regulatory obligations. Note: In line with principle (e) GDPR storage limitation, personal data should only be stored for as long a necessary. See ICO Guidance: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/storage-limitation/ Purpose of storage for future use: PISPs must ensure that the account details are being stored solely for the purposes of making a refund. If PISPs want to use the account details for other purposes, for example, for the future transactions, PISP must ensure this is clearly communicated to the PSU as part of the consent journey.They must also consider the appropriate lawful bases under GDPR as set out above.

5

CX Considerations 5
PISPs should also consider displaying some of the following information points, which customers indicated that their provision would be of value in relation to refunds: The type of information that will be accessed e.g. sort code and account number The purpose for which the information will be used e.g. to provide a refund How long the PISP will store the information Details on security and safety measures applied by the PISP An indication of how quickly refunds will be processed if requested. *This list is not intended to be exhaustive and PISPs should adapt this to include information relevant to their service offering. It is a mandatory obligation under GDPR to provide prescribed information in the form of a Privacy Notice. For further information on the requirements of a Privacy Notice and how to display content please see: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/the-right-to-be-informed/what-privacy-information-should-we-provide/.

CEG Checklist Requirements & CX Considerations

1

PSU Consent to PISP

In addition to the PSUs’ consent to the payment initiation, PISPs must also request PSUs’ explicit consent before they are able to request their debit account details from the ASPSP for the purpose of refunds, as part of the payment initiation process.

PSU consent for payment initiation and Refund Synchronous Information is provided in a single step.

In cases where there is no realistic chance of the synchronous refund information data (i.e. PSU account details) to be used (e.g. where the merchant business model does not offer refunds), PISPs should not request the PSU consent for synchronous refund information and the account details from the ASPSP.

PISPs must make it clear to the PSU that they will share these details with the payee or use the details if the PSU requests a refund.

8a

2

PISPs should provide clear messaging to the PSUs in relation to providing consent to PISPs for requesting their debit account details for refund purposes. Example wording may be as follows: 

“We will ask your bank to share your sort code and account number with us. If you ask for a refund, we will share these details with the payee or use them to process your refund request. We will not share it for any other reason”

3

Synchronous Refund Information Sharing

ASPSPs must include the PSU debit account details (e.g. sort code and account number) in the response message of the payment initiation performed by the PISP. This information should be in a format that will allow the PISP to initiation a refund payment in the future that can be routed to the PSUs’ account.

Note: For international payments this may include IBAN and/or other payment routing information to allow the refund payment to reach its destination account.

8a

4

PISPs should confirm to PSUs that they have received their debit account information to be used in the future for the purpose of refunds.

Note: Using, accessing and storing the PSU account details is the responsibility of the PISP. PISPs would need to ensure that details are stored securely and in line with relevant regulatory obligations, specifically the obligations under GDPR.  Please see the ICO Guidance on the lawful bases for processing personal data at: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/

We consider the following parameters will be useful for PISPs to consider when storing the sort code and account number, for the purposes of a refund.  

  • Security:  PISPs must have robust procedures in place to ensure account details are stored in a secure manner, in order to minimise the risk of these details being compromised. For additional information, please refer to OBL Security & Counter Fraud guide.

Note: Under GDPR, account should be taken of the security principle  which states that personal data should be processed securely by means of ‘appropriate technical and organisational measures’ – ICO Guidance: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/security/

  • Duration of storage: PISPs should ensure that the sort code and account number are stored for an appropriate length of time to meet the purpose for which they are required, and should not store these longer than necessary, in line with the refund policy and applicable regulatory obligations.

Note: In line with principle (e) GDPR storage limitation, personal data should only be stored for as long a necessary.  See ICO Guidance: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/storage-limitation/

  • Purpose of storage for future use: PISPs must ensure that the account details are being stored solely for the purposes of making a refund. If PISPs want to use the account details for other purposes, for example, for the future transactions, PISP must ensure this is clearly communicated to the PSU as part of the consent journey.They must also consider the appropriate lawful bases under GDPR as set out above.

5

PISPs should also consider displaying some of the following information points, which customers indicated that their provision would be of value in relation to refunds:

  • The type of information that will be accessed e.g. sort code and account number
  • The purpose for which the information will be used  e.g. to provide a refund
  • How long the PISP  will store the information
  • Details on security and safety measures applied by the PISP
  • An indication of how quickly refunds will be processed if requested.

*This list is not intended to be exhaustive and PISPs should adapt this to include information relevant to their service offering. It is a mandatory obligation under GDPR to provide prescribed information  in the form of  a Privacy Notice. For further information on  the requirements of a Privacy  Notice and how to display content please see: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/the-right-to-be-informed/what-privacy-information-should-we-provide/

Fulfilment of Refund Payments

The fulfilment of the refund payment itself 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 PISP, their systems capabilities and the way they integrate together.  In addition to existing or new business processes at the merchant/service provider’s side.

The Open Banking Standards are aimed at supporting the communication between PISPs and ASPSPs, but they do not define the parameters of the relationship and the mechanisms used between the merchant/service provider and the PISP, in relation to refunds. However, as part of the industry research OBL was conducting for the purpose of refund payments, we have included models that are being considered within the industry today. These models reflected below are intended to be illustrative 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 more information in relation to these models, please refer to section Refund Payment Fulfilment. in the appendices.

Note 1: As refunds are expected to be fulfilled with new payments to the PSUs’ debit 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 or not.

Note 2: The refund payment (initiated by the PISP, 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 PSU. Thus, in addition to using the same payee payment reference (i.e. the 18 character field) as the original payment, where possible, the refund transaction payment reference could 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 due to the limitation of this fields to 18 character across payment systems, the prefix should be used without truncating the original payment reference as this could make reconciliation of the refund payment against the original transaction more difficult.

What the research says

Current return processes: Time for funds to be returned is causing real frustration. Sending items back is easy, involving an increasingly simple and slick process. But, receiving returned funds can be time consuming. This is a particular frustration for SMEs, as waiting for returned funds can have significant cash flow implications.  Faster returned funds is a welcome point of difference.  

Click for customer research