This is a submission for Weekend Challenge: Generosity Edition What I Built Open Tab lets one customer's spare change help with someone else's purchase. A customer reaches checkout and chooses to add a small contribution. The money enters a shared pool. Another customer can use part of that pool during an ordinary checkout, with no application and no explanation required. I built it around a familiar moment: someone has enough for most of a purchase and could use a little help with the rest. Asking a stranger or an employee can feel exposing. Open Tab keeps that moment inside the same payment screen everyone uses. The weekend prototype connects two fictional local businesses, Café Sol and Bread & Butter Bakery. Each business has its own employee route and product catalogue. Both feed the same Open Tab pool and activity ledger. The contribution follows a predictable rule. A purchase moves toward the next 50-cent mark. When the total already ends in .00 or .50, Open Tab adds €0.20 instead. The customer always sees the amount before paying. Why small amounts can work Research supports testing a small round-up prompt ahead of a flat donation request. A study in the Journal of Consumer Psychology found that people responded more favourably to round-up requests even when both formats asked for the same amount. The researchers linked the effect to lower perceived pain of giving. An Open Tab pilot would still need to measure its own contribution rate. Kelting et al., Would You Like to Round Up and Donate the Difference? Everyday food purchases create repeated opportunities for that choice. The UK's nationally representative National Diet and Nutrition Survey found that 72% of participants had bought food or drink away from home during the previous seven days. Most did so once or twice that week. In its shorter food record, 17% reported an occasion involving a café, coffee shop, sandwich bar, or deli. These figures show recurring relevant transactions rather than expected Open Tab usage. UK National Diet and Nutrition Survey, 2019 to 2023 Digital checkout provides an existing place for Open Tab across the euro area. The ECB's SPACE 2024 study drew on 50,000 consumers. It reports continued growth in digital payments, with cards remaining the most popular digital method. Electronic payment acceptance increased across every euro-area country. European Central Bank, SPACE 2024 The demo menu is an illustrative local price book. It ranges from a €1.80 butter croissant to a €10.50 pasta bowl, while most drinks cost between €2.50 and €4.50. Pret's public UK delivery menu listed an all-butter croissant at £2.70 and a flatbread at £6.15 on September 7, 2026. This comparison supports the general purchase scale rather than a claim about average European prices. Pret A Manger delivery menu At that scale, cents accumulate quickly. If 100 eligible checkouts contributed an average of €0.25, the pool would receive €25 in one day. With 200 eligible checkouts at the same average, it would receive €50. These examples are arithmetic scenarios. Real results depend on checkout volume and customer participation, with local pricing and programme rules also shaping the total. For a participating business, Open Tab could create community affinity without requiring a points programme. Regular customers can see that their small contribution has a local use, giving them a reason to feel connected to the venue. That loyalty effect remains a product hypothesis. A pilot would need to measure merchant willingness alongside customer return behaviour. Demo Live employee views: Café Sol Bread & Butter Bakery Customer terminal: Open Customer Checkout Keep an employee view open and place Customer Checkout beside it. Contribute to Open Tab Choose products on the employee screen and create a checkout. The customer terminal receives the order. Select the round-up option and watch the shared pool increase on the employee dashboard. Use the shared pool Create a fresh checkout and select Use Open Tab on the customer terminal. Available choices adapt to the purchase and current pool balance. Apply one choice, pay the remainder, then return to the employee screen to see the receivable and updated activity. Payments are simulated for this challenge. The persisted accounting lifecycle models how contributions and assisted purchases move through the system. Code Source: github.com/Thegm26/open-tab The key accounting transition is authorization. It locks the shared scenario and order before checking available funds. An idempotency record makes a safe retry return its original result. select * into s from public.demo_scenarios where id = c.scenario_id for update; select * into o from public.orders where id = c.order_id and scenario_id = s.id for update; out := public.ot_idempotency_replay(s.id, 'authorize', p_key, p_hash); if out is not null then return out; end if; select s.settled_pool_cents - coalesce( sum(amount_cents) filter ( where status = 'authorized' and expires_at > v_now ), 0 ) into v_available from public.fund_reservations where scenario_id = s.id; if p_amount > v_available then raise exception 'INSUFFICIENT_POOL'; end if; How I Built It Open Tab uses Next.js with TypeScript. Employee routes provide the point-of-sale controls for each business. Customer Checkout follows the newest order and updates as its payment state changes. Supabase provides persistent Postgres storage. Every monetary value uses integer cents, which avoids floating-point accounting errors. Transactional RPC functions own the important balance changes. A round-up creates a pool credit only after simulated payment succeeds. When someone requests help, Open Tab creates a short-lived claim and reserves the chosen amount. The purchase total sets the ceiling. Pool availability and server policy can reduce it further. An assisted purchase creates a merchant receivable for the amount covered by Open Tab. Employees can settle outstanding receivables from the dashboard. Refunds preserve the split between customer money and pool money. Eligible funds return to the pool, while a refund after settlement creates recovery debt. The app uses idempotency keys with request hashes for payment-sensitive operations. A retry with the same input returns the recorded result. Reusing that key with changed input fails safely. The interface is responsive across phone and desktop layouts. Activity pagination keeps a longer ledger readable, while separate customer and employee views make the live checkout loop easy to follow. The automated suite currently passes 40 tests across 7 files. It covers the reservation lifecycle, refund accounting, settlement behavior, and repeated requests. The production build also passes TypeScript validation. This remains a focused hackathon simulation. It uses one shared terminal lane for the newest order. A production POS integration would assign terminal lanes to specific merchant devices and connect them to a payment processor. The part I cared about most was preserving dignity at checkout. Customers see a quiet, ordinary choice. Underneath that choice, the ledger protects funds that another person may rely on.