TableKind — agree on the split, then pay your share

Inspiration

A restaurant bill mixes individual dishes and shared food. Equal division can feel unfair, while manually working out each person's items slows the end of a meal. I wanted the group to express its agreement naturally and still see exactly what every person owes.

What it does

Three friends order individual dishes and a shared starter. A diner describes the split, then reviews an item-by-item preview and resulting totals. Everyone affected must agree before the bill changes. Each diner pays their own confirmed share through PayPal sandbox, and the table keeps an exact remaining balance.

GPT-6 Luna interprets the request into structured item and diner references. TableKind validates those references and computes money deterministically. Ambiguous or unsupported requests require clarification. The model cannot move money or consent for another diner.

PayPal Orders v2 creates an order for the reserved share. PayPal hosts buyer approval, and the backend verifies the order, merchant, currency and capture amount before settling those portions. Durable records and reconciliation support retries and interrupted browser sessions.

How I built it

Java 21, Spring Boot, PostgreSQL, React, TypeScript and Docker. The hosted demo runs on Render with a persistent database. The interpreter uses OpenAI Responses with low reasoning and strict structured output.

The project began as a restaurant SaaS idea and became a portfolio application before this hackathon. That baseline already had ordering, an integer ledger, manual sharing proposals and votes, command idempotency and simulated payments. For this entry, I added the isolated EUR scenario, real PayPal sandbox Orders v2 integration, hosted AI interpretation, reviewed multi-item proposals, provider recovery and the three-diner interface. The original MDL history is preserved. This is an extension of existing work, not a claim that the whole application was built during the event.

AI coding tools helped with implementation, tests, debugging and presentation preparation. I directed the work, reviewed behavior and tested the actual application. The demonstration uses synthetic Andre narration and a generated and retouched photograph of three fictional diners, animated in After Effects. Its interface views are high-density captures and rendered UI exports from real app and PayPal sandbox runs, edited as held views rather than continuous 4K screen recording.

Challenges I ran into

The difficult part was keeping the group's agreement and payment state correct across delayed responses. A preview can become stale while the table changes, so it carries a revision and must be reviewed again. A successful redirect is not proof of payment, so the backend checks the stored order and completed capture before updating the ledger. Payment network calls happen outside database locks, and recovery continues from the original attempt.

Rounding also matters. Sharing a EUR 7.01 starter equally produces EUR 2.33, EUR 2.34 and EUR 2.34. The server assigns the remainder deterministically so no cent disappears.

Accomplishments I'm proud of

The hosted GPT-6 Luna journey completed a real preview, all three diners' consent and three actual PayPal sandbox captures. It settled EUR 38.01 with zero outstanding and zero reserved; those totals survived reload. Six representative local Luna evaluation cases also passed, including ambiguous and unsupported requests. These are bounded tests rather than a claim of universal model reliability.

The payment integration was separately checked for tips, completed-payment replay and recovery after approval while the backend was stopped. Those earlier recovery checks are documented separately from the recorded walkthrough.

What I learned

A useful AI payment experience needs clear responsibilities: natural language helps express intent, deterministic code checks financial facts, and people approve changes to their own responsibility. Preview and consent are essential parts of the experience.

What's next for TableKind

Gather feedback on the dinner flow and validate it with restaurants. Beyond the hackathon, I would work through the requirements for a production payment rollout. PayPal refunds, live payments, fiscal receipts and real POS integration are outside this entry's scope.

Current demo and image credits

The current published source is commit 874f40838b4994976ae3aed311353a3c71d9b496 on the hackathon/paypal-bill-splitting branch. The app uses the Ink and Saffron theme and locally served, licensed representative photographs from Wikimedia Commons: 78 distinct photo contents across 222 menu image files, including compatibility paths for older dinners. Related dishes may share an image; photos do not verify exact recipes, brands or serving sizes.

The menu links to photographer credits, original source pages, individual licences and crop/resize notices. Adapted photographs retain their source licences, including ShareAlike where applicable; the MIT licence applies to application code. Credits: https://tablekind-hackathon.onrender.com/menu/photo-credits.html

On 28 October 2026, the hosted credits page and sampled burger/pepperoni photo hashes matched the licensed replacements. All 12 local menu/catalogue/provenance checks and the frontend production build passed. This publication check is separate from the earlier full AI and PayPal sandbox walkthrough. The approved demo video is available unlisted on YouTube with no password, and anonymous playback and 4K60 availability have been verified.

Built With

• docker
• java
• openai
• paypal
• postgresql
• react
• render
• spring-boot
• typescript