Request to Pay

A Value Add Service of Instant Payments, Request to Pay

Request to Pay Lifecycle

Request to Pay (RtP) is a payment service that allows a payee to request payment from a payer. In the context of instant payments, RtP enables individuals and businesses to send a payment request to their customers, suppliers, or partners, and receive instant payment in return.

Figure (1) A Ty[ical Request to Pay Lifecycle

• The RtP initiation is a stage specific to the Payee whereby the content of the RtP is populated. Mandatory elements such as the amount to be paid, transaction reference, Payer, and Payer’s provider identifier should be included at this stage.

• The RtP presentment can be defined as the moment when the RtP is received by the Payer. It can be assumed that once created, the RtP is immediately sent and presented as there is no business need to delay this stage, even though for technical reasons there could be a certain delay until the moment when it is made available to the Payer.

RtP can take various forms and can be presented in various ways, such as:

• In physical stores, as a data flow sent by the merchant (Payee) device (e.g. payment terminal) to the consumer (Payer) device (e.g. mobile phone) using proximity technologies such as reading QR-codes, BLE or NFC.

• In e-commerce websites presentation of the payment related data in a check-out webpage.

• In e-invoicing (B2C and B2B), usually the RTP is linked to an e-invoice for later payment.

• In P2P, it can be sent from the Payee mobile device to the Payer mobile device using proximity technologies or messaging applications

• The acceptance or refusal is the moment when the Payer utilizes an application (mobile application, Web browser, USSD, SMS) installed in a physical device (e.g. smartphone, PC, feature phone) to accept or refuse an RtP, usually by clicking on “confirm”, “accept”, “pay” button, or “decline/refuse” button.

The Payer can accept the RtP – and this acceptance can be followed by an immediate or future payment - or refuse it and optionally specify a reason for refusal. Payments are executed after customer authentication if necessary, some use cases require immediate payment, for example when used in the context of payments in physical stores or e-commerce websites.

• The “status report” is the step where the Payer's acceptance or refusal is transmitted to the Payee via a status report message. Depending on the use case the status report can be linked with the payment initiation. In case of acceptance, the payer gives its PSP the instruction to initiate the payment. The Payer’s PSP is committed to executing the payment at the execution date in respect of the current regulation and the obligations set by the payment schemes.

• The payment initiation, even though not part of the RTP lifecycle itself, is included to illustrate the close link it has with the RTP, as it uses payment data from the RTP and is performed upon the Payer’s action.

• The notification of the execution of payment instruction, also not part of the RTP lifecycle itself, is included to illustrate the possibility that the Payer’s PSP notifies the Payee’s PSP that the payment instruction has been executed.

Types of Request to Pay

There can be basically two types of Request to Pays that are derived from the immediate and deferred timing aspects that are “accept now” or “accept later”, as well as "pay now" or "pay later".

• “accept now”: the RTP must be accepted immediately, at the presentation time. A user action of type “Accept”, “Confirm”, or “Pay” implies both acceptance of the RTP and initiation of the payment.

• “accept later”: the RTP can be accepted at a later time than the presentation time.

• “pay now”: the RTP must be paid by the Payer immediately, at the acceptance time. It might be possible that the payment is “embedded” in the acceptance, meaning that by accepting the RTP, the Payer automatically initiates the payment of the RTP. In that case, a user action of type “Accept”, “Confirm” or “Pay” implies both acceptance of the RTP and initiation of the payment.

• “pay later”: the payment is initiated at a later term than the acceptance time. Depending of the use case the Payer may indicate a date and time for the payment, accept a time predefined by the Payee, define installments, or indicate the intention to pay upon the reception of the purchased goods or services.

Message Sequence

Figure (1) Request to Pay Message Flow between FSPs and the Switch