P7 • Reverse payments (Refunds)

1. Roadmap item definition and considerations

The Open Banking Roadmap describes “reverse payments” as an extension of PIS functionality to enable payees (or their PISPs) to refund a payer (customer) where the payee may be a merchant or a service provider. 

This proposition paper aims to address refunds of Open Banking PISP initiated payments, which are required as a result of the business/merchant’s commercial relationship with the customer (PSU). In the case that refunds are to be fulfilled via Open Banking, a refund payment would require the submission of a new payment order (either a single or bulk order) via a PISP to the merchant’s ASPSP, to facilitate the refund back to the purchaser, relating to a previous transaction. However, there may be cases where, depending on the model between the merchant/service provider and the PISP, refund payments may be completed via other payment methods or channels, that do not involve Open Banking.

The PSRs do not contemplate a mechanism for the refund or ‘reversal’ of a ‘push’ payment (including PISP-initiated transactions) except for unauthorised, defective, late or non-executed payment transactions, where there are specific requirements to facilitate those refunds. These fall outside the scope of this proposition, which deals with purely PISP related refunds required as a result of the merchant’s commercial relationship with the customer.

The proposition paper will consider the applicable functionality to enable a customer (PSU) to receive a refund amount (full or partial) when a payer and a payee (merchant/service provider) have previously both agreed to a refund and no dispute exists between them. The merchant/service provider is free to use payment methods other than through a PISP to carry out the refund*.

For the initial Roadmap Item Definition, please refer to section 11.3 of the Appendix. 

* Please refer to Constraints Section 9.3.

2. Market analysis

2.1 OBIE Analysis on Refunds

Customers

In the UK, refunds happen often and customers expect a seamless refund to be possible when they purchase goods and services. Refunds are particularly prevalent in the fashion / clothing retail industry, where 23% of all purchases are returned (data over 2016). For all eCommerce purchases in the UK, around 75% are made by a debit or credit card, or card-based products such as eWallets.

Merchants

Retailers have indicated that it is crucial for them that a payment proposition should include seamless refund functionality. As mentioned earlier, non-food retailers frequently require refund functionality. Also, food retailers such as Sainsbury’s, Ocado, Just Eat, etc make adjustments to transactions when they need to swap brands or something is out of stock which can entail a refund. The merchant business case for having seamless refund functionality is evidenced by a return rate of 15% of turnover (average for all online retail categories) totaling almost £8bn.  Often, non-card and some eWallet refunds are handled manually and are time consuming. This leads to higher costs for merchants, which is one of the key elements a merchant is looking to reduce. 

Card-based payment propositions do offer more seamless refund functionality for merchants, but card based refunds have a problem with lower speed. Card based refunds can take between 2-5 days for the issuing and acquiring bank to settle. This low speed prompts consumers to make complaints to the retailer, as consumers blame the retailer for the cause of the refund not being processed fast enough.

Making refunds is a critical function to make bank transfers in a merchant environment a viable alternative to card based payments. During the OBIE evaluation, many use cases have been identified in conjunction with retailers, SME, PSUs and Third Party Providers (TPPs). For businesses selling online, a priority use case is managing full or partial refunds for goods and services purchased online. Additionally, merchants have said that, to prevent fraud and money laundering, they want to return the payment to the account it came from.

If Open Banking and PISPs could provide a payment proposition, which includes seamless refund functionality, merchants would consider using it and they would recommend that payment proposition to their customers.

TPPs

TPPs have told us that offering payment initiation services without refund functionality makes it difficult for them to offer payment initiation services to online retailers. Currently, TPPs can offer customers refunds through screen scraping account details. When the RTS SCA came into force in September 2019, the provision of this type of refund functionality was significantly challenged. Additionally, screen scraping is against the vein of Open Banking and would require two tech builds; one to the APIs and one to enable screen scraping which adds complexity to the product. Therefore, it is essential to provide refund functionality within the Open Banking ecosystem. 

Additionally, if no refund functionality exists for an OB payment flow, TPPs say they may struggle to sign up eCommerce customers for the reasons mentioned in the merchant section above.

ASPSPs

