Navigating the World of Request to Pay

A Global Overview of the Implementations and Functionality

Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace

Learn payments with The Engineer Banker

---

In an era where the evolution of digital payments is at its zenith, 'Request to Pay' emerges as a transformative, agile, and flexible solution that is redefining the payments landscape. This article will explore the mechanics of Request to Pay, its global implementations, and present real-world examples to elucidate this innovative payment feature.

At its core, 'Request to Pay' is a financial communication tool rather than a payment method. It allows a payee (receiver of funds) to send a payment request to the payer (remitter of funds), who can then respond by fulfilling the payment request through various payment methods or engaging in communication if needed. This digital payment model enhances control, improves cash flow, and offers an agile approach to settling transactions. Be aware that some implementations of request for payment around the world might differ on the capabilities offered, in this article we will try to summarize what we consider a typical implementation of RtP.

In a nutshell, 'Request to Pay' is like a digital tap on the shoulder asking someone to pay up. It's a handy tool that lets anybody – whether you’re just a person, a shop owner, or even the taxman – shoot over a payment request to someone else. So, if you need to split the pizza bill with friends, send a gentle nudge to a customer who bought stuff from your store, or if the tax authorities need to remind folks to pay their taxes, ‘Request to Pay’ is everyone’s go-to buddy for making sure money gets from one pocket to another. It's pretty much like saying, "Hey, you owe me this much. Mind settling that when you get a sec?"

Request to pay is not a means of payment or a payment instrument, but a way to request a payment initiation.

Request to Pay often goes hand-in-hand with two additional components: account proxies or aliases such us phone numbers or emails, facilitated through a directory integration which will translate from the proxy to the end customer or account. This provides a significantly enhanced user experience as it's far more intuitive and convenient to send a request to an email or phone number, compared to an impersonal and complex IBAN. The second key component usually connected to request to pay capabilities is a real-time payment infrastructure that streamlines the end-to-end process for all parties involved.

For instance, in Spain’s popular Bizum payment method, the payer is typically identified using a "proxy" which can be an email address or phone number linked to the payer's bank account. The key to this process is that it operates via a secure directory service that maps these proxies to bank accounts. When a payee initiates a Request to Pay, they use this proxy instead of needing to know the payer's bank account details. Once the request is initiated, it's sent to the payer's bank (or other payment service provider) who then delivers it to the payer.

By utilizing this proxy approach, the Request to Pay framework in the Spain enhances privacy and security by limiting the sharing of personal bank account details while still ensuring the payer can be correctly and securely identified.

The Bizum directory allows the registration of only one phone to IBAN mapping at a time. If a user wishes to update the IBAN associated with their phone number or email, they must initiate the portability flow.

In today's discussion, however, our primary focus will be the Request to Pay mechanism itself.

How does it work?

Alright, let’s break down this whole 'Request to Pay' thing into easy-to-digest bites. Imagine you run a little online store, and you’ve got a customer who needs to pay you. Or maybe you’re just trying to get your buddy to chip in for last night's takeout. Either way, 'Request to Pay' is about to become your new best friend.

Step 1: Sending the Nudge So, you need to get paid. The starting point is when the you fill the payment details and shoot the request to the payer. It’s like a friendly reminder that says, “Hey, remember that money you owe me?”. You can shoot this over through an app, online banking, or whatever system you’re using. This is your opening move, setting the stage for getting that cash.

Step 2: You’ve Got a Message Now, over on the other side, your customer or buddy gets a notification. It could be an alert on their banking app, a text, or an email. Basically, something pops up to tell them, “Heads up! You’ve got a payment request waiting.”

Step 3: Time to Make Decisions This is when request for payments gets interesting, first two steps are basically a digital notification functionality, now depending on the request to pay implementation the payer can decide the payment method, delay the payout, pay partially, open a conversation, etc. Here’s where your customer or friend gets options. They can take a look at your request and decide to pay you right away (awesome!), or maybe schedule it for payday. If they’re not happy with something or need to pay a different amount, they can send a message back. Worst case, they decide not to pay at all (boo!).

Step 4: Show Me the Money! If all goes well, this is where you get paid. Your customer or pal agrees to the request and decides how they want to send you the money. It could be a bank transfer, card payment, or another fancy digital payment thingy. Once they hit ‘pay’, the money starts moving.

