How to build an in-house split payment feature in 3 weeks

Throughout our journey at Study Abroad Apartments of helping international students find safe and reliable housing we have always believed in the central focal point of making every step of the process easier. We found that many students were booking their accommodation in groups, and we often found ourselves trying to answer questions about payment that we had no business answering such as:

If my daughter has the smaller room, how much should the other students pay?

When dealing with group purchasing decisions on a user facing application, you have to consider ways in which the collective will most efficiently agree with one another without driving your customer service team insane. We have always known that at some point in our product roadmap we would build a split payment feature enabling our users to pay individual shares for their accommodation.

Here is how we did it in three weeks:

Week one

Our first week was filled with brainstorming and lots of research. We looked at 20 companies that we believe had a creative approach to tackling split-payment. To name a few:

Uber, Airbnb, Homeaway, Splitwise, Venmo / Paypal, Paybygroup, Antlos (boat sharing), billr.

Our first objective was to find a way that covers any and all scenarios with minimal edge cases. We narrowed down three ways to effectively split payment that puts control into the hands of various stakeholders. First, was the idea of SAA allocating amounts based on the number of users in a group. For example, if there were four students in an apartment we would create four shares by dividing the total sum evenly. Each user would be responsible for an equal share of payment. The second option was to put decision making in the hands of a single lead user. The lead user would allocate payment responsibilities to the other tenants and be responsible for deciding to split or pay the whole amount. The third option was to take the decision making process completely out of from SAA (or the lead user) and instead into the hands of the collective group.

Below are a few of the mock up designs we sketched based on ideas two and three.

Option 2
Option 3: Step 1

Week two

Each option had its own obstacles but ultimately we felt the best course would be to move toward collective decision making. Option three (shown below) depicts exactly how our users can be in charge of their own purchase. In this scenario we are keeping individual amounts in the hands of the group. We brought these ideas to the rest of our team to help make the decision. If we had more time we probably would have sent out user surveys asking former customers exactly what they would want in a split payment feature. The idea is that a user can insert however much he/she wants to pay and invite anyone. The decision on how much to pay would be made elsewhere (off platform) and it would not be bound by any individual stakeholder.

Much of week two was spent crafting user stories, establishing assignments, and perfecting the mock ups. In these 7 days we had crucial decisions to make that we knew would not affect us now, but could potentially become a problem down the road. In particular was the decision on how we would enable users to share while keeping our system safe from intruders. One feature we decided to keep was the ability for users to copy a link and send it to friends. We looked to our data to help us decide the importance of this feature. Students have a tendency to be slow when it comes to email so we incorporated a random token generation for each booking ID to share anywhere they desire.

Option 3: Step 2

Week three

During week three as we got closer to staging deployment we began the process of mapping the most important part — communication. Our existing communication did not reflect the new process which meant reviewing all email and SMS notifications. We dumped all of the current emails into a flow chart and started to insert points at which new communication would to be added. We were now able to communicate to all decision makers which meant the opportunity to increase efficiency of the customer support team. We decided on emails that were brief with large singular calls to action. When working with group purchasing decisions it is best to aim for a minimalist approach to content. As my old soccer coach used to say K.I.S.S (keep it simple stupid).

Once emails and code were deployed to staging we spent the later half of the week testing and fixing minor hiccups. When we felt we were in good shape we held a team meeting to walk everyone through the new process. The admin stakeholders shared feedback which helped to put in some of the final touches. When it was time to deploy we put together the user stories that we felt could wait until post release. This was tough but as soon as a new feature is ready it is always crucial to get it into the hands of real users. I cant stress this point enough. It is very easy to delay the deployment of a big feature and it can lead to unnecessary components via decisions that are not made based on user feedback.

And there ya have it. Three weeks and you can map, stage, build, test, and deploy. I did leave out a good amount of detail related to payment flow which I would be happy to discuss in a bit more detail.

Feel free to reach out for questions :)