Campus food delivery where one checkout splits meal points and a card, and one account switches between ordering and delivering.
Treat it as a single order with two tenders rather than two payments. The order total is settled first against the meal-point balance, and only the remainder is charged to the card through Stripe. The customer sees one checkout and one receipt, and the restaurant is paid once.
Because the obvious implementation makes two payments, and two payments can half-fail. A meal-point deduction that succeeds while the card charge declines leaves a student short of points with no food, and reversing it after the fact is a support ticket rather than a transaction.
Modelling it as one order with two tenders keeps the decision in one place. The order knows what it is owed, the balance covers what it can, and the card covers the rest. If the card leg fails, nothing has been committed, because the balance is not spent until the order as a whole is settled.
Because on a campus they are the same person at different hours. A student ordering dinner on Tuesday is a student with a free hour on Wednesday, and asking them to install a second app to earn is a barrier with nothing behind it.
One account carries both modes, and React Navigation switches between them rather than between products. That keeps a single identity, a single session and a single support story, instead of two accounts that have to be reconciled when something goes wrong.
With one lifecycle that every side reads instead of three views that each track their own progress. It is a state machine: placed, preparing, ready, picked up, delivered, with the restaurant advancing it from the kitchen, the courier advancing it on pickup and drop-off, and the customer watching it move. A three-sided marketplace only works when the three sides cannot disagree about where an order is.
Push notifications follow that same lifecycle through FCM and APNs, so the phone update and the screen are reading from one source. When status lives in three places, the divergence always shows up to the customer first.
Through Stripe Connect, so earnings are routed to the courier's own connected account rather than paid out by hand at the end of a period. Delivery is a job someone does for an hour between classes, and the payout has to be as automatic as the order.
Routing it through the payment provider also keeps the platform out of the business of holding and disbursing other people's money, which is the part that turns a side project into a compliance problem.
A much smaller map and a much higher bar for identity. Delivery is between dining locations and dorms on the Malibu campus, so routing is a short walk rather than a traffic problem, but the people on all three sides belong to one institution and the meal-point balance is university money.
It also has to be removable. Self-service account deletion is built in, both because the app stores require it and because a student who graduates should be able to leave without emailing anyone.
A campus delivery platform live at pepperdineeats.com and on Google Play, with an iOS build prepared for the App Store, covering ordering, dispatch, payment and payout for customers, restaurants and couriers.
| Client | Pepperdine University, Malibu campus |
|---|---|
| Sides | Customers, restaurants, couriers, plus admin |
| Mobile | React Native 0.83, New Architecture (Fabric), Hermes |
| Modes | Customer and courier on a single account |
| Payments | Split tender across meal points and card via Stripe |
| Payouts | Stripe Connect, routed automatically to couriers |
| Orders | One lifecycle read in real time by all three sides |
| Notifications | FCM and APNs, following the order lifecycle |
| Dashboards | Next.js restaurant and admin surfaces |
| Account control | Self-service deletion, store-compliant |
| Release | Live at pepperdineeats.com and on Google Play, iOS build prepared for the App Store |
Paying for one order with more than one source of funds. Here the order total is settled against a student's campus meal-point balance first, and only the remainder goes to the card through Stripe. It stays one order, one checkout and one receipt rather than two separate payments the customer has to reconcile.
Yes, and on a campus it should be. QuadQravings carries both modes on a single account and switches between them in the app, because the student ordering dinner is often the same student who wants to earn an hour later. Two accounts would mean two identities to reconcile for no benefit.
Through connected accounts at the payment provider rather than manual transfers. QuadQravings routes courier earnings with Stripe Connect, so a completed delivery leads to a payout without an operator moving money, and the platform never has to hold or disburse funds itself.
By keeping one order lifecycle that every side reads, rather than letting the customer app, the restaurant dashboard and the courier view each track their own progress. Push notifications follow the same lifecycle, so the phone and the screen can never disagree about where an order is.
It is built as a single React Native codebase targeting both. The Android app is live on Google Play, and the iOS build has been prepared for App Store submission. The platform is online at pepperdineeats.com.
Groceries and household essentials delivered across cities — five connected products sharing one catalog, one order and one backend.