And, that’s it! Request to Pay in a nutshell – a super simple way to ask for and receive money without all the awkwardness or chasing people down. Plus, it works for everyone: people, businesses, and even the government when it’s tax time. It’s like having a polite and super-efficient personal assistant that handles the money talk for you.

A payment request undergoes various stages during its lifecycle. Initially, when a payee sends a request to a payer, the payment request is in a "pending" state, indicating that it is awaiting action from the payer. At this point, the payer can either accept or reject the request. If the payer agrees to the request, the status transitions to "accepted," and the payment process is initiated. However, if the payer finds any discrepancies or chooses not to proceed, they can reject the request, updating the status to "rejected." Additionally, payment requests often have a time frame within which the payer must respond. If the payer does not take any action within this period, the request status automatically changes to "expired." Furthermore, at any point before the payer's response, the payee has the option to withdraw the request, in which case the status would be updated to "cancelled."

Use cases

Beyond the conventional person-to-person payment request, which is the typical scenario that comes to mind, there exists an array of diverse use cases that RtP can efficiently address. These encompass scenarios such as business-to-consumer, where companies can request payments for services or products; and business-to-business, where it can streamline transactions between companies. Additionally, RtP can prove invaluable in a retail environment, whereby consumers can make in-store payments by simply scanning a QR code. It’s also worth mentioning that charitable organizations can harness the capabilities of RtP to facilitate donations, making the process accessible and instantaneous if the underlying rail allows for it. Furthermore, government bodies can employ RtP to collect taxes or fees, thus elevating the efficiency and convenience for both the government and the citizens.

Recurring and bill payments

Request to Pay (RtP) enables instant payments for bills like home loans or utilities. When a bill is generated, the payee sends a payment request to the payer, who gets a notification in their mobile or web banking. The payer can review the details and either authorize the payment or reject it if there's an issue. This offers more control compared to direct debits, which automatically deduct the billed amount, potentially overlooking any errors and making refunds cumbersome.

RtP at a Point of Sale (PoS)

RtP can facilitate seamless in-store payments at the Point of Sale (PoS) counter when a customer wraps up their shopping. The customer, acting as the payer, can employ their phone to scan a QR code, which initiates an RtP through the store's designated RtP service provider. Subsequently, the customer is alerted with an RtP notification, prompting them to access their RtP app to give the green light for an instantaneous transfer of funds into the store's account.

Global Implementations

Request to Pay boasts a bunch of implementations worldwide, each exhibiting distinct characteristics. Some of these implementations adhere to an open-loop model, wherein individuals associated with banks participating in the scheme have the capacity to initiate payment requests among themselves, irrespective of the banks they are associated with. Conversely, other implementations operate on a closed-loop model, which confines the ability to send payment requests to users within the same application. Notably, a majority of prominent neobanks, including the likes of Revolut, Bunq, N26, Chime, among others, have integrated this functionality, enabling their users to effortlessly request money from fellow users. Additionally, it's noteworthy that various Request to Pay (RtP) implementations have differing areas of focus. While some primarily concentrate on person-to-person (P2P) transactions, others encompass a broader scope, including merchant-to-customer transactions, as observed in UPI in India or BPAY in Australia. It's crucial to recognize that these implementations are dynamic and continue to evolve, with new functionalities being iteratively integrated. For instance, Bizum in Spain initially rolled out with a focus on P2P transactions, however, it is currently expanding its features to incorporate merchant transactions as well, highlighting the adaptability and progressive nature of RtP implementations.

Typically, closed-loop implementations tend to be streamlined versions of the comprehensive Request to Pay functionality, mainly due to the limited options available to the payer, who can merely accept or decline the request. In stark contrast, as illustrated in the graphic sourced from the UK's official Request to Pay website, the UK’s RtP implementation furnishes the recipients with an extensive gamut of choices. The recipient, upon receiving a request, can opt to pay in full, make a partial payment, defer the payment, or even open a dispute by initiating a conversation. Additionally, the classic options to accept or reject the request remain available. Furthermore, in certain implementations, the payer is given the option to prevent the payee from initiating any future requests, effectively instituting a block on incoming requests from the specific payee in question. This breadth of options in the UK’s model showcases a more versatile approach, catering to various user needs and scenarios, as opposed to the pared-down offerings typical in closed-loop systems.

Find below an end to end journey of a generic implementation of request to pay:

