We previously introduced GOV.UK Pay, a new Government as a Platform product, to make payments more convenient and efficient. We’ve spent 6 months building our beta, and very soon we’ll be taking our first real payments with our first partner services. We wanted to give you an update on our public API, how we're making integration straightforward, security and our technical choices.
As a greenfield project, we’ve had the freedom to make good technical choices that address user needs. For example, rather than payment pages that look and work differently depending on the payment processor, we’ve built a consistent and reliable user experience hosted securely on GOV.UK. We’ve used our service design patterns to do this.
User research showed us how frustrating payment pages can be. Users get confusing messages when they press the back button, refresh, stop or hit submit twice. We’ve been working hard to improve this.
Making integration easy
To meet the needs of developers in service teams across government, we’ve built a series of straightforward RESTful APIs. This means that our beta partners can easily integrate with GOV.UK Pay and use any payment processor we support. We tested the APIs thoroughly at our hack day and have continued to improve them since.
We use development practices such as continuous integration and zero downtime deployment. This means we can push out updates and bug fixes without interrupting services that are using (or testing) GOV.UK Pay.
Our minimum valuable product
During our alpha phase, we learned a great deal about how to integrate with a variety of payment processors including card payment gateways, direct debit bureaus, e-Wallets, and others.
It’s always tempting to try and include everything in the first release, but we realised doing so would take years rather than months. To avoid this ‘second system effect’ we’ve been following lean software practices. We release early, get user feedback and make sure what we develop is genuinely fit for purpose.
Our alpha build was experimental. Following on from feedback from partner services and user research, we’re now building a small, production-quality beta that supports card payments.
We’ve taken great care to understand the lifecycle of a payment, and to make sure each step is recorded as a transaction. If a user loses their place, we can use this information to show a reassuring message and let them continue, or safely back out and cancel.
Technology choices for our beta
Feedback led us to make some changes to our technology stack as we moved to beta. We’ve changed from:
- Java 8 + Play Framework to Node.js + Express for frontend webapps
- MongoDB to to PostgreSQL for data storage
- Travis CI to Jenkins for continuous integration
For backend REST services we’re staying with Java 8 + Dropwizard.
We’re taking a modular approach by building microservices using 12-factor principles in Docker containers. Terraform is used to set up environments in the public cloud whenever we need to, eg for new features or performance tests.
Our public API and documentation
We’ll be coding in the open during the beta and hope our work will be useful to other people. For our hack day, we released a sample app that integrates with GOV.UK. And more recently, we opened our public API, the first of many modules that we'll open in the coming months.
Public API is where partner services will interface with GOV.UK Pay. Developers in service teams will need to understand how it works. So we’re using Swagger to automatically generate documentation and create an API explorer. Feedback so far has been positive.
Focus on security
Any software handling debit or credit card numbers has to comply with Payment Card Industry Data Security Standard (PCI DSS). This standard is quite long and intimidating, but at a basic level it tells us we must use:
- strong encryption
- firewalls
- file integrity monitoring
- anti-virus and intrusion detection to prevent attackers getting into our systems
It also says we should write policies on how we:
- keep our systems up-to-date and free of security vulnerabilities
- handle log files
- decide who has access to production infrastructure
PCI-DSS also requires our data centres to be physically secure. Fortunately many of the public cloud providers already meet this part of the standard. So building GOV.UK Pay to run on the public cloud saves time and effort.
Experts we contacted through the Digital Marketplace have run regular penetration tests and vulnerability scans on our environments. We’re taking advice from CESG, who've published a useful guide on Cloud Security for government services.
The right team
The most important part of building GOV.UK Pay sustainably and securely, is to start with the right people. As an integrated, multidisciplinary team, we bring collective experience from other government services both inside and outside of GDS, major card payment schemes, online retailers, and elsewhere.
It’s an exciting time to be on the GOV.UK Pay team and we’ll be blogging again once we’re ready for users - we’ll want your feedback.
And if you’d like to join us, we’re recruiting. We’re always on the lookout for talented people to join the team so take a look at our videos describing how we work, our vacancies page, or drop us a line.
If you work in central government and are interested in using GOV.UK Pay in your service, let us know.
Follow Ian on Twitter and don't forget to sign up for email alerts.