I work in a non-profit organization. We have a central kitchen for the kids we care. We sell some tickets for meal to the college students nearby our head quarter. (90’s partenrship ;-))
Today, they buy some tickets (6€/meal) to the accountacy service. Usally they buy 10 tickets or less with cash or their parent’s check. On the other other side, they book seats by taking contact directly with the central kitchen team. (phone, mail or one to one).
I would like to create a booking service. The idea is : Students or their parents contribute to their own fund (using Stripe Service) and make some bookings. (1 booking costs 6 euros today, but can change in the future).
I would like the central kitchen team just checks whether or not the person is present (by using a tablet for example).
For example 1 student has a fund about 60 euros in his account. He makes 5 meal bookings. 60 - (5x6) =30 euros)
Booking - student reserves and pays a meal slot in advance. Attendance check - the kitchen team isn’t processing a payment here, they’re just confirming the person showed up. The money is already handled previously so we’ll do a deduction from their balance.
So the flow would be:
Student tops up balance via payment (using Stripe)
Student turns up for a meal
Kitchen team marks them as present on the tablet - balance deducted immediately from their record
This is how I’d probably structure it to start with:
User
Role (option set: Student, Kitchen Staff, Admin) to make sure only the right people can use the Tablet functions.
Student Account (Bubble type is User)
€ Balance (number)
Student Name (text)
Student ID (text)
Any other student info like contact details as needed
Transaction
Student (Linked to a User) - this links the transaction (what happened) to a particular Student User.
Amount (number)- this will be how much they paid in that transaction, or how much was deducted, we can separate the two in the ‘Type’ below.
Type (option set: Top-up, Deduction), this will differentiate the transaction from either a balance top up, or a deduction for a meal via the table.
Stripe Payment Intent ID (text) - captured from the Stripe API call so you can link the Bubble record to the Stripe record.
Created Date (date) - this will be built in by Bubble so nothing to create here.
Price Per Meal (number) - you might want to change this later down the line, creating it once means you can edit it later and you can easily link it to the Transaction that occurs when the tablet is used.
The flow in Bubble then is:
Stripe webhook/Bubble Plugin Action fires on successful payment → create a Transaction of Type ‘Top Up’ in the database, link it to Student → add the payment amount to that Student’s Account balance
Kitchen staff find the student on the tablet (search by name or ID/whatever you’ll use to find the student)
Staff tap a button → backend workflow checks balance >= meal price, creates a Deduction Transaction, decreases the balance by one meal (€6). Make sure to have a check that the Student has enough balance before running the deduction to prevent free meals and a negative balance.
The Transaction database table gives you a full trail for both top-ups and deductions in one nicely structured, filterable place (you can create a database view in Bubble for both the Deduction Type and Top Up Type, and the separate Meal Price record means you can update the 6€ without touching any logic.
