When it comes to new ways to pay, consumers are making their preferences known. Overwhelmingly, today’s customers want fast, easy, and secure transactions and are increasingly willing to try new and emerging payments forms.
When you think about emerging payment forms such as Request to Pay, and the impact they might have on your organisation, what comes to mind? A complex, costly, and time-consuming undertaking?
It doesn’t have to be that way. Simply put, Request to Pay is a new, more flexible way for payments to be made between people, organisations, and businesses. It allows payments to be initiated, approved, monitored, and actioned via a secure messaging system. And it has the ability to influence both your technology strategy and roadmap.
Let’s take a look at some of the important considerations to keep in mind when evaluating Request to Pay technologies.
Request to Pay-type proposals
In the past few years, both Fintechs and Neobanks have introduced new Request to Pay-type propositions to the market. These propositions, though commercially different, do share similarities with Request to Pay, such as the ability to create a payment link which must then be sent from the payee to the payer. Some of the propositions also allow the payment reference and/or amount of the request to be changed and some even support multi-currency.
Although these solutions do share some similar functionality with Request to Pay, they differ in that they can be deemed potentially less secure since the payment request itself isn’t necessarily delivered over a secure channel. Furthermore, when the request is paid, users also need to make sure that the reference and amount haven’t been modified. This can mean additional work for payment reconciliation teams.
Adherence to different standards
Beyond security, Request to Pay propositions also face challenges when it comes to issues surrounding availability, interoperability, on/off boarding processes, performance, reachability, security, and standardisation.
For example, within the European Economic Area, two sets of standards exist, with Pay.UK governing the UK market and European Payments Council publishing standards for the rest of Europe. These standards differ dramatically with regards to API standards, message flows, and the types of payments supported. This makes it extremely difficult for banks to support both.
Pay.UK
Pay.UK is the UK payments governing body that is responsible for setting out the direction of all payments and payments overlay services frameworks, that anyone who wishes to operate in that space must comply with.
The Pay.UK Request to Pay framework is made up of three layers, representing the front end, the back end, and the guidelines within which the Request to Pay proposition must operate:
- Applications
- Repositories
- Framework
The framework has been created as a proprietary API overlay service to the UK’s existing payments infrastructure. This enforces complete separation of the secure Request to Pay payment request messages with the payment itself, enabling you to continue to use your existing payment rails to facilitate Request to Pay payments.
SEPA RTP (SRTP)
European Payments Council noted the requirement for a Request to Pay proposition within Europe and have created a scheme to meet demand. SEPA Request to Pay uses the Request for Payment (pain.013) and Response to Request for Payment (pain.014) ISO 20022 messages to facilitate Request to Pay. The rulebook suggests a generic four-corner model (one payee, one payer and two service providers), though they do note that three-corner models and payee or payer direct models are viable alternatives.
There isn’t a standardised Payer Identifier for the requests which leaves room for divergence and all payments made via SRTP must be made in Euros using SEPA Credit Transfer or SEPA Instant.
General principles
Message and payment security within any Request to Pay model are critical for success. Customers will be more confident when accepting or initiating a payment request if they feel like they are doing so in a secure manner, or if they can log in to an existing mobile application or website with multi-factor authentication and see a record of outstanding requests and payments already made.
To promote confidence in the security of a Request to Pay solution, organisations should have solid underlying data definitions and data structures (ideally in ISO 20022 format) to provide reconciliation, data analytics and management information for all relevant stakeholders.
The value of an open-source modular platform for Request to Pay
To accelerate adoption and drive value, organisations should consider deploying an open-source technology platform to enable a Request to Pay solution. This makes the transition to Request to Pay both cost-effective and straightforward.
The right modular payments platform, for example, relies on open-source technology to provide orchestration support for Request to Pay out of the box. It allows for quick integration with existing payment rails by generating Faster Payment (ISO 8583) or similar messages for existing payment engines or provide a low-cost per payment solution for Euro SEPA Credit Transfer / SEPA Instant payments. A low-code, cloud-native, open-source technology platform can help organisations accelerate payments transformation, address both critical non-functional and functional requirements, and deliver more value and unlock new revenues – all while lowering costs and risk.
Icon recently conducted a survey of global retail and corporate banks, which revealed that standardising message content and exchange are seen as key challenges limiting adoption of Request to Pay, alongside bank readiness which was overwhelmingly viewed as the main barrier to adoption. With banks already at the limits of their technological and strategic capacity, trusted third parties promise to play an important role in helping banks to adopt Request to Pay while embracing regulatory changes, enabling innovation, and driving new revenues.