Many ASPSPs also accept that refund functionality is important to their customers and would reduce operational costs, as it could fall to them to help manage the refund process. ASPSPs also consider driving increased revenue from push payments, if businesses decide to use this payment type as a way to refund their customers.

Furthermore, an ‘all-round’ Open Banking based payment proposition could allow ASPSPs to offer an alternative to customers who are currently using eWallets, pre-paid cards, and credit and debit cards, to make eCommerce payments. This could enable ASPSPs to better retain the relationship with their PSUs and could stop payments fragmenting away from their current accounts.

Summary

Refunds are important to stakeholders, but the Open Banking payment initiation model does not currently enable the merchants and their PISPs to initiate a refund in all cases. If this were available, TPPs could develop refund functionalities and open up eCommerce market segments where they can offer services. Also, PSUs would consider using the payment propositions more, provided that their security and anti-fraud concerns were addressed. This supports the broader objectives of PSD2, for instance, ensuring that consumers, merchants and businesses enjoy more choice and competition of payment services. We consider that refund functionality will be beneficial to both customers and merchant when using PISP services.

(Source: P7 Final Evaluation Report) 

2.2 Customer Research

OBIE performed PSU research (via Engine Trinity McQueen) to capture the customers’ views in relation to providing their permission to the PISPs for refunds purposes. Research included 6 focus groups (4 consumer, 2 SMEs) from 2 different locations Some of the areas of the research included:

• Whether or not customers want to know that the PISP and merchants will have access to their account details (sort code and account number) and may store these details for potential future refunds purposes.
• Whether customers want to share account details (sort code and account number) with the PISP and merchant only when they want a refund and do not want to have to share the account details with the PISP and merchant otherwise.
• What their current experience is on refunds using existing payment methods.

The key findings from the research are:

• Return journeys are working well, but low awareness of Open Banking is still a key barrier.
• 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 (and takes longer than in the past). This is a particular frustration for SMEs, as waiting for returned funds can have significant cash flow implications. 
• Thus, faster returned funds is a welcome point of difference and if Open Banking could produce this it could be a compelling differentiation point.
• There is preference for conditional sharing of details as per Option B (see section 11.5.1) as this clearer and more reassuring. However, Option A (see section 5.1), is not completely dismissed but need better explain of how details will be stored.
• Moreover, important aspects that also need to be addressed include:
  • More information of exactly what details will be shared.
  • How long the TPP will store the information.
  • Details on security and safety measures.
  • How quickly refunds will be processed.
• Finally confirmation of sharing their account details within the bank environment is considered to be important while repetition of confirmation at the TPP may be useful but not a must have.

3. Customer Use Cases

OBIE will conduct both primary customer research and secondary market research to identify the existing market offerings and requirements around refund process. In addition, a series of market engagement workshops are being conducted to validate the requirements, especially from the PISP and the merchants perspective. The following high level use cases requiring refund payments capabilities were identified.

* Please refer to Constraints Section 9.3.

4. Customer Journeys

4.1 Existing Customer Journeys (Currently available in v3.1.x Standards)

The following journeys are currently available in the v3.1.x Standards. They are described in the OBIE CEGs v3.1.3

4.1.1 Account Selection at the PISP – PISP retains the account details provided by the PSU during payment initiation

(using journey Single Domestic Payments – a/c selection @ PISP)

As part of the payment initiation service, the PISP should be able to request and retain the account details from the customer, for a period of time, provided that this is explicitly agreed with the PSU (customer). This will enable the PISP to provide a refund to the PSU, if and when required.

Description

• The PSU buys goods or services and agrees with the merchant/service provider’s PISP to provide their account details for the payments. These details are subsequently stored by the PISP for a period of time for the purpose of providing a refund and/or future transactions. 
• Within the agreed period of time and under the terms & conditions, the PSU 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 PISP initiates a refund payment  from the merchant/service provider’s ASPSP account with the merchant’s consent using the PSU account details as the beneficiary. This is a new payment order (it could be a single payment or included in a batch of payments).

Notes:

