Why Request to Pay is as easy as plug and play
From telegram to internet
Underpinning all of these customer experiences are the payment service providers (PSPs)—the unsung heroes who provide the interfaces and connectivity into the Request to Pay (RtP) ecosystem through which a payment request can be initiated and managed.
The real revolutionary aspect of RtP is the complex underlying interconnectivity between the payment service providers, which enables billers from one PSP to send payment requests to the payer community of another PSP. This transforms existing bill-paying experiences such as paper invoices or pay by link services into networked two-way dialogues. It’s the equivalent of moving from a telegram to the internet.
The challenge for a PSP is how to keep up with demand, and up to speed with Request to Pay when core product roadmaps are perhaps more challenging than ever. The good news is that for those PSPs that want to manage the user experience without the threat of disintermediation from large payment schemes you can outsource the complexity to Pay.UK accredited technical solution providers.
Technical solution providers build and certify their services with Pay.UK. This includes key functionality such as ecosystem connectivity and message routing. Designed to enable rather than replace, services will be fully branded by a PSP allowing them to control KYC, request initiation and management. This means for example that a biller using an API or portal from their PSP for cash collection today can be empowered to use Request to Pay through that same interface tomorrow reducing any potential friction.
PSPs have fantastic technical teams that allow them to run 24/7 payment services. So often if they are given the bandwidth they will be able to build connectivity to the Request to Pay ecosystem. In this context, a technical solution provider would offer time and capacity savings, but this is not where the biggest benefit is seen. It is operationally where these services excel. As demand continues to increase and more and more participants join there is a risk that managing the connectivity and testing of new entrants could quickly become overwhelming for an internal technology team.
With a technical solution provider every time a new party joins the ecosystem they are onboarded and made available to all the PSP customers of that solution provider. This is hugely important as the more participants the more opportunity for interaction. Technical solution providers can do this more efficiently than internal teams as this is the core focus of the technical solution provider and it is performed for multiple customers so there are economies of scale.
Pay.UK has developed a great standard but at the moment it is focused on the UK and there are other standards emerging in other countries and regions. Of particular interest will be the new European standard given many of PSPs operate in a multi-region environment. The good news here is that the UK standard has been constructed with ISO20022 in mind, the same standard that the European Payments Council have used for SEPA RtP, making it easier to communicate between the two.
Request to Pay is very much a global phenomenon and as it takes off, the variety of connectivity options are making it easier than ever to be a part of the story. PSPs can leverage technical solution providers to get the ownership and control of a build it yourself model but the ease and speed to market of a partnership model.