Payment Refunds

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. 

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 PaymentsFuture Dated PaymentsDomestic and International Standing Orders. 

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.

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. We will only use these details if you ask for a refund for this transaction”

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.

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.

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 & Customer Experience Considerations

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.

8a
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. We will only use these details if you ask for a refund for this transaction”

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

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.

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/

Fulfillment of Refund Payments

The fulfillment 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 OBIE 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:

  • Example 1: Merchant/Service Provider receives PSU account details from Merchant ASPSP
  • Example 2: Organisation with appropriate authorisation to hold funds, offers “merchant account” to Merchant/Service Provider
  • Example 3: Organisation with appropriate authorisation to hold funds, offers “refunds account” to Merchant/Service Provider
  • Example 4: Use of Open Banking APIs to initiate refund payments from the merchant/service provider’s ASPSP account
  • Example 5: Use of the Merchant/Service Provider’s ASPSP host-to-host solution – (Under consideration)
  • Example 6: Use of ‘assisted’/’shared’ SCA model for Refund Payments – (Under consideration)

For more informaiton in relation to these models, please refer to sectiion Refund Payment Fulfillment. 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 fulfillment 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