• This would not require a change to OBIE Standards or ASPSP development, since this is already available in the v3.1.x Standards, and described in the OBIE CEGs v3.1.3.
• However, in cases where the PSU provided the PISP with a valid account identifier (such as mobile phone number) instead of sort code and account number details, there could be a challenge to complete the refund if the merchant/service provider’s ASPSP does not support the use of these account identifiers for the beneficiary of the refunds payment. In this cases, the PISP may not be able to process the refund using the existing process and another solution must be implemented to cover this.

4.1.2 Account Selection at ASPSP – PISP does not have the PSU account details

Description

• In cases where the PSU selects their account at the ASPSP as shown in the journey above, the PISP does not have available the PSU account details in order to facilitate a refund payment. 
• Accordingly, the PISP is unable to make such a refund transaction without first obtaining the account details, either from the customer, the merchant or the PSU’s ASPSP.

5. Refunds Proposition Options

DPPWG conducted a Legitimate Interest Impact Assessment (LIA), which considered different options, which may be available when account selection occurs at the ASPSP. This included an analysis of the different technical options proposed for ASPSPs to provide the account details to the PISP and a legitimate interest assessment in respect of each option. It further considered the ASPSP’s legal basis for sending the customer (PSU’s) account details to the PISP and the relevant criteria related to “legitimate interest, as contemplated in GDPR,f Art. 6(1)(f) –“processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.”

The options below illustrate two of the possible alternatives that were considered during this process.

5.1 Option (A)

The ASPSP returns the PSU debit account information with each PISP initiated transaction. This happens only in cases where the PISP indicates that the PSU has consented to the PISP requesting their debit account details from the ASPSP. We will also refer to this solution as Synchronous Refund Information.

5.1.1 PSU buys goods or services

5.1.2 Example User Experience

5.1.3 Considerations

• The payload of the payment initiation endpoints are expected to be modified to include the additional consent information provided by the PSU to the PISP.
• The explicit consent from the PSU to the PISP is required to allow the PISP to request the ASPSP to provide the PSU debit account details.
• Not all payment journeys require the capability of refund. Thus, the explicit consent mentioned is only be used in case refunds capability is required, based on the business model of the PISP or its servicing customer.
• The PSU account details are expected to be stored securely by the PISP. In this case, the merchant has to instruct the PISP to initiate the refund payment from their account, thus the same PISP needs to be used for the refund payment.
• This solution is expected to be simpler for ASPSPs to implement compared to solution of Option (C).

Based on the support Option A has received and the perceived lower implementation effort, it is recommended that this functionality should be included in the OB Standard for Dec-19. If any option is to be mandated for the CMA9, it should be Option A with implementation completed six months from the publishing date of the Standard. 

5.2 Option (C) – Refunds using Merchant Order ID

Option (C) was not in the list of options considered initially by DPPWG. It was added later to offer an additional enhancement compared to the previous options, by preventing the PSU account details from being shared with the PISP. The option is using an ID (i.e. Merchant Order ID) generated by the Merchant/Service Provider which is populating the payment reference field (18 characters) when the PISP is initiating the payment order from the PSU’s account to the Merchant/Service Provider’s account. This payment reference will travel via the payment rails to the merchant/service provider’s ASPSP. (see 5.2 1 below). 

When a refund is requested, the Merchant/Service Provider will supply the Merchant Order ID to the PISP together with the request for refund and the refund amount. The PISP will prepare the refund payment initiation order, providing the details of the Merchant debit account, the amount, the Order ID and some additional information (such as the date and the amount of the original transaction). This information will effectively serve as a payment order (with the Merchant Order ID acting as a proxy for the payee details) , which will enable the Merchant ASPSP to search their payment records and identify the original payment, which contains the details of the PSU’s debit account. Thus, the Merchant ASPSP has all the information to proceed with the processing the refund payment, once confirmed by the Merchant (see 5.2 3 below). 

Alternatively, the most likely scenario is that the PISP will be collecting multiple refund requests and compiling this into a file, so that it submits a file of refund payments instead of single refund payments. This is particularly useful when a business requires to send more than a few refunds a day as part of their business model (see 5.2 4 below).

5.2.1 PSU buys goods or services

5.2.2 Example User Experience

5.2.3 PSU Request Refunds – Single Refund Payment fulfilment