In various regions, Request to Pay (RtP) has been ingeniously integrated as a feature of real-time payment schemes, whereas in others, it has been architectured as an independent infrastructure. This distinction is crucial. For example, in the United Kingdom, RtP is designed as a standalone framework that can work in conjunction with the Faster Payments Service. This design allows for flexibility as it facilitates the initiation of payment requests across multiple Automated Clearing Houses (ACHs). On the other hand, in India, the UPI (Unified Payments Interface) has RtP embedded within its real-time payment infrastructure, making it an intrinsic component of the real-time payment ecosystem. These varied implementations reflect the adaptability of RtP and its potential to be tailored according to the specific payment landscape and requirements of different regions. Find below some known implementations and configurations of request to pay and their relative initiation infrastructures.

In the United States, The Clearing House (TCH) developed the RTP® Network, an equivalent of Europe’s RT1/TIPS, which supports Request for Payment (RFP) messages. This allows businesses and consumers to send real-time payment requests, providing an alternative to traditional invoicing methods.

The European Payments Council (EPC) introduced the SEPA Request to Pay (SRTP) scheme, which acts as a set of rules and technical elements for European payment service providers. It’s a pivotal step towards harmonizing Request to Pay services within the Single Euro Payments Area (SEPA), however, its

iDEAL in the Netherlands is a widely used online payment method, but it's not exactly the same as the "Request to Pay" model discussed earlier. However, it does share some similarities.

iDEAL allows customers to make online purchases using direct online transfers from their bank account. When a customer chooses to pay via iDEAL, the payment details are pre-filled, and the customer authorizes the payment through their own bank. The amount is directly debited from the customer's bank account and transferred to the merchant's bank account.

In "Request to Pay" model, the payee sends a payment request to the payer, who then has the option to accept and pay immediately, schedule the payment for a later date, negotiate by sending a counter-request, or decline the request entirely. The payer also has more flexibility in choosing payment methods.

In contrast, iDEAL is more of a direct and immediate bank transfer mechanism for online payments. It is often used in e-commerce for the checkout process.

So, while iDEAL incorporates elements of requesting and authorizing a payment, which is somewhat akin to "Request to Pay," it does not have the same level of flexibility and communication between payer and payee that a typical "Request to Pay" service offers. iDEAL is more comparable to a streamlined online bank transfer tool tailored for the e-commerce environment.

Delighters based on RtP

Some neobanks like Bunq and N26 have built delighter features, as per Kano’s model, on top of their internal request to pay implementation like the split the bill functionality. It’s a feature that enables individuals to effortlessly divide the cost of a shared expense among a group. Commonly used for restaurant bills, grocery shopping, shared subscriptions, or travel expenses, this feature streamlines the process of ensuring that everyone contributes their fair share. When utilizing this functionality, an individual initially pays the entire bill. Subsequently, through a payment app or banking service that offers the "Split the Bill" feature, they can enter the total amount and select the contacts with whom the expense is to be shared. The app then calculates each person's share and sends them a request to pay their portion. In the event that the individual is not a registered user of the neobank in question, the system dispatches an SMS invitation, encouraging them to sign up for the service. Upon approval from each participant, the payments are processed, and the amount is credited to the account of the person who paid the initial bill. This functionality eradicates the need for cash transactions and complex calculations, making the process of splitting expenses more efficient and hassle-free. These innovative features exemplify how neobanks are enhancing the user experience by building versatile and user-centric functionalities on top of their Request to Pay frameworks. N26 has developed a visibility control feature, catering to scenarios where users prefer to exercise discretion and opt not to receive Request to Pay notifications from other members. This functionality empowers users with greater control over their interaction preferences within the platform.

Final considerations

As we look into the future, it is clear that Request to Pay (RtP) infrastructures will play an increasingly pivotal role in the global payments landscape. The adoption of RtP is poised to continue to rise dramatically, offering substantial advantages in speed, efficiency, and user-friendliness. Technological advancements and the digitization of economies will also drive the continued expansion of RtP, facilitating faster and smoother transactions. Furthermore, the flexibility of RtP - catering to individuals, businesses, and even government entities - makes it a versatile solution that can adapt to diverse payment needs. In developing countries, where mobile penetration often outpaces traditional banking infrastructure, RtP could play a significant role in financial inclusion, enabling people to transact in a safe, cost-effective way

---