Case StudyTechnology

Payments as a Platform – The Scottish Government Payments Service

An exemplar case study for GaaP in Scotland (Government as a Platform) is the Scottish Government Payment Service.

An exemplar case study for GaaP in Scotland (Government as a Platform) is the Scottish Government Payment Service.

As they write on their blog the Scottish Government began pioneering a platform model in 2019 for a single Payments system, an approach intended to yield the benefits described by the digital economy strategy:

“That means building something centrally that is easy for service teams to plug in to and re-use, without additional procurement. That saves them time, money and hassle.

Building a single platform also means we can establish standards that will work across government. That will cut down on bureaucracy and needless repetition of work.

Finally, a platform will make things better for public servants and for citizens. It will be quicker for us to set up new services, or retire old ones. When new payment technologies emerge, we’ll be able to securely add them to the platform once, for the benefit of everyone.”

A similar system has already been developed at the UK Government level, Gov.UK Pay, as part of their GaaP strategy. Asked on their blog why they don’t simply reuse this capability, the SG Payments team explain that:

“the programme is designed to consider the opportunity to develop a platform that could support both outbound and inbound payments. At present, the GOV.UK Pay platform only carries out inbound payments.”

Moving from Alpha to Beta

They have conducted early prototyping work, awarding a first stage to vendors including Scott Logic, with the code shared openly via Github.

In their supplier briefing video, they outlined the plans for the beta stage of work.

The headline goal is to improve the way the public sector process payments to and from citizens and other organizations, encompassing pensions, benefits, grants, taxes and licences, services likely to experience large scale growth. In 2018 volume as around 5 million transactions per year, with usage estimated to expand to 25 million by 2022/3 as the Scottish Government takes on increasing levels of devolved functions.

Beginning at 4:00 the team is introduced, led by Trish Quinn, and they explain their planning process including their service design and the other organizations they learned from to form the strategy. Key Scottish Government agencies they have collaborated with include Social Security Scotland, the Independent Living Fund and the Scottish Public Pension Agency.

Platform Architecture

From 8:50 they provide a detailed review of their planned technology architecture for implementing the service.

Their initial requirements are to cater for outbound payments, utilizing Gov.UK Pay for incoming in the short term but potentially taking this on too longer term.

Central to the GaaP model the core requirement is to provide a standard API for calling all the systems services. There will be a human interface to enable users to query payment status and to authorize or cancel payments, but ultimately they hope customers will utilize the APIs to integrate it with their own financial systems to automate the transactions.

The Payment Platform will act as a broker, abstracting the payment process across and aggregating the services of multiple PSPs (Payment Service Providers), providing a common interface to services such as BACS and Faster Payments, feeding the resulting transaction details into common public sector accounting systems. As new payment methods become available the architecture should make it simple to plug them in.

It will also cater for intelligence of payment processes, for example facilitating alternative methods for those without bank accounts, choosing the best routes for sending payments depending on the requirements of their partner and tracking and handling failed payments.

The platform will be built via a ‘Cloud Native’ approach of hyper-scale Cloud hosting (AWS has been used thus far), a Java-based back-end implemented on Kubernetes containers and a microservices software architecture.

Buy vs Build

From 17:30 they describe the procurement process, they are looking for a single development service contract, and the timeline for the purchase.

What is telling about the project is the single focus on coding the system from the ground up. Given their primary requirements of a payments engine that integrates with multiple systems and service providers, it is very likely this is a scenario already addressed by the Open Banking industry, a sector built entirely upon those requirements with a plethora of long-established vendor solutions already developed.

Tags
Show More

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button
Close
Close