5.2.4 PSU Request Refunds – Multiple Refund Payment fulfillment

5.2.5 Considerations

• This solution is considered more secure compared to options (A) and (B) as the PSU’s account details are never shared outside the ASPSP’s space or seen by the merchant/ PISP.
• Searching for the original transaction to retrieve the PSU’s account details using the Merchant Order ID, the merchant’s account and other info (e.g. date, amount) may required significant implementation by the Merchant’s ASPSP.
• There are payment services who are already using the payment reference field for other purposes (e.g. collection accounts, building society roll numbers, government payments using the NINO, etc). In these cases, the above refund mechanisms using Order ID may not be applicable).
• For each payment type that will be supported for refunds, a new ‘refund payment’ endpoint is expected to be created, that will be providing the ability the payment payload to contain the Merchant ID and the other information to be use for searching the original PSU payment, instead of the PSU account details as the refund payment beneficiary. 

In 2020, OBIE will evaluate how well Option A is performing and consider whether there is still a need to develop Option C further.

5.3 Fulfilment of the 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. 

Example 1: Merchant/Service Provider receives PSU account details from Merchant ASPSP

There are cases where merchants/service providers (especially large corporate organisations) receive information services files from their servicing ASPSPs, which include details of payments in and out of their bank accounts. These details very often include the payment account details of the payers of incoming payments and in certain cases, they are also supported by the Open Banking Read APIs. In these models, the merchants/service providers already have the PSU bank account details and when a PSU requests a refund payment, merchants/service providers can fulfill the refund request by using any existing payment channels (e.g. their business online banking, host-to-host payment solutions, batch file processing, direct submission etc). They do not have to use an Open Banking channel or a PISP for sending the refund payments.

Example 2: Organisation with appropriate authorisation to hold funds, offers “merchant account” to Merchant/Service Provider

OBIE industry research shows that, there are models in the industry where organisations holding multiple licenses have contractual agreements to offer “merchant account” services, similar to the acquirers’ in the card payments model, holding incoming payment funds on behalf of the merchant/service provider. These organisations also provide reconciliation and settlement services with the merchants for their receivables on regular intervals (e.g. daily or every few days).

In these models, when a refund is requested by the PSU to the merchant/service provider, and the multi-licensed organisation receives the refund request from the merchant/service provider, the multi-licensed organisation will search its records for the original PIS transaction and identify the PSU’s account details. It will then be able to initiate the refund payment from the funds holding account to the PSU using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing, direct submission etc). In the cases where the multi-licensed organisation does not have the PSU’s account details (i.e. the PSU selected their debit account at the ASPSP in the original PIS payment), then they can use Option (A) mentioned above to acquire the PSU’s account details for the purpose of refund.  

Details of the model will be covered under the contractual agreement between the multi-licensed organisation and the merchant/service provider. Please note that this model assumes the original payment to the merchant was initiated from the PSU’s account by the same multi-licensed organisation as the one requested to process the refund payment.  

Example 3: Organisation with appropriate authorisation to hold funds, offers “refunds account” to Merchant/Service Provider

OBIE industry research also shows that, as a variation of 5.4.2, the organisation holding multiple licenses, including a license which enables an organisation to hold funds, may have a contractual agreement to offer “refund account” services to merchants/service providers, by providing or holding specific funds to be solely used for the purposes of refunds. When requested by the merchant/service provider, the multi-licensed organisation will be initiating the refund payments from the refunds account using existing payment channels (such as business online banking, host-to-host payment solutions, batch file processing, direct submission etc). Finally, the multi-licensed organisation will be settling with the merchant/service provider as would be described in the contractual agreement with them. As above, the multi-licensed organisation could use option (A) to receive the PSU’s account details, provided that the original payment to the merchant was initiated from the PSU’s account by this organisation.

Participants engaging in the models described in Examples 2 and 3 will need to ensure they meet relevant regulatory obligations specifically relating to the services they are providing.

Example 4: Use of Open Banking APIs to initiate refund payments from the merchant/service provider’s ASPSP account

