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 for 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 twofold desire on the part of the European authorities. On the one hand, to democratize bank transfers, and in particular the instant transfer.

Secondly, there is the will to digitize the invoices of companies. Indeed, all invoices between professionals (B2B) must be sent electronically within the next few years. This is already the case for invoices sent to the public sector since January 1st 2020. The next deadlines are January 1, 2023 for large companies (Update: recently postponed to July 2024), and January 1, 2025 for SMEs.

Therefore, the RTP system defines both the payee's path (how the link is to be generated and presented to the payer) and the payer's path (how the payer can accept/deny the payment request and instruct the wire transfer to 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 about how the payment will be made, but simply about making the payment request.

This will give rise to a new type of actor: the RTPSP, or Request To Pay Service Provider. And these players will not necessarily have to be from the payments industry.

As mentioned in the introduction, RTP can be used for B2C payments, but the main use case is B2B billing. It will also be possible to use it for C2B for mobile payments and in-store subscriptions, or C2G for tax payments, among other use cases.

HOW DOES IT WORK?

The Request To Pay system requires a clear and relatively easy to follow path. The first step is the RTP initiation. The beneficiary indicates the various parameters of the request such as the amount, the order reference, the validity of the link, the recipient, etc... Then, the payee's RTPSP validates the request and sends it to the payer's RTPSP.

The second step is the submission of the PTR. The payer receives a notification for the payment request. The payer identifies himself to his PSTN and accesses the request.

Next comes the step of accepting or rejecting the RTP. As the name suggests, the payer can accept or decline the request. If he accepts, he can choose to defer his payment as much as possible and therefore specify whether he wants an immediate or deferred transfer. The response is then sent back to the Payee's PSTN.

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 steps to be taken before this solution can be used. Since June 15, 2021, the system has been in effect 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 enrollment and activation of payers/payees by the RTPSP, and will go into effect during 2022.

The RTPSP agenda is full and, at this time, there are still a few important elements of the system that are 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 process payment requests leading to its Pay by Bank solution.

MARKET PAY'S PAYMENT REQUEST SOLUTION

Market Pay's Pay by Bank solution simplifies bank transfers for merchants and e-commerce customers. Combined with Request to Pay solutions, it enables merchants to address a wider variety of use cases, from automatic billing to debt collection to in-store payments for large-value transactions.

Specifically, it allows merchants to insert payment links into any invoice, whether one-time or recurring. These payment requests can be shared across all channels, including email, SMS, messaging apps, and physically via QR codes.

Again, the process is very simple:

  • The merchant (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 in which he wants to insert the payment link.
  • 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 transparent process (without entering an IBAN).
  • The transfer received by the merchant on his bank account contains the order reference he indicated at the beginning of the process, which simplifies its reconciliation.

The merchant can monitor the status of the payment at any time and set up manual or automatic reminders in case of unpaid invoices. Advanced features are already available such as installment payments, programmable payments, automatic reminders and more.

Market Pay is constantly monitoring the payments market and the innovations and opportunities that arise. We're always looking for ways to innovate to deliver payment experiences that are close to the needs of merchants and consumers.

Because we are born in retail to drive payment.