Request to Pay: Your questions answered

Following our Request to Pay webinar last month, the RtP team have answered the questions that they didn’t have time to answer on the day. If you have any further questions or would like to discuss how to get involved in Request to Pay,  you can email

When do you see Request to Pay being a solution that is ready/available? Do you need the major banks/PSPs to start to develop in order to help scale?

We expect there to be sufficient capacity created in the market during H1 2021. The banks will certainly help with scaling up Request to Pay, but there are other providers that could get involved to increase access.

How many other Request to Pay providers are there?

Since publication of the Framework at the end of May, we have enrolled a service provider and a technical provider. These are listed on our website. We are also working with a number of other companies who are currently progressing their solution and expect to announce further new joiners in the coming months.

The service relies on adoption – so how can we promote and accelerate the on-boarding of payers, because without payers, billers can’t bill.

Any financially regulated organisation with a large customer base could certainly help adoption, such as the high street banks, but also comparison websites or other technology-based providers who meet the eligibility criteria could assist.

What commitments do you have from banks to include this in their banking apps?

We are discussing this with the banks at present and hope to see them starting development in the new year. One of the purposes of the webinar was to highlight the demand for Request to Pay.

How do you see the Fintech players will play the role in the Request to Pay ecosystem?

The design of the Framework is to encourage innovation. So Fintechs can build either apps or repositories, or both.

This proposition could really effectively support under-served consumers but a lot of the use cases rely on the billers implementing – why wouldn’t the billers bring in the Request to Pay proposition within their app?

In order for payers to have confidence that the billers are legitimate, we require that Service Providers are FCA or PSR authorised so that we can be confident that appropriate AML and KYC controls are in place when on-boarding end users. Most billers will not be FCA or PSR authorised.
Also the App Service Providers need to be able to offer at least two methods for the end user to pay all requests, which won’t necessarily be from the biller.

Many governments will look to support nascent payment solutions, especially when it provides support to our most vulnerable communities, will the UK government look to do the same with Request to Pay?

We are continually having conversations with government departments and in principle they are very supportive of Request to Pay and many of the departments can see lots of use cases for Request to Pay.  However, to date we have not spoken to them about vulnerable communities, but this is something we are planning on doing in the near future.

For customers who don’t use Direct Debit due to concerns around billers increasing prices each month (based on estimates of what is owed which may not be accurate) – how will Request to Pay help remove this challenge, other than giving the option for the payer to refuse the request or pay less?

Request to Pay provides a secure digital method to send a request that relates to a bill. It has been designed to give the consumer control of how they pay the request. However, the commercial arrangement is a matter between the supplier and their customer.

Does 45% of people who don’t pay by Direct Debit include or exclude those on pre-pay meters?

It includes those on pre-pay meters

With split bills, how does this impact credit profiles?

We do not support split bill functionality. Request to Pay is the means of securely presenting a bill request to someone. It does not impact on the commercial relationship between the two parties. How their payments impact credit scores is out of scope of the Request to Pay Framework and provided the request is paid by the due date it should not have any impact.

Does Request to Pay work with debit or credit cards as a payment type?

Yes, it is payment agnostic.

Can Request to Pay remove Card fees?

No Request to Pay is a secure message service. However, it does allow the consumer to pay in the way that suits them, provided the biller accepts that payment type.

How does a customer get a full view of any ‘in progress’ requests without having to go to multiple sites or providers?

Our rules require that apps are developed to allow the end user to access multiple accounts on multiple repositories. This works in the same way that an email app on your phone today allows you to see all of your email accounts in one place.

If I receive a Request to Pay message and click on a payment type, does this then wake up my bank mobile banking app to fulfil payment?

Not necessarily, this is down to the competitive design of the app provider. They may use Open Banking which could interact with the end users bank, or they may offer payments through another service e.g. PayPal.

It was mentioned that end users can see all Request to Pay statuses on the one app but when user change from one app to another app, would that just be data specific to the app used only?  Is there a unique end user ID that would allow the end user/payer to be uniquely identifiable so that their Request to Pay transaction history are portable from one app to another app if the user switches app?

Apps have to allow the end user to log into all of the accounts that the user has.

