#mobiledevelopment #backenddevelopment #database #infrastructure
Campus rideshare is informal. Nobody wants to enter a card number. But "figure it out after the ride" doesn't work either — it creates friction and confusion at drop-off. We needed a payment flow that's lightweight, works with Venmo and CashApp, and doesn't require GusLift to touch money.
Here's what we built.
Fare Calculation
Fares are computed from the straight-line distance between two campus buildings using the Haversine formula. The base fare is $1.00. Distance adds $0.75 per mile on top. All 20 Augustana buildings have precomputed lat/lng coordinates, so the fare for any route is deterministic and computable on the client with no API call.
The rider sees an estimated fare on the home screen before they even request a ride, calculated from their saved commute. That number is confirmed again on the ride detail screen once a match is made.
Driver Payout Settings
Drivers configure their preferred payment method once — Venmo handle, CashApp tag, Zelle phone number, or "cash." This is stored in a driver_payment_settings table in Postgres. When a rider views a confirmed ride, they see which method the driver accepts and the amount to send.
We also scaffolded Stripe Connect routes for future use, but that path isn't active. For now, all transactions happen off-platform.
The Verbal Code
The rider generates a 4-digit code through the app after paying. The code is written to the Rides table and marked code_issued. At drop-off, the rider reads the code to the driver, who enters it in the driver ride detail screen. The backend verifies the code matches, marks the ride payment_verified, and that's it.
There's no escrow, no hold, no dispute mechanism. The code is purely a lightweight confirmation signal: the rider clicked "I paid" and got a code; the driver confirmed they heard it. For a campus app where both sides know each other by face, that's sufficient.
Schema Changes
Four new columns on Rides: fare_cents, payment_code, payment_status, payment_method. One new table: driver_payment_settings. The ride history screens for both roles now surface payment status on completed rides.
What's Left
The flow assumes the rider pays before the ride ends and that the driver actually checks the code. There's no enforcement if either side skips. For pilot scale — a few dozen rides a week — that's acceptable. Rate limiting on code generation and expiry on unverified codes are the obvious next additions.