Option (A) provides solution to the information gap of the missing PSU’s account details necessary for the PISP to initiate refund payments back to the PSU. These can then be combined with Open Banking Payments Initiation API calls to send the refund payment from the merchant/service provider’s ASPSP account to the PSU’s account. Two main options exists:

• Single immediate Payments API: This could be used to send a single refund payment to the PSU. Please note that, it is anticipated that the merchant’s ASPSP will apply SCA for these payments to refund the customer, unless the ASPSP applies an available exemption. An additional implication is that there may be a multi-auth process flow also implemented at the ASPSP since this is business/corporate account. This solution is expected to only be acceptable in cases of very small businesses/startups that will not have a large number of refund payments to process during each day.
• File Payments API: This could be used to send multiple refund payments to a number of PSUs. The refund requests will be processed as a batch and will be submitted to the merchant/service provider’s ASPSP in a single file. Again note that, it is anticipated that the merchant’s ASPSP will apply SCA for these payments to refund the customer, unless the ASPSP applies an available exemption. However, submitting the refund payments in a file reduces the ‘call to action’ required by the merchant/service provider PSU. Also, the same implications with the multi-auth process flow apply for the file payments.

Option (C) will entail modifying the Single Immediate and File Payment APIs to create a refund payments version of these, where the PISP will be able to provide the Merchant Oder ID and the rest of the parameters mentioned in section  5.2.3 above, to allow the initiation of the refunds payments from the merchant/service provider’s account. Once again, it is anticipated that the merchant’s ASPSP will apply SCA for all the above payments to refund the customer, unless the ASPSP applies an available exemption. Similarly, any multi-auth process flow implications will also apply, making these refund payments appropriate only from small or medium size organisations and limited to business models which do not require large number of refund payments as BAU.

Further details of these models are shown in the Appendix, section 11.2  

Example 5: Use of the Merchant/Service Provider’s ASPSP host-to-host solution – (Under consideration)

Larger organisations/corporates, in many cases use host-to-host payments solutions, offered by their ASPSPs, in order to submit payments directly to their bank. These solutions are primarily designed for unattended processing (using end-to-end automation via server-to-server connection with very little or none human interaction) in order to increase Straight Through Processing (STP). This functionality can be combined with using either options (A)/(B) to obtain the PSU account details (if not known by the PISP licensed organisation) or alternatively in a more secure end-to-end solution with option (C) by the PISP licensed organisation to submit payment instructions with the Merchant Oder ID instead of the PSU’s account details to the merchant/service provider ASPSP. Details of the model will need be considered in the context of the contractual agreement(s) amongst the PISP licensed organisation, the merchant/service provider and the ASPSP of merchant/service provider, and appropriate consideration to the relevant regulatory obligations under the PSRs.

Example 6: Use of ‘assisted’/’shared’ SCA model for Refund Payments – (Under consideration)

In this model, using contractual agreements, the requirement of SCA is performed by the PISP licensed organisation on behalf of the merchant/service provider’s ASPSP. The PISP and the merchant/service provider’s ASPSP undergo a setup process, where a unique ID identifying the merchant/service provider’s terminal (or server) is encrypted and associated with the merchant/service provider’s credentials at the ASPSP. This is designed to support the first factor of SCA (possession). The PISP will also attest to the merchant/service provider’s ASPSP, that the merchant PSU has logged in using a second factor of authentication (this could be a knowledge factor such as username/password or a biometric). This would allow any authenticated merchant/service provider PSU, using an authenticated terminal (Trusted platform) to initiate a refund payment using the PISP service without performing any additional SCA at the merchant/service provider ASPSP. Details of the model will be covered under the contractual agreement between the PISP, merchant/service provider and the ASPSP of merchant/service provider. More details on this option would be covered under the standards technical design process.

Note: 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.

6. Regulatory Considerations

ASPSPs and TPPs will need to consider their obligations under PSD2 and GDPR, where applicable.

In the context of processing of personal data i.e. the sort code and account number, both the PISP and the ASPSP must ensure a valid basis for processing. While we note that GDPR obligations are for each data controller to determine based on their individual requirements, we would consider that for the PISP in particular, they could consider the basis below, as applicable. We note for PISP’s relying of consent for the processing of this data, consideration must be given to an appropriate revocation mechanism.

