Why Request to Pay is as easy as plug and play
Have you read the excellent blog piece by James Stanley at Anglian Water highlighting the customer benefits of Request to Pay? Or maybe you’ve heard Sian Williams from Toynbee Hall discuss why Request to Pay is a step change in consumer empowerment? Peter Cornforth from Answer Pay comments.
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 ecosystem through which a payment request can be initiated and managed. Under the hood the complex underlying interconnectivity between the PSPs enabling a community of billers from one PSP to send requests for payments to the payer community of another PSP is the real revolutionary aspect. This transforms existing bill pay 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, they have to in order 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 a time and capacity saving, 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 Request to Pay, 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.