Request-to-Pay: from real-world solutions to holy grail

Jeroen Dekker, Solution Architect at Serrala elaborates on the key takeaways regarding Request-to-Pay

Request-to-Pay (RtP) pushes payment instructions from a biller to a payer and into the payment flow. This makes it easier to pay and enables accurate matching later. Standards, networks, features, channels, and payment methods aside – that is the essence of the buzzword you have been seeing. We know it, as we have been preaching and practicing it since 2008, starting in the Netherlands. This article discusses the benefits, use cases, flavours, and success factors for using this powerful and versatile concept that the industry is waking up to.

Reasons to adopt the core concept

RtP benefits everyone involved, from bean counters and customer success people to recipients. 

Customer experience 

Instead of creating a bank transfer from scratch or writing a check, the payer simply authorises the predefined payment. From their bank account or mobile wallet, whether the RtP landed there directly or through an email or conversational inbox – no typing, no mistakes, just a few familiar taps or clicks with additional options like delay or split, if enabled by the biller.

More payments faster

The convenience makes payers more likely to pay straight away, and therefore not forgetting about it. In finance terms, this means lower DSO, more cash flow, better working capital. 

Real-time visibility

Done right, an RtP tells the biller in real time that the payment was authorised and money is on its way. Several populations benefits include:

Automated matching

Crucially, pushing the source system’s unique reference (like an invoice number) into the payment enables automated and successful matching. That is almost a given with individual account-based payments, but often is requires systems integration if a PSP takes care of the payment. 

Process automation & efficiency 

The basic concept already streamlines a lot, however codifying common exceptions further eliminates scenarios previously handled by phone calls and emails: asking for extra time, a payment plan, or objecting to the bill. Arming the RtP with a due date also enables timely digital reminders.

Examples and use cases

Corporates in insurance, utilities, telco, automotive, housing, online retail, consumer finance, education, and more use our vendor version of RtP. Starting from ERP, CRM, AR, Customer Contact, or Accounting systems, they generate and deliver payment requests for many purposes, such as:

The RtP evolution

First came the paper invoice, and then its digital equivalent (email/PDF). Making the details scattered across the page usable for the actual payment came with the payment link we popularised. The destination URL offers the appropriate online payment options – cards, e-wallets, BigTech Pay, but also local cross-bank account-based payment methods like iDEAL, EPS, Sofort (now Klarna) or PayWithMyBank. The process involves direct, increasingly fixed fees, which are irrevocable from the place where most folks receive and keep their money.

PSD2 and Open Banking will also bring pay-by-bank to other countries, with an RtP connecting a source system to the payer to their bank’s API. If the EPC and Pay.UK initiatives succeed, bank and other PISP apps become inboxes to directly receive and pay requests from billers – whether those are corporates, small businesses, or individuals.

Keys to success

That last incarnation requires mass adoption by companies to deliver them directly into PISP apps, and by people to want them there. What comes first?

On the biller side, the key ingredients to leverage any generation of RtP remain the same:

1. Source system integration: The RtP river starts in systems that know Who needs to pay What, and by When. Can a company effectively generate, deliver, and track batches of bills, invoices, reminders, or on-the-fly transactions during a conversation or online purchase, at scale as an end-to-end process? 

2. Choice and orchestration: PayPal from an email, Apple Pay from a chat, pay-by-bank in a portal or directly into and from the bank app. People have preferences, so corporates need something to offer customers choice and orchestrate across channels, use cases and payment providers.

3. Trust and need: New ways to do things only get adopted if people trust and need them on both sides. Does it solve a problem? Is the solution secure? This requires technology, of course, but also education and communication.

Request-to-Pay is available today to deliver most of the benefits touted by industry initiatives. Implementing it today also puts corporates in prime position to quickly join network initiatives when they reach critical mass.

This article was published in our Payment Methods Report 2020, an extensive overview of what’s new in how people pay in the most relevant ecommerce markets.

Jeroen Dekker

Jeroen Dekker manages the Solution Architect function for Serrala’s Request-to-Pay and EBPP solutions. In this role he defines, articulates and delivers new and existing capabilities and use cases to customers and the market at large. Jeroen is a career professional at innovative international b2b software companies like NetEconomy, Fiserv, eVision and most recently AcceptEasy, which joined Serrala in February 2020 after a decade of delivering Request-to-Pay solutions to corporates. In his product leadership role at Fiserv, he worked with many banks and insurance companies around the world on detecting and preventing financial crime risks. 

About Serrala

Serrala is a global B2B fintech creating more secure payments capabilities for every enterprise. The company provides unparalleled end-to-end services from inbound to outbound payments. With offices around the world and over 700 employees, we are proud to be a trusted solution provider to over 2,500 customers across industries. In February 2020, Serrala acquired Dutch SaaS-provider AcceptEasy and its market-leading Request-to-Pay platform.