GPPR, Article 6

1. Processing shall be lawful only if and to the extent that at least one of the following applies:

(a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes;

(b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;

(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data…”

7. Evaluation criteria

Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate).

1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
2. Is the proposition implementable at reasonable cost?
3. Does the proposition comply with all relevant regulations?

8. Product requirements

OBIE understands that this proposition needs to support the following high-level requirements:

Synchronous refund info – Option (A)

• Ability for the PSU to give their permission to the PISP to request from the ASPSP the debit account details during each payment initiation.
• Ability for the PISP to request the ASPSP to provide the PSU’s debit account details during each payment initiation.

Merchant Order ID – Option (C)

• Ability for the merchant/service provider to generate a Merchant Order ID for the original transaction. 
• Ability for the PSU to give their permission to the PISP to provide their transaction details (Order ID, date etc) to the merchant/service provider’s ASPSP for the purposes of refunds, in the case when PSU requests a refund.
• Ability for the PISP to initiate a PSU payment using the Merchant Order ID as a payment reference.
• Ability for the PISP to receive the Merchant Order ID and initiate a refunds payment order using the Merchant ID instead of the PSU account details.
• Ability for the ASPSP to use Merchant Order ID and other information provided by the PISP to search the payment records and identify to original transaction in order to populate the refund payment with the PSU’s account details as the beneficiary of the refund payment.

Generic

• Ability for the PISP to receive the PSU’s account details when debit account selection is taking place at the PISP but the debit account identification used was not in the account number and sort code format.
• Ability for the PISP to request the account details to be provided by the ASPSP by specifying the desired format (e.g. account number,  IBAN etc).
• Ability to support the refunds options from any account type and currency selected by the PSU which is in the CMA Order and in PSD2 scope*.
• Ability to support the refunds options for following payment types: Single Domestic Payment, Single International Payments, Domestic Standing Orders, International Standing Orders, Future Dated Payments.
• Ability for OBIE solutions to support some (or all) of the models of refund fulfillment as described in the examples in section 5.4. subject to regulatory acceptance.

For detailed list of Product Requirements, please refer to section 11.1 of the Appendix.

(*) Note: BT/MTs accounts are excluded of this functionality.

9. Considerations

9.1 Assumptions

There is appetite from ASPSPs to implement functionality to allow PISP initiated payments to be refunded back to the PSU when no dispute between the merchant and the PSU is in place. Enabling refunds capability for all cases of PISP initiated payments will increase the adoption of Open Banking PIS services by merchants, especially for the eCommerce use cases. 

9.2 Dependencies

Implementation for CMA9 may be required in order to meet the objectives of the CMA Order, subject to further clarification from the Implementation Trustee on rationale and timing.

9.3 Constraints

N/A

10. Measuring adoption

The following metrics will be required to measure adoption:

Option A – Synchronous Refund Information

1. Number of PISPs requesting PSU’s account details to be provided by the ASPSPs as part of the payment journey, during the reporting period.
2. Volume of payments for which ASPSPs provided PSU’s account details to the PISPs for refund purposes, during the reporting period.

Option C – Asynchronous Refund Information

1. Volume of successful dedicated endpoint calls requesting PSU’s refund payments to be initiated from the merchant/service provider ASPSPs, during the reporting period.
2. Volume of failed dedicated endpoint calls requesting PSU’s refund payments to be initiated from the merchant/service provider ASPSPs, during the reporting period.

11. Appendix

11.1 Detailed Product Requirements

These are stated as requirements of the OBIE solution to enable support for key customer use cases.

Requirements marked as ‘M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.

Conditional (*): Implementation may be required in order to meet the objectives of the CMA Order, subject to further consideration.

11.2 Potential PISP/Merchant refund models using OBIE APIs for fulfillment

OBIE is performing industry research for the purpose of refund payments. Some of the potential PISP/Merchant models that can be implemented for refunds are shown below. The list is not exhaustive and also merchants and PISP need to consider their legal/regulatory obligations in relation to these:

11.2.1 Model 1A – Multiple Refunds – Account details stay with PISP – Refunds by same PISP

11.2.2 Model 1B – Single Refunds – Account details stay with PISP – Refunds by same PISP

11.3 Relevant Regulatory References

PSR  – Access to payment accounts for payment initiation services

69.—(1) This regulation applies only in relation to a payment account which is accessible online.

(2) Where a payer gives explicit consent in accordance with regulation 67 (consent and withdrawal of consent) for a payment to be executed through a payment initiation service provider, the payer’s account servicing payment service provider must—

(a) communicate securely with the payment initiation service provider in accordance with the regulatory technical standards adopted under Article 98 of the payment services directive;

(b) immediately after receipt of the payment order from the payment initiation service provider, provide or make available to the payment initiation service provider, all information on the initiation of the payment transaction and all information accessible to the account servicing payment service provider regarding the execution of the payment transaction;

(c) treat the payment order in the same way as a payment order received directly from the payer, in particular in terms of timing, priority or charges, unless the account servicing payment service provider has objective reasons for treating the payment order differently;

(d) not require the payment initiation service provider to enter into a contract before complying with the preceding sub-paragraphs.

(3) A payment initiation service provider must—

(a) not hold a payer’s funds in connection with the provision of the payment initiation service at any time;

(b) ensure that a payer’s personalised security credentials are—

(i) not accessible to other parties, with the exception of the issuer of the credentials; and

(ii) transmitted through safe and efficient channels;

(c) ensure that any other information about a payer is not provided to any person except a payee, and is provided to the payee only with the payer’s explicit consent;

(d) each time it initiates a payment order, identify itself to the account servicing payment service provider and communicate with the account servicing payment service provider, the payer and the payee in a secure way in accordance with the regulatory technical standards adopted under Article 98 of the payment services directive;

(e) not store sensitive payment data of the payment service user;

(f) not request any information from a payer except information required to provide the payment initiation service;

(g) not use, access or store any information for any purpose except for the provision of a payment initiation service explicitly requested by a payer;

(h) not change the amount, the payee or any other feature of a transaction notified to it by the payer.

FCA Approach Document

17.68 The PSRs 2017 do not prohibit PISPs from using and storing the payment service user’s account number and sort code for the purpose of providing a payment initiation service, with the customer’s explicit consent.

PSD2 pre read (31)
​When exclusively providing payment initiation services, the payment initiation service provider does not at any stage of the payment chain hold the user’s funds. When a payment initiation service provider intends to provide payment services in relation to which it holds user funds, it should obtain full authorisation for those services

11.4 Roadmap Detail Item Definition

P7 – Reversal (Refund)

11.5 Previously Consulted Options

11.5.1 Option (B)

The ASPSP returns the PSU debit account information only when it is explicitly requested by a PISP, after the PSU has requested a refund, on case by case basis. We will also refer to this solution as Asynchronous Refund Information.

11.5.1.1 PSU buys goods/services (using journey Single Domestic Payments – a/c selection @ ASPSP)

11.5.1.2 Example User Experience

11.5.1.3 PSU requests a refund

11.5.2 Considerations

• A new endpoint to be called by the PISP in case a refund is requested need to be designed and implemented.
• The endpoint will return to the PISP the account details of the PSU so that the refund can be arranged.
• The explicit consent from the PSU to the PISP is required to allow the PISP to request the ASPSP to provide the PSU debit account details.
• Not all payment journeys require the capability of refund. Thus, the explicit consent mentioned is only be used in case refunds capability is required, based on the business model of the PISP or its servicing customer.
• A payment id or transaction id has to be provided to the PSU’s ASPSP in order to search the original payment records and extract the payment account details of the PSU.
• Client credentials can be used for the PISP to authenticate and request the information.
• This solution can follow the sub resource construct that has been introduced with specs v3.1.2.
• From the standards perspective, this is expected to be a much cleaner option compared to the solution of Option (A).  
• However, it will require payment resources to be retained for querying for a further period in time, which varies based on different periods available for refunds. Alternatively, ASPSPs may need to run queries in archived payment records or in the underlying payments system level, which could be quite expensive for certain ASPSP implementations.

12. Version control