Practical guide to SEPA Request to Pay

A powerful new pan-European payment instrument is almost ready for implementation November 2021. The European Payments Council has issued a new draft rulebook for public consultation. Although it is not yet final in this paper we are already providing you our preview of the working and expected benefits.

Introduction

Over the last few years, commercial and central banks, as well as market infrastructures, have made massive investments in the development and launch of Instant Payments. With over 56% of banks across Europe joining the scheme as of writing this article, it is a great success. However, volumes are still relatively limited as 6,5% of total SEPA Credit Transfer volume is processed instantly.

During the design phase of Instant Payments, there was plenty of talk about the potential use cases: sharing a restaurant bill, buying used goods online or face-to-face, mobile top-ups, instant bill payments to avoid late fees, all the way up to high(er) value transactions such as buying a new car with immediate confirmation to the payee. The promises are endless.

But as banks, consumers and merchants have found out, a high-tech infrastructure is just one piece of the puzzle. For the use cases to come to fruition, another element is necessary, namely a user-friendly way of making use of this infrastructure. The high-speed train that goes onto the new rails, if you will.

There are several of these “high-speed trains” already in circulation. In the Netherlands, the ABN AMRO sponsored Tikkie app has 6 million active users, in Sweden Swish is used by 7 million Swedes and in Denmark, the mobile payment app MobilePay is so popular that it was used by 98 percent of Danes aged between 20 and 29 years and by 97 percent of 30-to-39-year-olds in January 2020. But these success stories are very local, restricted to a country. This is where the European Payments Council (EPC) comes into play, the factory of the SEPA payments schemes so to speak. After the EPC developed the Credit Transfer, Direct Debit and Instant Payments Rulebooks for Europe, it started working on a new sequel: the SEPA Request-to-Pay scheme. It could bring the payment actors together and provide impetus for additional innovation on top of the Instant Payments rails. EBA Clearing described Request-to-Pay (RTP) as a key step towards unlocking the enormous potential that Instant Payments hold for both consumers and businesses: “Many payments professionals consider Request to Pay to be the missing link between the instant payment clearing & settlement infrastructure and innovative customer solutions”.

In this paper, we will dive into how the EPC designed the RTP scheme, what use cases are the most promising, and what benefits they would bring to consumers and merchants; it concludes with an outlook on future developments.

This paper is based on the draft RTP scheme that has recently been published for public market consultation. The final scheme, due this November, is expected to be very similar to the draft, but might differ and impact some of the views in this paper.

What is an RTP?

The principle of the RTP is simple.

A Payee, such as a merchant or an insurance company, initiates a request to be paid (in Euro only for now) with the relevant payment information included. The request is processed and routed (via intermediaries called RTP Service Providers – RTP SPs) and presented to the Payer. The Payer approves the request and the appropriate payment to the Payee is initiated and executed. If the Payer rejects the request, the Payee is notified. As a last step, the Payee validates that the funds have been credited to its account and everybody is happy.

In a bit more detail, the operation of the scheme is described below (please also refer to graphic 1 below and our infographic with a link at the bottom of this paper).

 

The RTP scheme, like all SEPA schemes, is based on a four-corner model, to ensure it is open and allows competition. The key difference with the other SEPA schemes is that the RTP scheme defines the exchange of payment initiation information and not of the payment process itself. The scheme sits ‘on top of’ or reuses an already existing payment instrument. This type of scheme is frequently called an ‘overlay service’. That is why the initiation and execution of the payment is not part of the scheme, as we will see, with only a hook provided for when the linked payment should be initiated, for instance via a SEPA Credit Transfer or Instant Payment.

The actors in the scheme are:

• The Payee: the party that wants to settle a bill, for example for delivering a service or product
• The Payer: the consumer or business paying
• The Payee’s RTP Service Provider (Payee’s RTP SP): an intermediary Service Provider providing an RTP processing and routing service for the Payee;
• The Payer’s RTP Service Provider (Payer’s RTP SP): the intermediary Service Provider that receives the request from the Payee’s RTP SP and presents it to the Payer for approval; the Payer’s RTP SP is also responsible for ensuring that the linked payment is initiated, either in its own back-office or via a third party (using, for example, the PSD2 Payment Initiation Service)

