We have implemented Apple Pay and Google Pay into GOV.UK Pay using the Payment Request API standard. We’ve named this functionality ‘digital wallet’, and it will appear under this name to GOV.UK Pay service teams.
A digital wallet makes payments more secure, which helps our users and reduces fraud for government. Here, we explain the different approaches we took to integrate the 2 payment providers into GOV.UK Pay.
Security benefits of the digital wallet
Payment Request API is a means of paying online through securely stored card data, rather than filling out forms. It’s an already integrated way of passing a user’s preferred payment to a merchant. The API was first released in 2017 and major browsers like Google Chrome and Apple’s Safari, started to support it in early 2018.
We decided to rename Payment Request API to ‘digital wallet’. This makes the name more meaningful to our service teams and encompasses the different payment providers.
Payments are more secure through a digital wallet as your card number and card verification code (CVC) are never exposed to GOV.UK Pay. The card data is encrypted and then sent to us.
For Apple Pay, the card information is only released by authorisation made using biometric information and stored within a secure and separate processor, called a secure enclave, on the device itself. This is possible with Google Pay, but it’s not a hard requirement.
The encryption creates an implicit 3-D Secure authentication. This helps government, as we can be confident the data is secure, leading to reduced risk of fraud.
Knowing which browser
Our analytics show that:
- nearly 50% of our users browse using Google Chrome
- just over 32% use Apple's Safari
Implementing the change
Both Apple and Google support payments using the Payment Request API open standard but also both have built a proprietary API with added features.
However, with Google Pay, we stayed with the Payment Request API. This was because the Google Pay API required us to include an additional Google script within our page that pulled in other tracking scripts. We did not want these as they would affect page performance.
Decrypting payment data
The payment data we receive from Apple Pay and Google Pay uses secure cryptography to protect payment information. Apple and Google can do this because they have a public key infrastructure (PKI) with the payment service provider – currently Worldpay.
However, Google Pay and Apple Pay need to identify a merchant, and GOV.UK Pay is not a merchant, it’s a tool to take and process payments from government services. To Google and Apple, the government services would be the merchants.
So, we needed to decide how we would identify the merchants to Apple and Google Pay, as well as Worldpay.
For merchants – or government services in this case – using Apple Pay, the identification process would involve setting up an Apple Pay Developer Account and managing a merchant identifier, payment processing certificate and merchant identity certificate. This would add an operational burden to our users as they would have to manage this information.
Therefore, we decided we would decrypt Apple Payment data. GOV.UK Pay will have a set of certificates to manage and allows us to effectively be the merchant. Decrypting the payment data means we can see the expiry date and cardholder name, but never card numbers or CVC.
The identification process for Google Pay was simpler. Our users who use Worldpay already have a contract with Worldpay, and enabling Google Pay is simply a matter of generating a unique code through their Merchant Admin Interface.
They then upload their unique code to us via our self-service platform. We can then fully leverage the PKI between Google Pay and Worldpay without having to do any decryption and managing certificates ourselves.
Testing the digital wallet
We decided to write the tests using Cypress as we already used this throughout our applications. We wrote stubs to replicate the availability of the Payment Request API and Apple Pay JS, and add hooks so that they would respond with the expected payload after a user authenticates the payment. On GitHub, you can view our tests and our stubs.
The functionality is now available to the 4 central government services following a successful pilot.