Week 7: How GusLift Handles Payment Without a Payment Processor

Amanuel Demissie — Sat, 23 May 2026 10:29:57 +0000

#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.

Week 7: How GusLift Shows Your Route in Real Time

Amanuel Demissie — Sat, 23 May 2026 10:25:24 +0000

#reactnative #maps #crossplatform #mobiledevelopment

Every ride request involves two locations. The matching screen was showing those as text. Adding a map that actually shows both pins — pickup in green, dropoff in red, other participants in blue — is a small change in concept but a surprisingly tricky one in practice.

Here's how we got there.

The Native Maps Dead End

The first attempt used react-native-maps backed by Google Maps. It worked on iOS and Android simulators. It didn't work on web at all, and the native build requires an API key wired into the native layer, which adds friction every time someone clones the repo. After getting it running, we ripped it out entirely.

What We Replaced It With

The map is now a WebView embed running Leaflet over OpenStreetMap tiles. On web it renders as a plain <iframe srcDoc>. On iOS and Android it uses react-native-webview. Same HTML, same behavior, no API key required, no native build step.

The map HTML is generated at runtime. We compute a bounding box from all the pins, set the center and zoom dynamically, and inject the markers as JavaScript into the Leaflet page before it loads. Each pin is a custom SVG — a teardrop shape with a white circle — colored by role.

The Coordinate Layer

Campus buildings don't have addresses that geocoding handles well. We precomputed lat/lng for all 20 Augustana buildings from OpenStreetMap and stored them in a static lookup table — campusCoords.js. Every pin resolves through that table. No geocoding at runtime, no API call, no latency.

Where Maps Appear

RouteMap is a single reusable component that takes pickup, dropoff, and an optional extraMarkers array. It appears on:

The rider and driver waiting rooms (your own route while you wait)
The ride detail screens (confirmed route after match)
The available riders/drivers screens (driver sees all rider pickup pins; rider sees the driver's pickup pin in purple once matched)

The matching worker was extended to broadcast pickup_loc alongside to_location over WebSocket so that map pins for other participants are available on match screens without an extra DB fetch.

What Didn't Change

State, matching logic, and the Durable Object model are untouched. The map is purely display — it reads locations already present in the app state and renders them.

DEV Community: Amanuel Demissie

Week 7: How GusLift Handles Payment Without a Payment Processor

Week 7: How GusLift Shows Your Route in Real Time