What Do Treasurers Need to Know About Request to Pay?

 

One of the hottest topics at EuroFinance this year seems to be Request to Pay. By way of background, the advent of real-time payments and open banking, together with the rise of open application programming interfaces (APIs), has seen Request to Pay schemes being developed in geographies across the globe.

While much has been written about the potential of Request to Pay for making the payments process more seamless from a customer experience perspective, there are also many reasons why treasurers should pay attention to this development.

Although it is often referred to as an ‘instant direct debit', Request to Pay can be used for single, ad hoc payments too, and is an evolution of today's electronic bill presentment and payment solutions. As well as offering all the benefits of real-time collections, Request to Pay also requires no static upfront mandate from the payer. Moreover, there are no extended rights of revocation. All of which will be music to treasurers' ears.

But how does Request to Pay work? Dean Wallace, Head of Product Management, Real-time Payments, ACI Worldwide gave TMI a practical explanation (although consumer-focused there are/will be opportunities in the B2B world too) back in our August issue: “Let's say you – as a consumer – have agreed to pay your gas and electricity provider using Request to Pay instead of a direct debit. Your provider would most likely send you a 'request to pay' as an app notification on your mobile.

“You (the consumer) would then tap or swipe to open the authorisation screen. Key information about the requested payment would be displayed and a thumb print reader enabled on that screen. The consumer would check the information, press their thumb on the reader, and that's it, job done – 1 screen, 2 taps, 3 steps. Request paid.”

And, as alluded to, the technology enabling all of this is APIs. So, for those treasurers wondering how APIs can be put to practical use (another hot topic at EuroFinance right now), Request to Pay is a great example.

Of course, no solution is perfect and there are potential sticking points in the Request to Pay workflow. The payer may not instantly approve the payment, for example, which makes it no longer real-time. Payers also have the option to delay payments, which again defeats the ‘instant' benefits. Nevertheless, with everything being performed digitally, the payee is kept informed of any delays, enabling them to predict cash flows more accurately.

We will no doubt hear more about Request to Pay in the months ahead, and as the value limits on real-time payment schemes are raised, the opportunities of this new payment/collection method will move into the B2B arena….watch this space.