Written by Earlier this year we were delighted to be part of the Consult Hyperion webinar on Request to Pay. A common thread in post-event conversations that followed was an interest in the parallel developments of the UK and European flavours of Request to Pay and how they might work together. With the launch of the European version on June 15th, we thought it an ideal time to signpost the bigger differences.
Where Request to Pay (and SEPA R2P) have come from
The UK version of Request to Pay (‘RtP’) launched in May 2020, the payment services regulator having identified a gap in the domestic bill payments market for a service to bridge the gap between billers and payers. The result was a messaging standard (now ‘Request to Pay’) that facilitated communication between a biller and payer prior and post the payment itself being initiated. That this communication is via banks and payment service providers removes the integration burden for the biller and ensures robust security.
The European equivalent (‘SEPA R2P’) is also a messaging standard but has potentially broader application and was born of a need to catalyse the adoption of instant account-to-account payments. It is still commonplace as a consumer to pay a fee to use SCT Inst instead of standard SEPA Credit Transfer. This has resulted in sluggish adoption by both PSPs (only offered by 59%) and their respective customers. The Council of the European Union feels very strongly that Request to Pay forms an essential part of this plan, so much so it may shortly be mandated:
Digging into the detail
Both RtP and SEPA R2P are heavily backed. And they aren’t in isolation—there are similar developments taking place in the US, Canada, and Australia to name but a few.
For Banks and PSPs, it’s important they have a plan to meet the growing demand that will come from your customer base. Part of that plan will be to deliver services across the different regions in a seamless manner. This is where understanding the differences between the European and UK standards is so important:
1. Payment Method
Given the background of their development it’s perhaps not surprising that one of the key differences between RtP and SEPA R2P is the payment methods supported. One of the key goals of SEPA R2P is to stimulate the uptake of account-to-account payments so it therefore makes sense that this standard whilst being a communication protocol is tied to SEPA payment rails. By extension this does limit which payment providers will be interested in this service as you do need access to these rails either directly e.g., Banks or indirectly e.g., Payment Initiation Service Providers.
By contrast the UK’s instant payment adoption is nothing short of phenomenal and is continuing to grow. For Faster Payments In the 12 months to the end of April 2021 we see that:
- Single Immediate Payment volumes have increased by 25% (12 months to March 22%)
- Total Faster Payment volumes have increased by 19% (12 months to March 16%)
- Single Immediate Payment values have increased by 18% (12 months to March 14%)
- Total Faster Payment values have increased by 14% (12 months to March 9%)
Thus, the trend has continued in April with both volumes and values significantly ahead of 2020 levels; April 2021 saw an increase of 43% in the volume of Single Immediate Payments processed and 48% in the value of Single Immediate Payments. The increased use of faster payments seems to be a digital payment habit that will be here to stay, reinforced throughout each lockdown over the last 12 months. There’s therefore less of an imperative to use Request to Pay as a tool to drive demand which led Pay.UK to declare their standard as being payment method agnostic.
You could therefore conceivably see a consumer paying their utility bill with cash using Request to Pay although bank transfer and card payments are perhaps more likely. The Payer’s app then makes a bank transfer to the biller—so the biller only manages one cash collection process yet can support an unlimited amount of alternative payment methods, thereby helping the Payer to broaden the appeal of their apps.
2. Application
At least in the short term, SEPA R2P has a broader application than the UK’s Request to Pay. This partly due to the mandated response options that a Payer must be presented with every time they get a request in the UK. They are pay in full, part pay, request a delay, ask for more information and decline; Great in an invoice type payment scenario where you perhaps have as much as 30 days to consider your response, but terrible in eCommerce where checkout times are measured in seconds.
Secondly, Open Banking is a mess in Europe due to the lack of API standardisation, the result being 4000+ banks each adopting PSD2 legislation differently, leading to wildly varying experiences. As highlighted by Francis De Roeck of BNP Paribas (an investor in an Open Banking aggregator), SEPA R2P could lead to uniformly positive experiences thanks to API standardisation. The fact that banks can also make money from it does also ensure that they are incentivised to create compelling experiences.
3. Identity
The UK solution limits competition on this messaging solution by only allowing payment companies to offer services in this space. This makes it harder for accountancy platforms or tech companies to take part directly. On the plus side, the UK RtP standard does incorporate the concept of a payer ID. Functioning very similar to an email address, participants create one of these addresses as part of their onboarding process and this becomes the destination that messages are sent to or from.
The fact that a unique ID is created means that newer payment providers without existing customer bases can compete in what will be inevitably become a land grab to own that customer relationship.
The European standard has no equivalent ID. Instead, customers will have to use their existing supplier credentials. While this may benefit the customer experience, this approach favours incumbent providers who already possess large customer bases who can be effectively ‘enabled’ for SEPA Request to Pay.
The big picture
On the broader topic of identity, this two-way dialogue between a payer and their biller— facilitated by trusted parties—could offer up very interesting new experiences. You can picture for example a payer looking to buy age restricted goods and a biller asking the payer using Request to Pay to validate their age using their PSP held details before continuing. The PSPs have the commercial opportunity to evolve their business models to become trusted data brokers not just payment providers.
With these key differences between the two standards, multinationals looking to offer services in both markets may have a challenge in delivering services. This is where services from Consult Hyperion and Answer Pay could help.
Consult Hyperion is an independent consultancy, have grown to be globally recognised as thought leaders and experts in the areas of Payments, Digital Identity and Mobility.
Answer Pay are your API for Request to Pay offering a single point of integration across these emerging standards for simple and cost-effective routes to market.
Written by Peter Cornforth
Peter Cornforth is the Commercial Director of Answer Pay, a first to market Request to Pay service. Request to Pay supports the needs of billers and payers and empowers a new era of modern cash collection services. Peter leads the market engagement and product development initiatives needed to support the connectivity of Payment Service Providers (PSPs) to the Request to Pay framework and standards using Answer Pay’s platform.
Prior to Peter’s appointment in May 2020, Peter was the Vice President of Payment products for Token, responsible for the development of Open Banking technology into market leading payment services. Peter has also held roles at Vodafone M-Pesa, Santander, Amazon Pay and Paysafe.
Peter has more than 20 years of professional experience with extensive industry knowledge and deep expertise in payments strategy and innovation.
