How we built Settle Up

Chasing money, misplacing account details, chasing again; it’s fair to say that paying back friends and family can be a bit of a minefield. We built our new feature Settle Up to make it a little more straightforward – and a whole lot quicker. No need for sort code swapping, or awkward chasing messages, no double checking details – with just a few taps, a single link, and you’re all settled up.

In pushing ourselves to create the best current account possible, we’re constantly opening up our engineering team to a range of challenges which the finance industry hasn’t faced before – particularly with respect to how we build truly seamless experiences with money. To do that, we’ve left outdated team structures in the past and allowed our engineers to manage projects – from planning and prototyping, right through to execution.

That’s no different with Stephan’s latest project – to lead the website for our new feature, Settle Up. In this blog post, he explains how he approached the project, some of the challenges along the way, and what’s next for Settle Up. Stephan was the 33rd employee at Starling, and works in both Javascript on our web applications, like Settle Up and the developer portal, as well as Java on the banking platform.

So why does Settle Up need a website?

The website exists so that you can request money from any of your friends, regardless of whether they have a Starling account or not by sending them a personal Settle Up link. If they have an account with us, the link you share with them will open in the Starling app and allow them to pay you back in just three taps. If they are not a Starling customer (yet) or aren’t on their mobile, the link will open our Settle Up website in the browser. So wherever they are, your friends can pay you back seamlessly on any platform or device – whether they’re a Starling customer or not.

How did you approach it?

I had plenty of autonomy over the building of the Settle Up website, whilst working alongside Product and Compliance. While there were certain key requirements requested by our Product Managers, and designs from our Web Designer, it was my responsibility to review and select technologies that fulfilled these requirements, in particular the responsive and user experience design.

At the outset of the project I considered a number of technologies for the website, before choosing to use React, the popular JavaScript framework. The most important thing was that – whatever framework I chose – it had to fit into our existing infrastructure and the engineers had to be comfortable using it. I’m sure I could write an entirely separate and completely boring post on how I ended up using the stack that I did and the pitfalls along the way, but I’ll save you from that.

For those interested, the Settle Up website is a single page app (SPA) written in the JavaScript framework React. I used Flow for static type checking and due to the small size of the application I chose to use the internal React tools for state management.

Once you’d settled on the tech needed, how did you go about building the Settle Up website?

I initially joined the project back in mid-December 2017 and spent the first two weeks of engineering time exploring the various methods, and weighing up how I would approach the build. I find the best way to do this is to jump right in and build some prototypes. I then have something to play with, giving me a clearer view of the objectives and how they might be achieved.

The initial implementation used a technique called server-side rendering, where the final page content is delivered directly to the browser. The alternative is client-side rendering, where the browser receives all the pieces but has to do some assembly before they can be displayed.

For our use-case, server-side rendering didn’t give the best user experience. The main issue with the technique is that every user interaction, like clicking a button, required a round trip to the server to get new content, resulting in a full-page reload. This meant that every interaction left you waiting for far too long and was not a good user experience.

However, with the client-rendered prototype, everything that is needed to use and navigate the site is delivered as you land on the first page. This approach gave near-instant UI interactions at the cost of slightly longer initial load times. This was also important as we know many people would be visiting the page on mobile devices and using a mobile device – so it had to be quick and responsively designed.

Once we had agreed to use client-side rendering, I selected the React framework which is also used in the Developer Portal, which gives external developers the tools to develop with our public API. We also use React in our management console, which is used internally by customer service and operations, making the framework familiar to the rest of the front end developers on the team.

I got started using the create-react-app GitHub repository which lets you get stuck in to building your app within minutes, without having to worry about any configuration. In total the development process of the Settle Up website took roughly 2 months. For those who joined us for our community event before Christmas, you will have seen the bare bones of the site being demo’d. The core functionality was in place by the end of the year and in January the user experience and content (and the name!) was finessed.

Given its sociable friend-to-friend functionality, we decided that a warm, conversational and colloquial name felt right for the feature, rather than something purely utilitarian. We wanted it to feel like something people might say to each other in real life – and the result was Settle Up.

What did you do to make sure it’s completely secure?

Our main banking experience exists through our iOS and Android mobile apps. When you’re logged into one of our apps any requests from your app is authenticated so we know it’s you. Read about the security in our app.

For further reading take a look at the blog post by our Director of Technology Steve Newson on the approaches we employ on both platforms to ensure that Settle Up and all of our systems are secure.

You can easily confirm the legitimacy of a site by looking out for the padlock and company name in the address bar of their browser. This is often set in green font and indicates that the site and domain have been validated as being owned and operated by the named company and that the contents were sent securely over the internet.

The site also uses a payments technology called 3D Secure, which provides an additional authentication factor when using your card online. You will probably have seen it before and may know it as Verified by Visa or MasterCard SecureCode depending on your card issuer. On submission of the payment using a card that supports 3D Secure, the site will redirect you to a page provided by your bank as an intermediary step before your payment can go through. This makes fraud more difficult as possession of the physical card or card details is not enough to make payments.

What’s next?

When we launch a feature, it’s never the end, we always have plenty of ideas on how we’d like to iterate and improve on it and we also take great inspiration from our customers on the Starling Community. Settle Up is no different. Since launching in February, I’ve been working on adding Apple Pay and Google Pay to the website alongside existing card payments to give customers even more choice and convenience when they’re paying somebody back. This should make paying people back even easier for non-Starling customers, and I hope to release this feature in the very near future – so keep an eye out!

Are you a Starling Customer and not yet used Settle Up? Find out more by reading our original blog post ‘Introducing Settle Up’ and activate your link in app today to start settling up with friends.