Banks are logical candidates to take up the role of RTP SP, however, with additional focus these days on competition and innovation, the scheme does not restrict RTP service providers to being banks only.

First step: Retrieving the Payer identification

After the Payer and Payee have agreed to settle the outstanding payment via an RTP, the Payee will need to obtain identity information of the Payer (his or her IBAN for example) and of the Payer’s RTP Service Provider (for example a BIC). The Payee can request the identity information from the Payer at the time of contracting a service or product delivery and store it for future use. Other possibilities are that the information is shared at the point of interaction, for instance via NFC.

The initiation of the RTP

With the identity information available, the Payee generates an RTP and sends it to its RTP SP. The RTP contains:

• amount
• remittance information
• Payee’s IBAN and name

The RTP will also include payment conditions such as:

• expiry date and time, i.e. by when the Payer should have accepted or rejected the RTP
• the requested execution date and time of the payment (initiation)

Additionally, other information and conditions could optionally be inserted into the RTP, including:

• what payment method the Payer should use (normal SEPA Credit Transfer or Instant Payment)
• a URL referencing an invoice
• a flag that a notification should be sent when the Payer accepts the RTP (not only in case of rejection)
• other payment conditions, for example changeable amount allowed

Routing and presentment of the RTP to the Payer

After the RTP is initiated by the Payee with its RTP SP, the RTP is processed and routed to the RTP SP of the Payer. The Payer’s RTP SP will validate the RTP. Is the RTP request valid? Has the Payer provided an opt-in for the scheme? Is the Payee on a whitelist or blacklist? If all positive, the RTP request is subsequently sent or presented to the Payer for confirmation. He or she can then review the RTP and accept or refuse before its expiry date. Optionally, the Payer might schedule the payment execution date, if allowed by the Payee. During this process the Payer will need to authenticate him or herself and authorise his or her response to the RTP as well as for the initiation of the payment. Preferably all in one go!

The scheme also indicates that the Payee’s and Payer’s RTP SP could be one, turning the four-corner model into a three-corner model or even that the Payee and Payer use the scheme ‘just’ to exchange payment information.

Further Processing of the RTP by the RTP service providers

If the Payer has confirmed the RTP, the Payer’s RTP SP will initiate the payment as well as send status information about the processing of the RTP to the Payee’s RTP SP. The Payee’s RTP SP will then forward the status report to the Payee. The status report includes information about whether the RTP was confirmed (if requested) or rejected (with reason).

Request for Status Update

In cases where the Payee or the Payee’s RTP SP are in doubt about the status of the RTP, for instance due to a communication or application glitch, a Request for Status Update message can be sent by the Payee (or the Payee’s RTP SP). The Payer’s RTP SP will respond with the correct status.

Request for Cancellation

If the RTP becomes invalid, the Payee can initiate a Request for Cancellation. This request can be processed automatically by the Payer’s RTP SP, but the Payer needs to be notified. The Request for Cancellation can be used to correct, for instance, an accidentally sent duplicate RTP.

24/7 and real time

The processing and communication is expected to be up and running 24/7, as well as instant. This ensures that online and Point of Sales use cases are supported. However, the scheme does not indicate timelines, contrary to, for example, the Instant Payment scheme.

ISO 20022 based

All messages used in the scheme are ISO20022 XML based, allowing for standardisation, improved integration in the value chain and greater flexibility.

Use case examples

RTP, especially in combination with Instant Payments, offers tremendous potential for a variety of use cases, in a variety of situations. 

Payment of a (periodic) invoice

The use case that we think will be picked up by the market quickly is the use case of billers that deliver (regular) services or products to consumers, with whom they have a longstanding relationship. Examples of these type of billers are insurance and electricity companies, mobile operators, cloud providers, B2B suppliers, but could also be eWallet providers. As part of the service or product contract, the Payee could easily collect the Payer’s IBAN (or an alias if allowed) and the identifier of the Payer’s RTP SP.

Each time an invoice is created, the Payee will initiate an RTP with its RTP SP. When the Payer logs onto his or her mobile or web banking environment, the Payer will get notified that one or more RTPs are awaiting a response. It could also be that the Payer’s RTP SP sends a notification as soon as it receives an RTP. The Payer will review the RTP and its details and ascertain that it is valid. If allowed and needed, the Payer can then adjust some of the parameters of the RTP and the related payment, such as from what bank account the payment should be debited, when the payment should be executed and/or the amount (if changeable), after which the RTP and the associated payment can be authorised. The Payer can also choose to reject the RTP.

If requested by the Payee, the Payee will receive a confirmation that the RTP has been confirmed. The Payee will always get a notification in case the RTP was rejected. The confirmation of the acceptance of the RTP provides reasonable certainty of payment. What could go wrong? Not much, but the payment execution might fail due to insufficient funds or if the bank goes bankrupt during the processing. The first poses a more common risk, and hence it would have been logical that the successful initiation of the payment would have also been a condition for providing a positive confirmation of the RTP, i.e not only approval of the RTP. This is however not designed into the scheme at the moment. For a 100% payment guarantee, the Payee will have to validate that the payment has been settled in the Payee’s account. This should be easy enough as the Payee’s remittance information will be transferred unaltered through the chain. The only challenge we see at the moment is getting real time notifications of credits to the Payee’s account. That will allow instant reconciliation, for example required for online shops. Not many banks cater for this currently.

Compared to Direct Debits the advantage of RTP is the certainty of payment. When the Payee receives money, the payment is final. With Direct Debit the Payee has to take into account that the Payer has a refund option that the bank will always execute, if requested within 56 days. The other advantage could be that if the payer has confirmed the RTP he or she will most likely have enough funds to complete the payment execution. Up to 3% of Direct Debit transactions are rejected due to insufficient funds. An additional advantage of RTP will be the option for a Payee to attach an invoice to the RTP. Would it not be easy if your invoices are stored and payed in once place?

Point of Sale/Point of Interaction

One of the promising use cases is the combination of RTP with Instant Payments for in-store commerce, at the Point of Sale (PoS). The European Central Bank has already publicly expressed support for initiatives in this area (ECB welcomes initiative to launch new European payment solution).

The user experience however still seems to be somewhat of a challenge. This is partly caused by the EPC design. The first step in the process is the identification of the Payer by the Payee. This requires an information flow from the Payer to the Payee, as in the subsequent RTP message, the Payee identification and the Payee RTP SP identification are mandatory fields. In a PoS scenario, this can be done by tapping your NFC enabled phone, or having the Payee scan a QR code. The latter is a bit counterintuitive, as current prevalent schemes (Payconiq, PayByBank, AliPay) have designed the flow in the opposite direction (i.e. the Payer scanning a QR code presented by the Payee).

Once identified, the Payee sends the RTP to its RTP SP. This can be a bank or a third party. The Payee’s RTP SP forwards the RTP to the payer RTP service provider (which again can be a bank or a third party) for presentment towards the payer. The payer will get a push notification on his phone, will have to open his or her RTP SP app, log-in and authorise the RTP. This will trigger the initiation of a payment towards the Payee. If the Payee RTP SP is his or her account holding bank, the authorisation of the RTP and the subsequent initiation of the Credit Transfer can be made seamless, but when it is a third party, this may require an additional authorisation at his or her bank to comply to the PSD2 Secure Customer Authentication rules. Note that all this interaction only works if the Payer has a smartphone with working internet connection. The scheme currently does not translate well into an offline scenario. A status update is sent upon the approval of the RTP, but this does not guarantee a successful payment as mentioned earlier, as the payment flow and the RTP flow are disconnected in the current design of the EPC RTP scheme. The Payee and/or its RTP SP will have to verify receipt of funds on the Payee’s bank account. If the RTP SP is his bank, this can be done seamlessly, but when it is a third party, this depends on the APIs offered by the Payee’s bank and may be covered by the PSD2 Account Information Service (AIS).

The EPC RTP scheme does have several benefits though. For one, when combined with SEPA Instant Payments, the payee immediately gets credited. In specific branches and markets, this may significantly improve the merchant’s cashflow, also in the weekends. Second, the scheme allows for far richer data to be transported than a traditional card payment. Specifically, the message set allows for attachments, which could be utilised to include a cashier’s receipt or invoice with the request. Having a user friendly and durable storage of receipts may be the killer feature for the consumer. Additionally, RTP SPs might be very interested to use the richer data for value add services.

In a next version of the scheme, the EPC may consider making some adjustments to better cater for the PoS use case. An integrated feedback loop which creates certainty for the merchant would be a big improvement. In the current design, the Payee’s RTP SP either needs to invoke a PSD2 AIS pull, or the Payee’s bank needs to supply a webhook. Webhooks are “user-defined HTTP callbacks”. They are usually triggered by an event, such as in this case the arrival of funds on the account. When that event occurs, the bank makes an HTTP request to the URL specified by the RTP SP, so they get notified proactively.

But this only works in the scenario in which the RTP is used in combination with SEPA Instant Payments. To allow for other payment methods to work in the PoS use case, a notification of RTP approval and successful initiation of the payment is a necessary addition. Secondly, the EPC may consider introducing the ability to send ‘generic’ payment requests (i.e. make the Payer identification optional instead of mandatory). This would simplify the first step in the payment process and would allow for a reverse flow as is currently the case in several other RTP schemes (such as Tikkie from ABN AMRO or the payments request functionality from Bunq for example).

Online Commerce

Payments in online commerce are an interesting topic, especially in a European context. In the offline, brick-and-mortar commerce world, payments are dominated by cards. There are multiple schemes, and some countries tend to favour credit, where others favour debit, but in general, the payment method is the same; a piece of plastic and a PoS-device.

The online commerce world is vastly more differentiated. In Austria, 43% of consumers pay by invoice (i.e. a fully decoupled process), in Belgium, 51% use credit card. In the Netherlands, 84% use iDEAL (a predecessor of PSD2 PIS of some sort and the RTP for that matter), while for a merchant to be successful in Slovakia, you need to offer cash-on-delivery (source: DPD E-shopper Barometer). As such, there is no single use case for RTP to compete with in the online commerce payments landscape, and there are cultural barriers in addition to technical ones.

Similar to the PoS use case described above, the RTP flow starts with the identification of the Payer. When you are a recurring buyer at a specific online merchant, you may have created an account and your identification and preferred RTP SP may already be known to the merchant, but for first time use, the Payer will need to provide these details. Note that the Payer identification does not need to be his or her IBAN, it is the identification of the Payer at his or her RTP SP, and can thus be a less sensitive data such as his or her email-address or mobile phone number.

From here, the process follows the same flow as described above. The Payee RTP SP sends the RTP to the Payer RTP SP for presentment to the Payer. This can potentially be done via an app-to-app redirect if the transaction takes place on the mobile device. After authorisation, the Payee gets confirmation and a similar challenge as in the PoS use case emerges, as the confirmation of the RTP does not constitute successful transfer of funds – only confirmation that RTP was accepted – in the current design of the EPC RTP scheme.

In addition to the benefits mentioned in the PoS use case (the immediate access to funds when combined with Instant Payment and the ability to include the invoice in the request), is the combination of the RTP with a SEPA Credit Transfer. i.e. a Credit Transfer is a push payment and, as such, irrevocable. Some of the payment methods used online expose the merchant to customer initiated refunds (which have seen a big surge since COVID-19 by the way, source: Businesses Warned of Surge in Opportunistic Chargebacks Fuelled by COVID-19).

Petrol Stations

