Refund Payment Fulfillment

Fulfilment of Refund Payments

The 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 could consider how these channels can be used to support refunds in this context.

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 the Synchronous Refund Information 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 the Synchronous Refund Information 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

Synchronous Refund Information 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.

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 Synchronous Refund Information to obtain the PSU account details (if not known by the PISP licensed organisation) by the PISP licensed organisation to submit payment instructions 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.