Scottish Government Processes First Payments Service Transactions

As they write on their blog the Scottish Government has made the first transactions through their new Payments Service.

They successfully processed the first payroll run for Independent Living Fund Scotland, a discretionary fund providing financial awards to over 5,000 disabled people in Scotland and Northern Ireland.

This was a test run of a single payment while the service is still in beta to give their partner a chance to input into the design of the Payments Service, and for them to iterate and make improvements.

In previous blogs they describe the history and background of developing the service. As they describe here 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.