One court, four payers, a fee from each

Padel is almost always played by four people. Two against two, on one court. But a booking app usually has one payer. One person opens the app, picks a court, pays the full price and then spends the next few days asking three friends to send them their part.

That is the first problem. Paying for everyone is a small barrier, but it is real. The person who books carries the cost and the awkward follow-up. For the clubs, that means courts that are harder to fill.

The second problem was the company's. The app earned a fee when a booking was paid. One booking, one payer, one fee, whether one person or four people played. Four people used the app to find the court and the game, but the business only earned from one of them.

The CEO brought both problems to me as one feature: let the players split the cost, and let the platform take a small fee from each person who pays their share. It is not often that a user problem and a business problem have the same answer. This one did.

The club must not notice the change. A club sets one price for a court and an hour. If four people share it, the club should still receive that court price, on the same terms as a booking paid by one person. The split is between the players. It is not the club's problem.

Each player pays their part plus a fee. That sounds simple, but it changes every number on the checkout screen. The total the booker sees is no longer the court price. The amount each player pays is their share plus the split fee. Discounts and promo codes still have to apply. And the parts must always add up to the whole, even when the court price does not divide evenly into four.

A split booking has more states than a normal one. A normal booking is either paid or not. A split booking has a booker, a list of players, and a share for each of them. The confirmation screen has to show who is in the split and what each person owes. The booking details have to show it again later. And a player who was added by mistake needs a way out.

The money also has to be visible after the booking. Every month the company sends each club an invoice that lists the fees for that month. Once split payments existed, split fees had to appear on those invoices as well. I had built the invoice tool too, so this part was mine as well. A fee that the app charges but the invoice does not show would make the month impossible to check.

And the checkout screen was already crowded. It held the court selection, extra slots, member discounts, promo codes, payment methods and the payment itself. Adding a second way to pay, with its own list of players, into the same screen would have made it very hard to change safely.

It is easiest to follow one split booking from the start.

First, the booker picks a court and a time, as before. The court has one price. Nothing about choosing the court changed.

Second, the booker turns on split payment and chooses who is playing. They set the number of players and add them, searching for people they play with. Each added player appears as a player card, so it is clear who is in the split.

Third, the app works out the shares. The court price is divided between the players, and each share gets the split fee on top. The checkout shows the split, so the booker can see what the booking costs and who it is shared with.

Fourth, the booking is confirmed with the split attached. The confirmation screen shows the players and their shares. From the booking details, the players in the split can open a payment screen for their own part.

Fifth, the money is counted. The club's court price is handled as for any booking. The split fees are the platform's. At the end of the month, the split fees for each club appear as their own line on that club's invoice.

The most important design choice was where the fee lives. The easy way is to add one number to the booking: total fee, done. That works for the checkout screen. It does not work for anything after it.

Instead, I put the split fee on each booking item. A booking item carries its own split fee, and the checkout and the court list read it from there. So the app always knows how much fee belongs to each part of the booking, not just the total.

That pays off in three places. On the checkout screen, each player's amount is a clear sum: share plus fee. In the booking details, the split can be shown again without working it out a second time. And in billing, the fee can be added up per club and per month from data that already exists, instead of being guessed from the booking total.

The fee value itself came from configuration in the app, and the backend kept a matching value that the billing side reads. I added the backend part when I brought split fees into the invoice tool. Looking back, that is one value in two places, and I would now keep it in one place that both the app and billing read from.

A fee per payer is not only a way to earn more. It also follows the real work. When one player pays for a court, there is one card payment. When four players split it, there are four payments. Each one has its own processing cost, its own receipt, and its own chance to fail and need support.

So a split booking creates more payment work than a normal one. A small fee on each share ties that cost to the people who chose to split, instead of hiding it in the court price. The players get something in return: nobody has to carry the whole cost, and nobody has to chase anyone for money.

This also made the feature easy to explain. The booker sees the court price, the players and a small fee on each share. There is no hidden change to the price the club set, and no one in the group pays more than their own part plus the fee.

Most court prices divide neatly into four. Some do not. A price with an odd number of öre, or a split between three players, leaves a remainder that cannot be shared equally.

The rule has to be decided, not left to chance. If each share is rounded on its own, the shares can add up to a little more or a little less than the court price, and the club is paid the wrong amount. The safe way is to divide in whole units, give the leftover unit to a chosen payer, and check that the shares add up to the price exactly. The sketch further down shows that rule.

Before I could add split payment, I had to make room for it. The checkout screen held both the layout and the booking logic: which court, which slots, what price, which discount, which payment method. Adding a list of players, shares and fees into that same file would have made every later change risky.

So the first split payment commit also moved the booking logic into its own hooks, separate from the checkout screen. The screen shows things and reacts to taps. The hooks hold the booking data, the price and the split. A change to how shares are worked out no longer means editing a large screen component, and other screens can use the same logic.

This kind of work is invisible to players. Nobody opens an app and thinks the hooks are nicely separated. But it made the next changes easier: the split fee on booking items, the changes to the confirmation logic, and the screen for the players in a split.

A split is a small group, and the app has to treat it like one. The booker searches for players and adds them to the split. Each one shows up on the checkout as a player card. The booker can see at a glance who is in the game and who is paying what.

After the booking, the split stays visible. The booking details show the players in the split, and I added a separate screen for the players in a split, linked from the booking details, where they handle their own part.

People also change their plans. Someone is added by mistake, or cannot play after all. A teammate later added a way for a player to remove themselves from a split, and about half of that change was my code. It is a small feature, but without it, a split booking could hold a person who never meant to be in it.

I want to be exact about my part, because the git history is not. I wrote the split payment work in the app: the booking hooks, the player selection, the split fee on booking items, the confirmation logic and the screen for the players in a split. It reached the main app through a teammate's pull request. Most of the lines in that merge were mine, and the commit credits me as co-author.

The same is true of split payments for KNET, the local payment method for clubs in Kuwait. That change was also merged from a teammate's branch, and most of its lines were mine. On the billing side, I added split fees to the invoice tool and the backend value it reads. The rest of the backend for bookings and payments belonged to the wider team.

The first lesson was that the best features solve two problems at once. Split payment made the app better for players and better for the business at the same time. When I hear a feature request now, I ask who else it helps, and whether there is a second problem hiding behind the first.

The second lesson was that money features travel. Split payment started as a checkout screen. A few weeks later it had reached the booking details, the confirmation screen, a payment screen for the other players, the KNET flow and the club invoices. If I had stored the fee as one total on the booking, every one of those places would have had to work it out again. Putting the fee on each item, once, saved that work everywhere after.

The third lesson was to make room before adding. Moving the booking logic out of the checkout screen was not part of the request. But without it, split payment would have made the checkout screen much harder to change, and every later fix would have cost more.

I built split payments again later, on a court booking platform in Australia, this time with the payment held first and captured when the game happens. The ideas from this first version carried over: the fee is tied to each payer, the group is visible to everyone in it, and the shares must always add up.

Shared costs are everywhere. Friends split a holiday house. A team shares the cost of a pitch. A group shares a table deposit at a restaurant, or a private class with a coach. In each case, one person usually pays and then chases the others.

The same design works for all of them. Keep the provider's price whole. Divide it into shares that always add up. Put any fee on each share, so each payer sees exactly what they pay and the business can count it later. Show the group clearly, and give people a way to leave it. And make sure the fee reaches the statement or invoice, not only the checkout.