Request to Pay is changing payments – first use cases

The payment request or, in business terms, Request to Pay (R2P), is a new payment instrument that is set to change payments for the long term. In the whitepaper “Request to Pay completes the electronic payment process”, I have already explained the relation between electronic billing, instant payments and the hitherto missing payment instrument Request to Pay.

I will use this blog entry to present the first few of many use cases which can be easily addressed to an existing bank account via Request to Pay:

  • Request to Pay in case of an already sent commercial invoice: an easy use case is that the invoice has already been sent in a classic way and a Request to Pay is additionally sent afterwards. This use case primarily focuses on speeding up the settlement of the due invoice by facilitating the invoice data processing for the debtor. The Request to Pay related to the invoice that the debtor has already received is displayed to him in his online or mobile banking application with the recipient data, the payment amount and the remittance information already filled out. The debtor only needs to confirm the data and sign the execution with his credentials.

  • Request to Pay combined with a commercial invoice: of course, the previously described use case is also conceivable if both an electronic invoice and the associated Request to Pay are to be presented to the debtor at the same time in his online or mobile banking application. The conventional postal dispatch is thus eliminated and the debtor can view his invoice digitally and pay it in a simple manner. This method also offers the option to digitally store the invoice in a banking archive and to digitally match it with a payment at any time.

  • Request to Pay in step-by-step transactions: needless to say, Request for Pay is useful for more than just scenarios with separate locations. It is thus also conceivable to digitise the previous cash on delivery method. The supplier addresses a Request to Pay message to the recipient who then verifies the product delivery and initiates an instant payments order as response to the request. The supplier is informed via a notification that the payment has been received and releases the product.

  • Request to Pay in stationary trade: similar to the previously described case, Request to Pay could also be used with instant payments and notifications in stationary trade. In this case, it is not the invoice but the purchase receipt that is transported with the Request to Pay message and can be stored in a digital archive at the account together with the booking. The cashier personnel release the purchase only once the notification has come in.

As demonstrated, payment requests are applicable in many sectors and I therefore believe that the new payment instrument Request to Pay is bound to change payments as we know them on a lasting basis. I will continue to post frequent updates on current developments and additional use cases on this blog.

Author: Eric Waller

Announcement: Extension of PPI’s EBICS blog – all about payments!

Dear readers,

We are pleased to inform you today about the extension of our EBICS blog.

In the PPI EBICS blog "All about payments" we would like to keep you up-to-date about current payment trends and topics concerning EBICS, SEPA, SWIFT, regulation and digitisation.

From now on the EBICS blog is maintained by two teams of authors in a 2-week rhythm. Our goal: to give you a first-hand account of the views and experiences of our product and consulting experts from customer projects, studies and white papers with regard to current and future requirements of the payments market.

We look forward to your feedback and hope you enjoy reading this blog!

Your team of authors at PPI

Real-time notifications and EBICS – no more "hopeful queries" for downloads

As I already wrote in my blog post in December 2018, real-time credit transfers (instant payments) in the corporate customer business are making their way into the world of EBICS via the new bulk format. When uploading real-time credit transfers, the EBICS transfer phase is not subject to the strict synchronous time rules of instant payments. The clock starts ticking only after the EBICS bank server processing.

But what about the opposite direction for instant payments business transactions in EBICS? After all, a credit notification, if not possible in real time, should still be sent to the payment recipient as soon as possible. In the standard role relationship between customer and bank, the EBICS client always downloads the information from the bank server. An active provision by the bank via EBICS is not intended. Especially the business community has urged the banks and the German Banking Industry Committee (Deutsche Kreditwirtschaft) to find a pragmatic solution for a push option. The ultimate goal was to develop a solution that could be implemented without the need to change the EBICS protocol and the role concept.

The result was the idea to create a new web socket-based standard interface that informs EBICS clients when new information is available for download. This also includes information about a newly available credit notification. This new push channel is thus not used to transfer any sensitive data. The download of the relevant sensitive data is still carried out via the secure EBICS channel.

In the meantime, the Deutsche Kreditwirtschaft has described this new interface in the "Spezifikation Echtzeitbenachrichtigungen" (specification for real-time notifications) and published version 1.0 on July 18, 2019 on the German EBICS website (

Now the interface must be implemented in the EBICS clients and EBICS servers in a standard-compliant and timely manner. This development opens up new possibilities for optimising corporate customer business, even independently of instant payments. For example, the frequent and ongoing "hopeful queries" by automated EBICS clients (as performed in case of account statement downloads) can be eliminated for all download processes. This means that both EBICS client users and bank server operators can expect a load reduction. That's good news, isn't it?

Author: Michael Lembcke