Confirmation of Payee is seen to be an important part of stopping APP fraud – what layers will be needed/are planned for Request to Pay to provide similar reassurances that the request isn’t fraudulent?

This has been at the heart of the design of Request to Pay. This is why the Providers have to be authorised by the FCA / PSR and need to perform KYC checks when on-boarding an end user. There is also the need for a Pre-authorisation message to be sent from the biller to the payer before any Requests can be sent. This provides the Payer with the opportunity to decline the relationship if they don’t recognise it. Finally, the Payer has the option to decline a request and block future requests if they don’t want continue using Request to Pay with the Biller. when this happens, a message is sent back to the biller informing them, so that they can make alternative arrangements.

What plans are there to promote awareness to end users?

Request to Pay is a Framework, the companies who adopt it and build it into their propositions will want to promote their products. However, to help with end user identification of who is part of the Request to Pay Framework, we have created an Indicator Mark to show compatibility, similar to the contactless or USB logos.

Would Pay.UK and Money and Pension Advice help train debt advice providers on the benefits of Request to Pay and its use. It will of great help to consumers in need of debt advice

Part of the Mark Guidelines Toolkit will be to help organisations who are developing Request to Pay propositions to help provide elements of education about the Mark and what it means, but also how Request to Pay will operate and how it can help individuals manage their finances and have more control over how and when they pay their bills. It should also be noted that those organisations who join the Request to Pay Framework also have a responsibility to educate their customers, and if we work together as a Request to Pay community we should be able to use Request to Pay to help people understand more how they can better manage their finances.

Is Request to Pay likely to take off globally? If so are the standards the same in all markets?

Request to Pay is already taking off around the world. We have been talking to the EBA / EBC, Canada, US, Australia, P27, Vietnam amongst others about their plans and implementation of Request to Pay propositions. The Nordics have been running Request to Pay services for several years.
Regarding Standards, we have aligned our messages as far as possible to ISO 20022. However, to address the consumer control detriments we needed to add more functionality which led us to extend are message standards. We have included the International payment fields to aid compatibility and the messages can be extended to carry additional payloads for other markets. This includes the capability to include BIC and IBANs.

How do you see the international Request to Pay working given that the UK’s approach so far has been unique versus the Request to Pay approaches in development?

The Request to Pay standards have been designed around ISO 20022. Common fields are named the same and have the same definition to assist with translation to Pain.001 and Pacs.008. We are also talking with other Request to Pay Frameworks Internationally and will continue to work with them as the standards evolve. We believe that as a messaging system, the Framework should be Payment Agnostic and should be capable of working across border.

How would Request to Pay work on a cross border basis (assuming no deal Brexit)? 

Request to Pay does not affect the commercial arrangements between the Biller and the Payer. It simply carries the Request message including details of how to pay it. At launch it is intended that Request to Pay should be limited to the UK, Northern Ireland and the Channel Islands, but further expansion to other territories in the future is certainly possible.

What are the main differences between the UK-model, and EPC/SEPA’s 4-corner model in regards to different actors and their roles in the eco-system?

There are a lot of similarities, but the EPC/SEPA offering is based in Pain.013/014 messaging and is tied to SEPA as a payment type. Also because of the limitations of Pain.013/014, they don’t offer the consumer control of partial and full payment or requesting a revised due date.

Can you provide a description of Point of Sale and International Requests?

Both the Point of Sale Proposal and International Request are still a work in progress and as such there are not too many details that we can provide at this present time, apart from the fact that it is something we will be looking at developing in the not too distant future.  If anyone would like to provide input into these developments please get in touch.

Do you see Request to Pay having a capability in a physical environment? i.e. in a retail store – ability to limit physical contact in current environment?

This is certainly possible and we are talking to organisations to also allow a Request to be settled in cash through their outlets.
The Point of Sale Use Case is something we are looking to develop in the near future.

How does the cost of Request to Pay compare to DD? i.e. per transaction processing cost?

The cost card for Request to Pay is available on our website.

How would this solution support new services (like Afterpay)?

Afterpay / Klarna are types of services that could use Request to Pay to settle the original Request and then could use Request to Pay to request the subsequent repayments.

Why does HMRC’s recent open banking tender not include Request to Pay?

You would have to ask HMRC that. However, we are talking to HMRC and Government Banking about Request to Pay.