Split Pool

SplitPool logo !

Inspiration

Dinner with friends is fun until the bill arrives. Suddenly, someone becomes the accountant, another person opens a calculator, and everyone's asking: "do you have Venmo/Zelle/Cashapp?" Eventually, one person fronts the entire check and everyone promises to pay them back. But in the end, there's always that one person who forgets to pay their share-- and is it bad to ask them for the third time?

We wanted settling the bill to feel as easy as sharing the meal. That's why we developed SplitPool, a group-payment platform that helps you manage everything from the receipt to the card you pay with. The current market only has apps where you can split bills and other apps where you can pay each other, but no app that seamlessly integrates the process from getting a receipt to tapping a card.

We also wanted the experience to capture something worth remembering about the dinner. After checkout, generative AI gives each diner a playful title based on their claimed items. The friend who ordered the giant sundae might become “Sundae Enthusiast,” a title they keep until their next settled meal. With SplitPool, the receipt becomes a shared memory, and the group gets a little reason to come back together.

What it does

SplitPool makes sure everyone approves their share and authorizes their payment before the restaurant bill is paid. All those promises of “I’ll pay you back” are handled upfront, so nobody has to put the entire table’s dinner on their credit card and hope for the best.

It starts with a photo of the receipt. Gemini turns it into an editable list of items and prices, and friends join the same bill to claim what they ordered. Shared the fries? Split them between the people who ate them. Ordered a giant ice cream sundae? That one’s yours. The app calculates tax and tip, showing everyone exactly what they owe.

As people claim items, live updates keep the group in sync. Once everything is accounted for, the host locks the bill, and each person approves their exact total and authorizes payment on their own card.

Checkout stays closed until everyone’s authorization succeeds and funding is ready. The designated spender can then create a virtual card for that bill, with a limited budget and a one-hour spending window. Everyone handles their own share, and the table settles one bill together.

After payment is complete, generative AI turns everyone’s claimed items into a playful meal recap, giving each person a personalized title! The veggie lover might earn “Leafy Greens Legend,” while the friend with the giant sundae takes home “Dessert Devotee.” Everyone leaves with their share settled and a little recognition for their contribution to the dinner lore.

How we built it

We organized SplitPool around four components: receipt processing, collaborative bill splitting, individual payments, and virtual card management.

Our receipt-processing design uses Gemini API to convert a receipt photo into structured items, and prices. The extracted bill is presented for review before anyone starts claiming items.

Our collaborative bill-splitting design uses a Fastify API and PostgreSQL to hold one shared bill. After the host reviews the receipt, friends join through an invite and claim items as fractions of each line: all of one dish, or half of something shared. The backend recalculates tax, tip, and each person’s total in integer cents from those claims, and the app refreshes the bill every few seconds while people are still claiming.

Each edit sends the bill’s current version. If two people claim at the same time, one request succeeds and the other is told to refetch, which stops overlapping shares and disappearing items. Unclaimed amounts stay unclaimed, and the host can lock the bill only after every item is fully accounted for and the printed total matches.

We built the payment flow around an approved, frozen version of the bill. We then designed the payment flow around an approved, frozen version of the bill. First, each participant confirms their selections and their subtotal amount before collection begins. Then Stripe Payments authorizes each participant’s amount on their selected payment method. Once all required authorizations succeed and the funding is ready, Stripe Issuing creates the card for the designated spender. Repeated checkout requests reuse the same operation to avoid creating duplicate cards.

The card has a fixed one-hour spending window. Our backend checks purchase requests against the approved budget, merchant, and deadline, blocking a second independent purchase or spending outside the permitted session. If the final charge was below the budget for whatever reason and there is leftover funds in the card, it is refunded proportionally to each participants. Charges above the budget open a review case, and the payment does not go through.

After checkout, we use Gemini again to turn each person’s claimed dishes into a short food title. The request sends only opaque diner labels and the items they ate, not names, group details, or payment data. Gemini returns playful two-to-four-word titles, which we check so they stay kind and unique across the table. If the model is unavailable or a title fails that check, the backend falls back to a keyword title from the same dishes, and the host can skip titles entirely from the approval screen.

Challenges we ran into

One of our biggest challenges was understanding the payment system we were trying to build on. As computer science students, we had little experience with what actually happens between a customer tapping their card and a business receiving the money. An idea that sounded straightforward, collecting everyone’s share and funding one virtual card, raised questions we hadn’t anticipated. Who holds the money? When does it become available to spend? Which parts of the process can our app actually control? We spent a lot of time researching payment platforms and figuring out which could support our intended flow.

Security was another unfamiliar but unavoidable challenge. When designing something that handles people’s money and personal information. We had to consider who could access the group card, how to ensure people were charged only what they approved, and how to prevent duplicate payments when someone tapped twice or retried a slow request.

Multiple users interacting with the same bill added another layer of complexity. Two friends might claim the same item simultaneously, or someone might change their share while another person was approving payment. We had to think carefully about keeping everyone’s view consistent and deciding when the bill should become locked. Failed contributions, delayed confirmations, and refunds also pushed us to plan beyond the happy path and consider how the system should recover when something goes wrong.

Accomplishments that we're proud of

We’re proud of bringing every stage of splitting a restaurant bill into one cohesive experience. Receipt scanning, collaborative item claiming, shared dishes, tax and tip calculations, individual contributions, and the final virtual card payment all connect within the same flow.

Each step feeds naturally into the next. The scanned receipt becomes a shared bill, everyone’s selections become an exact amount to approve, and their contributions determine when the group card becomes available.

We’re also proud of the concurrency handling and payment protections we implemented. Multiple people can interact with the same bill while the backend validates changes to prevent conflicting claims and inconsistent totals. We added safeguards against duplicate payment requests and unauthorized access, and tied payment approval to the exact bill version each person reviewed. Coordinating these details was challenging, but it helped us build an experience that takes both collaboration and people’s money seriously.

What we learned

A lot happens between tapping “Pay” and a restaurant getting its money. We learned that collecting contributions, funding a card, and completing a purchase are separate steps, each with its own timing and potential failures.

We also saw concurrency and security become very concrete. Two friends claiming the same fries is a coordination problem. Someone tapping “Pay” twice could become a financial one. Keeping bills consistent, approvals explicit, and retries safe taught us how much careful engineering goes into making checkout feel effortless.

What's next for Split Pool

Our next priority is putting Split Pool through more rigorous testing, both technically and with real people. We want to test simultaneous edits, interrupted connections, failed payments, and retries to understand how reliably the app handles the messier parts of a group checkout.

We also want to put it in front of groups splitting actual restaurant bills and see whether it makes the experience easier. We’d measure how long the process takes, how often someone needs help or corrects a mistake, and how it compares with their usual approach. Watching people use it will help us identify friction we’ve overlooked and find out whether Split Pool delivers on its promise of making dinner easier to settle.