split-the-bill

home-page
custom payment page ui for individuaks
stripe-checkout
payment success page
payment update status
history of previous payments with delete button

Inspiration

When a group splits a shared bill, one person almost always ends up fronting the money and then has to individually chase everyone else down for their share. This happened to me and my friends more times than I can count, and it seemed like a solvable problem, not just an annoyance to live with. When the Cursor Dhaka x Stripe Community hackathon asked us to build something with Cursor and integrate Stripe, this was the first real, personal problem that came to mind.

What it does

Split the Bill lets an organizer enter a total bill amount, the number of people splitting it, and each person's name. It automatically calculates everyone's exact share and generates a unique payment link for each person. Each person opens their own link and pays their share directly through Stripe Checkout, no manual tracking, no chasing. The app shows live progress ("X of Y paid") and keeps a history of previous splits.

How we built it

I built it with Next.js 14 (App Router), React, TypeScript, and Tailwind CSS for the frontend, with Stripe Checkout Sessions handling payments through a Next.js API route. Cursor was used throughout, from scaffolding the project to iterating on features one prompt at a time. The app is deployed on Vercel, with environment variables synced for the live production URL. Since Stripe accounts currently cannot be created directly from Bangladesh, everything was built and tested in Stripe's test mode: real Checkout flow, real test cards, fully functional logic, just not live transactions.

Challenges we ran into

Plenty, and none of them were the "fun" kind. Windows blocked npm scripts entirely through a PowerShell execution policy restriction, which took a real fix (not a workaround) to resolve. Switching from Windows to Mac mid-project meant re-cloning and reconfiguring environment variables from scratch. Git merge conflicts came up more than once from parallel changes to the same file, which meant learning to actually read and resolve conflict markers instead of guessing. Vercel's Deployment Protection silently blocked anyone but me from opening the live link, which would have been a disaster to discover during the actual demo instead of before it. Handling dynamic base URLs between localhost and production also broke the payment redirect flow until it was properly abstracted. None of these were conceptually hard problems, but debugging them live, under a countdown, was a real crash course.

Accomplishments that we're proud of

Going from not knowing how to integrate Stripe at all to a fully working, deployed, end-to-end payment flow, tested and functioning, in one weekend. Also proud of catching the Deployment Protection issue before the actual demo, since that alone could have made the live link completely unusable in front of judges.

What we learned

Real payment integration (Stripe Checkout Sessions, test mode, success/cancel URLs), how to actually resolve git merge conflicts instead of avoiding them, environment variable management across local and production environments, and honestly, a lot about staying calm while debugging under time pressure. Also got a first look at Stripe Projects and the Stripe CLI as newer tools for provisioning services.

What's next for Split the Bill

Per-person shareable payment links already work today, each person gets their own link and pays independently through Stripe Checkout. The next real gap is that payment status only syncs on the device/browser that created the split, since it's tracked in localStorage rather than a shared backend. The next step is a lightweight database so payment status updates live across everyone's own devices in real time, not just the organizer's screen. Beyond that: email or SMS notifications when someone pays, and proper Stripe account activation once it becomes available for Bangladesh.