Forem: Nathan Sisay

Strengthening Ride Matching, Notifications, and Schedule Management

Nathan Sisay — Fri, 22 May 2026 03:17:59 +0000

For our last week, focused on improving session persistence and preparing GusLift for broader platform support. This week, we continued improving the core ride-sharing experience by working on notifications, routing, schedule management, ride matching, and user interface consistency.

Improving Push Notifications

One major focus this week was improving push notification support.

Push notifications are important for a ride-sharing app because riders and drivers need to receive updates quickly. For example, a rider should know when a driver responds to a ride request, and a driver should know when there is activity related to a potential ride.

To support this, the app was configured to work with Expo notifications and Firebase notification services for Android.

On the backend, notification token handling was added so the app can store device push tokens. This allows the system to know where notifications should be sent when ride or matching events happen.

The matching worker was also updated to support push notification behavior, helping connect real-time ride matching events with user-facing alerts.

Why Notifications Matter

Without notifications, users would need to constantly keep checking the app for updates.
That would make the ride experience slower and less reliable.
By adding notification support, GusLift can begin moving toward a more real-time experience where users are alerted when something important happens.

This is important for matching riders and drivers, since timing matters when coordinating rides.

Improving Routing and Login Flow

Another major area of work was improving how users move through the app after logging in.

Several routing fixes were made so riders and drivers land on the correct screens based on their role and setup status.

For riders, the app was updated so they consistently land on RiderHome instead of being sent to the older RequestRide screen. Older entry points to the previous request screen were removed or redirected.

A new route helper was also added to centralize user routing logic. This makes the app easier to maintain because routing decisions are handled in one place instead of being scattered across multiple screens.

Improving Ride Matching Visibility

This week also included improvements to the ride matching experience.

The app now shows pending driver matches more clearly on rider home and scheduled rides screens. This helps riders understand when a match is waiting for action instead of hiding it deeper in the app.

There were also fixes to prevent drivers from re-selecting riders who already rejected them.This makes the matching process feel more logical and prevents confusing repeat interactions between riders and drivers.

Updating Schedule Management

Schedule management was another important improvement.
The older change-schedule flow was replaced with a cleaner view and edit schedule experience. This gives both riders and drivers a better way to manage their availability and planned rides.
The schedule screens were also connected more cleanly from the rider and driver home pages.

This matters because scheduling is one of the core features of GusLift. Riders need to plan rides, and drivers need to manage when they are available.

Improving Time Display and Ride History

Many commits focused on fixing time display issues.
Waiting room times, manual ride times, and ride history display were updated so users see more accurate and consistent information.
This is especially important for a ride-sharing app because incorrect time information can quickly make the experience confusing.
Ride history was also improved so past ride information displays more reliably for users.

User Interface Improvements

We also made a lot of visual and layout improvements.
Rider screens were restyled for better color and layout consistency. Home screens and waiting room screens were updated to better match the app’s brand palette.
Quick-action buttons were added to rider and driver hero cards, and a new logo was added to the homepage.
These changes help the app feel more polished and easier to navigate.

Before deployment, we plan on:

Testing push notifications across more devices
Improving the full rider-driver matching flow
In app chat functionality
Connecting payment status more closely with ride status
Continuing to clean up time and schedule logic
Improving reliability of ride history and scheduled ride screens

Stripe Payment and Processing

Nathan Sisay — Mon, 18 May 2026 05:37:29 +0000

Since GusLift is a ride-sharing platform, payments are an important part of the user experience. Riders need a simple and secure way to complete payment, while the backend needs a reliable way to track payment status for each ride. To begin this process, we integrated Stripe Checkout into the project.

Implementing Stripe Checkout

One of the biggest goals so far was to create a payment flow that could be tested safely during development.
To do this, we added a backend route that creates a Stripe Checkout Session. When the mobile app requests a payment, the backend communicates with Stripe and receives a hosted checkout URL.
The user can then open that Stripe-hosted page and complete the payment using a test card.
This approach is useful because Stripe handles the secure payment form, card validation, and checkout experience. GusLift does not need to directly collect or store sensitive card information, which makes the implementation safer and easier to maintain.

Connecting Payments to Rides

Another important part of the payment system was making sure payments could be connected back to a specific ride.
When a checkout session is created, GusLift can include ride information such as:
-Ride ID
-Rider ID
-Ride label
-Customer email
-Payment amount

This information allows the backend to keep track of which payment belongs to which ride.
We also added support for storing payment records in a RidePayments table. This table keeps track of information such as the Stripe checkout session ID, payment intent ID, amount, currency, checkout URL, and payment status.
This gives the app a clearer record of what happened during the payment process.

Handling Payment Status

After a user finishes checkout, Stripe redirects them to a success page. GusLift then retrieves the checkout session details from Stripe and updates the payment record.
If the payment was completed successfully, the record can be marked as paid. If checkout is canceled, the payment can be marked as canceled instead.
Tracking these states is important because ride status and payment status are separate things.
For example, a ride could be accepted, but the payment may still be pending. Keeping those states separate makes the system easier to reason about as the app grows.
Building the Mobile Checkout Screen
On the mobile side, we added a Stripe Demo Checkout screen.
This screen checks whether the backend payment configuration is ready before allowing the user to continue. If Stripe is configured correctly, the user can tap a button to launch checkout.
For the current development version, the checkout uses a fixed demo amount of $5.00.
The mobile screen also supports passing ride-related information into the checkout flow, which helps prepare the app for real ride payments later.

Why Stripe Matters

Stripe is useful for GusLift because it allows us to build payment processing without needing to manage sensitive payment details ourselves.
Instead of building a custom card form from scratch, we can use Stripe’s hosted checkout flow. This improves security, reduces complexity, and lets the team focus more on the ride-sharing experience.
It also gives us a strong foundation for future payment features, such as authorizing payment when a rider confirms a driver and capturing payment after the ride is completed.

Some of the next milestones include:

Connecting payment more directly to confirmed rides
Improving success and cancel handling in the mobile app
Adding webhook support for more reliable payment updates
Moving from simple checkout payments toward authorization and capture
Testing the full ride flow from request to completed payment

By integrating Stripe Checkout, adding backend payment routes, and storing payment records, the app now has a basic but functional payment flow. While there is still more work to do before payments are production-ready, this is an important step toward making GusLift feel like a complete ride-sharing platform.

Forem: Nathan Sisay

Strengthening Ride Matching, Notifications, and Schedule Management

Improving Push Notifications

Why Notifications Matter

Improving Routing and Login Flow

Improving Ride Matching Visibility

Updating Schedule Management

Improving Time Display and Ride History

User Interface Improvements

Before deployment, we plan on:

Stripe Payment and Processing

Implementing Stripe Checkout

Connecting Payments to Rides

Handling Payment Status

Why Stripe Matters

Some of the next milestones include:

Stripe Payment Processing

Implementing Stripe Checkout

Connecting Payments to Rides

Handling Payment Status

Why Stripe Matters

Some of the next milestones include:

Stripe Payment Processing

Implementing Stripe Checkout

Connecting Payments to Rides

Handling Payment Status

Why Stripe Matters

Some of the next milestones include: