Use Cases of Request to Pay
This article was originally posted to Linkedin and is an excerpt of a white paper I wrote together with Paul van der Valk. The full version of the white paper, titled can be found here: https://www.linkedin.com/posts/paul-van-der-valk-63b6391_practical-guide-to-sepa-request-to-pay-activity-6712078788357828608-LKYj.
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”.
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).
There are further use cases, such as Online Commerce and Petrol Stations, and some challenges, such as interoperability between RTP SPs, which I will address in a future article. In short, RTP has the potential to significantly boost the Instant Payments volume. If you want to read the full white paper, this can be found here: https://www.linkedin.com/posts/paul-van-der-valk-63b6391_practical-guide-to-sepa-request-to-pay-activity-6712078788357828608-LKYj.