Request-to-pay has the potential to become a revolution in payments, as it can completely change the payment experience as we know now. In a series of articles, we will collect and share information from the very basics about request-to pay to end user business cases and outline the key success factors for customer onboarding targeting those elements that are missing pieces but could be addressed by banks as service providers.
This article is the first piece of the series introducing the very basics about request-to-pay.
What is request-to-pay (RTP)?
“Request-to-pay is a messaging functionality. It is not a payment means or a payment instrument, but a way to request a payment initiation.
The scheme can be considered as a complement to the payment flow because it supports the end-to-end process and lies between an underlying commercial transaction and the payment itself. An RTP as such can be seen as an enabler for digital payments.
A request to pay means that a payer and a payee electronically exchange structured data through a request for payment, before they exchange the money. Request-to-pay improves the standard payment process by adding a message exchange, which takes place before the actual payment and includes:
1 A request to the payer for a payment,
2 The acceptance (or refusal) of this request by the payer[1]. “
Request-to-pay is an overlay service that is made available in instant payment schemes. Not all instant payment schemes support request-to-pay, but it is available in a lot of those: in Europe the SCT Inst (20 European countries), the UK, Poland, Hungary, Sweden and Denmark instant payments schemes provided this functionality as of 2020[2].
The service is generally open to banks and PISPs and it allows the choice for the method for the payment execution (e.g., instant payment or credit transfer).
The request-to-pay process can be described as below:
- Sending a payment request from the payee to payee’s PSP
- Sending the payment request from the PSP to the payment scheme’s service
- Sending the payment request from the payment scheme’s service to the payer’s PSP
- The payer’s PSP presents the payment request to the payer with the option to approve or reject the payment request
- The payer approves or rejects the payment request at its PSP
- The payer’s PSP sends the confirmation/rejection message the payment scheme’s service
- The payment scheme’s service sends the confirmation/rejection message to the Payee’s PSP
- The Payee’s PSP presents the confirmation/rejection message to the Payee.
This is a so-called 4-corner model, where the 4 corners are:
- The Payee,
- The Payee’s PSP,
- The Payer’s PSP,
- And the Payer.
This model has the advantage to ensure the interoperability among all participants, because the service providers exchange messages in a standardized format on the payment schemes infrastructure, but they can develop their own services and value propositions to end customers just like in payments.
Advantages
The most important advantage comes from the nature of request-to-pay, as it is a message, and it contains additional information about the payment transaction that has been requested.
The payee can include information in the payment message about additional information related to the transaction, such as:
- reference numbers (e.g., contract number or invoice reference),
- these reference numbers will create a link between the business transaction and the payment transaction, which enables automatic reconciliation,
- the requested payment deadline.
The payer can provide additional information about the requested payment, whether:
- it approves or rejects the payment request,
- it can fulfil the request in full or only partially,
- in case of rejection or inability to pay, it can provide additional information about the reason of rejection or ask for an extended payment deadline.
Because of the real time nature of the messaging and payment initiation the request to pay together with instant payments can be a viable alternative for card payments in certain situations.
Use cases
The related use cases exist in all kinds of relations:
- business to consumer: at a physical retail point of sale or e-commerce instead of a card or cash payment; in bill payments it can substitute direct debit mandates,
- business-to-business: invoice payments can happen with request-to-pay, enabling reconciliation automation,
- business/consumer to government: requesting payments for taxes or fines,
- peer to peer: requesting funds from a private individual within the family or sharing expenses.
Benefits to end customers: service quality and cost benefits
Request-to-pay provides service quality improvement for consumers and businesses alike: better information and more control over payments improves the service experience. For businesses the data quality related to payments improves, as invoice/receipt data can be linked directly with the payment transaction. Together with the digitalization of financial administration processes in enterprises this implies a 95% cost savings potential.
[1] Source: European Payments Council: https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/sepa-request-pay-scheme
[2] Austria, Belgium, Cyprus, Estonia, Finland, France, Germany, Greece, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Monaco, the Netherlands, Portugal, Slovakia, Slovenia and Spain. Source: FIS Flavors of Fast Report, 2020.