One specific and interesting use case is for payments at fuel stations (petrol or increasingly also charging of electric vehicles). As each vehicle is already equipped with a unique identification code, the vehicle registration number, the car’s license plate could be used as an alias in the RTP flow. Using licence plate image recognition, the petrol station or electric vehicle charging point can uniquely identify the car and release the pump, on the prerequisite for example that the owner has completed a one-time registration of the licence plate prior the visit. The car is filled up and, once finished, an RTP is sent to the Payer. This request includes the receipt, which can be used for VAT and other tax declarations, as it contains a link to the Payer (which normal cashier’s receipts do not).

Keys to a successful deployment and European take up

The RTP aims to provide a standard for all 28 countries that are part of the SEPA area. The good news is that the scheme is designed to be open, based on the four-corner model also allowing non-banks to play a role and provides flexibility to support many use cases. However, as a little more than a decade of SEPA payment history has shown us, the devil also hides in the details of flexibility and openness. It has led to country (or even bank) dialects that hamper SEPA-wide roll out and adoption. Some of the challenges to fast adoption in Europe are:

• The Payer identification process is not standardised. Using the IBAN is possible but the process also allows for use of an alias, potentially leading to interoperability issues.
• The means of supplying the identification from the Payer to the Payee is not standardised, for instance at the PoS through QR or NFC.
• End-to-end user experience is not really defined and will differ, hampering adoption; a good example was given in the last years by the UK the open banking workgroup, providing guiding principles for user interaction

Additionally, interoperability between communities or countries is a challenge. How will RTP SPs be able to find each other efficiently? This will require a routing table of some sort. This has not yet been defined. Who will pick this up? Furthermore, the scheme is optional, i.e. there is no deadline (yet) for scheme adoption. In itself this tends to lead to slow(er) and fragmented market adoption. This is also the case for one of the underlying payment instruments, the Instant Payment. Not all banks have rolled out Instant Payments, not all countries have the same processing timelines and some of the banks are only reachable in their community. We think that more focus is required to standardise the deployment of the RTP, especially as the ECB is now putting a lot of importance on European led, SEPA-wide innovative payment instruments.

The sky is the limit

Looking ahead, beyond the aforementioned use cases, we can see tremendous potential for value-added services on top of the standardised RTP scheme. During the transaction, the user has a rich and interactive user interface at his disposal, as opposed to, for example, a card payment. This enables the RTP SP to offer additional services outside of the scope of the RTP. For example, in the scenario of a pay-now payment, which needs to be paid in full per the conditions set by the Payee, the RTP SP could offer the payer the option to pay in instalments, effectively offering instant credit to the Payer. Potentially the RTP can be turned into a Direct Debit by the Payer RTP SP offering a mandate option to automatically authorise RTPs (under clear conditions!).

Other value-added services could also be offered as part of, or on top of the scheme. The scheme for example allows for attachments to be included in the request. This allows not only for invoices, but also cashier’s receipts to be included. The RTP SP could offer a safe repository for all these documents. Taking this one step further, it could even offer additional value based on the contents of the receipt. For instance, if the RTP request was for a new television, an extended warranty could be offered; or in the case of an RTP request for airplane tickets, travel insurance could be offered.

The immediate benefits from RTP are clear. It will allow for greater flexibility for the Payer, with options such as pay-later and pay-in-instalments. RTP could reduce costs for merchants, with the promise of 100% reconciliation and, as Accenture states “from an accumulation of factors; switching from paper to electronic billing and reducing time and effort in chasing late payments.” And with the promise of value adding services, the future is bright and the sky is the limit.

Contributors

Mark Munne has spent the last decade making payments less painful by using new technology, innovative ideas and common sense. Mark has successfully launched new products and services such as Instant Payments in The Netherlands, Clearing and Settlement in Aruba and SEPA at ABN AMRO.

Linkedin: Mark Munne

Paul van der Valk is a senior international professional specialised in payments consultancy, program and product management with strong focus on innovation and business development. In the last 20 years he has been involved in projects for the development and implementation of SEPA & Instant Payments (SCTinst), PSD2/Open Banking, (SEPA) Request to Pay, CSM (ACH), Payments Outsourcing, Payments Engine, Payments SaaS services.

Linkedin: Paul van der Valk

Request to Payment Cheat Sheet

SEPA Request to Pay Cheat Sheet