Skip to main content

Unlocking account-to-account retail payments – functional capability

In this piece, Andrew Self, Senior Manager in our policy division, explores how operational and technical standards can be developed so that they meet the functional requirements for retail transactions via account-to-account payments. This piece builds on a previous thought piece by Kate Fitzgerald, our Interim Head of Policy, which talked about how account-to-account payments can help increase the choice of payment system for retailers.

Account-to-account payments can help increase the choice of payment options for retailers and change the way we buy things in the future. However, we believe there are four issues that need to be addressed to promote account-to-account retail transactions using open banking. These are:

Functional
capability

Operational and technical standards meet the functional requirements for retail transactions. This, for example, includes the ability for the retailer to support subscription payments.

Dispute
processes

Consumers are suitably protected when making account-to-account payments. All parties involved in the transaction act together to minimise payment risks, and put in place the right processes to ensure that people feel safe when using account to account payments because they know what will happen if things go wrong.

Sufficient access and reliability

People and businesses feel comfortable making and accepting account-to-account payments because they are quick and convenient. This means that there is sufficient availability across the end-to-end journey for a retail transaction and customer drop-outs are at a low level.

Competitive
pricing

Account-to-account payments support competition and provide commercial opportunities for businesses involved in the transaction. A sustainable pricing model for retail transactions ensures firms can continue to invest in new products and further innovation that benefits people and businesses.

There are a range of considerations when thinking about what functional capability requirements are needed to realise our vision for account-to-account retail transactions.

Open banking payments allow consumers to pay by bank transfer, sending funds directly from their bank account. Currently, people tend to use them to allow authorised and regulated firms, Payment Initiation Service Providers (PISPs), to make transfers on their behalf between their accounts (for example paying off a credit card bill or topping up an ISA) or to make a bill payment, (for example making a self-assessment tax payment). In many cases, this works well. Retail transactions, however, are a more complex environment and if this type of payment is to work well, additional functionality is likely to be needed.

Retail transactions introduce a new party in this payment chain -- retailers, who would normally lead the payment process and offer particular payment options to their customers. Retail transactions also add a number of uncertainties (such as a customer paying a certain time before goods or services are delivered) which the consumer’s account provider needs to be able to assess the risk of. These types of factors place demands on the underlying payment infrastructure.

This means the payments industry will have to change or establish new standards, infrastructure, and service support, to operate a fully-fledged retail payment service. We want to hear from the account-to-account ecosystem how these features and capabilities can be added.

We’ve set up a Strategic working Group (SWG) to assess a range of different retail scenarios to see if the current functionality works and, if it doesn’t, identify gaps and propose ways to address them. This will help us understand which options can be progressed quickly, and which will need additional time and work to deliver.

Scenarios that the SWG will explore include:

  • E-commerce single transaction: you buy a mobile phone on a website or through a retailer’s mobile app.
  • Pre-ordered online grocery shopping (with variable amount): you order a grocery shop on Monday for delivery on Friday. When the groceries arrive, a product has been substituted, so the amount you pay changes.
  • High risk e-commerce transaction: you pay for an expensive holiday several months in advance, which could be disrupted by sickness or an airline going out of business.
  • Subscription payments: you set up a mobile phone account with varying monthly payments.
  • Physical point-of-sale transaction. you use a retailer’s mobile app to pay for an item in store and walk out with the goods immediately.

Of course, this list isn’t exhaustive. We expect the SWG and its expert panels to identify other relevant scenarios as part of its work. We’d also like to hear from our stakeholders outside of the SWG about any functionality gaps.

To help bring the issues we’ll consider to life, let’s take a closer look at the steps in a typical e-commerce payment, and the types of things we need to consider.

Step

Actions and questions

Customer makes purchase decision

You decide to make a purchase and agree the terms of purchase including when and how much you need to pay.

Payment options

You click through to the payment page and are offered a number of payment options.

How can the retailer make account-to-account options clearly available?
How do you know that you are choosing an account-to-account option?
What data do you need to provide to make the payment?
How does the retailer, banks and payment service providers make the process easy and safe for you to use?

Customer consent and authentication

Having chosen the account-to-account option, you must now prove that you consent to a PISP sending the payment instruction to your bank. To do so, you will need to strongly authenticate the transaction.

How can you do this conveniently?
Should your experience be any different if you pay via a phone with facial recognition, instead of via a browser on your laptop?

Risk management

The PSIP and the banks involved do a number of checks to minimise any risks with the payment. This might include further information to prove that the PISP has carried out due diligence on the retailer.

Every party in the payment chain has a different set of information, so how do they share the risk assessment effectively?
What data should the PISP share with your bank?

Payment initiation

The PISP is ready to initiate the payment on your behalf. It gives information about the payment to your bank, including the retailer’s account details, the amount of the payment, the time the payment should be made, etc.

What if the amount changes after the customer has approved the payment? (As in our online supermarket order example above).
Can the current infrastructure support these changes?

Payment

Your bank sends the payment to the retailer’s bank using the Faster Payments Scheme. To do this, it must fill in information about the payment. Some of this will be the same information provided at payment initiation, but your bank may need to add more details.

How do we easily link the payment initiation and the payment?

Reconciliation

The payment has been made and the retailer’s bank credits the retailer’s account.

How do you find out this has happened?
How does the retailer find out they have been paid?
How quickly do you and the retailer need to know?
What happens when the payment has left your account but hasn’t reached the retailer’s account?
What if you find out there was something wrong with your purchase; can the retailer issue a refund in a convenient way?

 

We’ll need to examine each of these steps – and variations on them – through the account-to-account retail transaction lens so we can understand what functionality will be needed to support these payments. There is clearly a lot of work to be done. We are looking forward to working with our stakeholders to identify the challenges and find a way forward so that account-to-account payments can be developed further to provide a wider choice of payment options.

If you like to tell us how functional capability can help unlock account to account retail payments, please contact us at A2A@psr.org.uk.