Standardizing Payment Requests with Request to Pay
You may have already heard of it, but do you really know what is RTP? Request To Pay, or RTP, is a scheme that aims at standardizing the way companies send payment requests to their customers.
A little background
In 2018, the EPC — European Payments Council — created the Request To Pay working group. This group is responsible for defining the rules of a scheme that allows companies to send payment requests that result in an SCT (inst) transfer.
The creation of this working group is the result of a double desire on the part of the European authorities. Firstly, to democratize bank transfers, and in particular the instantaneous bank transfer.
Secondly, there is the desire to digitalize company invoices. Indeed, all invoices between professionals (B2B) will have to be sent electronically by the next years. This is already the case for invoices sent to the public sector since January 1, 2020. The next deadlines are January 1, 2023 for large companies (Update: recently postponed to July 2024), and January 1, 2025 for SMEs.
As a result, the RTP scheme defines both the payee’s journey (how the link should be generated, and presented to the payer) and the payer’s (how the payer can accept/refuse the payment request, and give instructions on whether the bank transfer should be executed now or later). However, it is important to understand that the payment itself is outside the scope of the system. It is not a question of knowing how the payment will be made, but simply of making the payment request.
This will give birth to a new type of player: the RTPSP, or Request To Pay Service Provider. And these players will not necessarily need to be from the payment industry.
As mentioned in the introduction, RTP can be used for payments between individuals, but the main use case is for B2B invoicing. It will also be possible to use it for C2B for in-store mobile payments and subscriptions, or C2G for tax payments, among other use cases.
How does it work?
The Request To Pay scheme requires a clear path that is relatively easy to follow. The first step is the RTP initiation. The payee indicates the different parameters of the request such as the amount, the order reference, the validity of the link, the recipient, etc… Then, the RTPSP of the payee validates the request and sends it to the RTPSP of the payer.
The second step is the RTP submission. The payer receives a notification for the payment request. The payer identifies himself to his RTPSP and accesses the request.
Next comes the step of RTP acceptance or refusal. As the name suggests, the payer can accept or decline the request. If he accepts, he can choose to defer his payment within the limit possible and therefore specify whether he wants an immediate or deferred transfer. The answer is then sent back to the payee’s RTPSP.
Finally, to pay, the payer selects his bank, identifies himself and validates the transfer via a strong authentication.
The process is therefore quite simple to follow, but there are still a few milestones to be reached before this solution can be used. Since June 15, 2021, the scheme has entered into force and is now open for applications. On November 30, the second version of the rulebook will be published, including details on the technical specifications and rules related to the enrolment and activation of payers/payees by the RTPSP, and will come into force during 2022.
It is a busy agenda ahead for the RTP, and for now some important chunks of the scheme are still missing to make it fully operational.
However, the need for a merchant to be able to send payment requests is real, and Market Pay already has a solution to address it with an existing portal to handle payment requests driving to its Pay by Bank solution.
Market Pay’s Request to Pay Solution
Market Pay’s Pay by Bank solution simplifies bank transfers for both merchants and customers on ecommerce. Combined with the Request to Pay solutions, it allows merchants to address a wider variety of use cases: from automatic invoicing, to debt collection, or even instore payments for large amount transactions.
Concretely speaking, it enables merchants to insert payment links in any invoice, whether ad hoc or recurring. Those payment requests can be shared across all channels, including emails, SMS, messaging apps, and physically via QR codes.
Here again, the process is very simple:
- The merchant (the payee) generates his payment link by setting it up manually or automatically. He can add all the necessary information such as the amount, the order reference and the recipient for example.
- He then creates or uploads the template of the message or invoice he wants the payment link to be inserted into.
- The merchant sends the payment request and the customer receives it containing a payment link (URL, email, SMS, QR Code, Chat…).
- Then, the customer selects his bank and validates the transaction with his bank, in a seamless process (without entering an IBAN).
- The bank transfer received by the merchant on his bank account contains the order reference he indicated at the beginning of the journey, which simplifies its reconciliation.
The merchant can monitor the status of the payment at any time and can set up manual or automatic reminders in case of unpaid invoices. Advanced features are already available such as staggered payments, programmable payments, automatic reminders and others.
Market Pay constantly monitors the payment market and the innovations and opportunities that arise. We are always looking for ways to innovate in order to provide payment experiences that are close to the needs of merchants and consumers.
Because we are born in retail to drive payment.