Lost revenue from silent payment failures recovered and booking conversion rebuilt for one of India's largest bike-hailing platforms

The platform was India's largest bike-hailing service. Customers wanted the product. The market was there. The problem was the app itself.

A bug in how payment requests were sent caused transactions to fail without the customer knowing. A customer would complete a booking, the payment would appear to go through on their phone, and the transaction would fail on the company's side. The company lost the revenue. The customer was confused. The failure wasn't recorded. Across thousands of daily bookings, this was a material revenue leak.

Device-specific crashes locked out customers before they could complete a booking. Certain Android device models hit issues the team knew about but couldn't fix reliably, because the app was structured so that changing one feature often broke another. A fix to the payment screen could break the booking screen. A fix to the booking screen could break captain search. No one had high confidence in what a given change would affect.

The booking flow itself created friction at every step. Address search was slow and unresponsive. Selecting a pickup location required multiple taps. Captain search gave users no indication of progress. Each friction point was a place where a customer decided to use a competitor instead.

Five wallet integrations meant five separate failure modes. Paytm, Amazon Pay, LazyPay, Simpl, and the platform's own wallet each had different rate limits, different response patterns, and different error states. There was no orchestration layer managing them. Each integration was its own implementation, and each failed in its own way.

The team couldn't move fast enough to fix any of this. The app's structure made every change risky, every release a manual testing exercise, and every new feature a negotiation with what was already fragile.

We rebuilt the entire Android application. The payment layer, the booking flow, the location stack, and the UI system. The brief was not to patch what was broken - it was to build something that could hold at scale without the same failure patterns recurring.

Independent feature modules. The app was restructured so each major feature - booking, payments, rewards, location, captain search - is its own self-contained module. A change to payments cannot accidentally break booking. A change to booking cannot affect captain search. Engineers ship updates to one area without manually testing every other screen. The team moves at the speed the business needs.

Modern UI framework. The full interface was rebuilt in Android's current UI framework (Jetpack Compose). The approach is simpler to test and gives fine-grained control over how the interface renders on different devices. A design system (RDS) built on top ensures every screen looks consistent and gives the team a library of validated components to build from rather than starting each new screen from scratch.

Payment orchestration layer. We built a single payment stack that manages all five wallets plus UPI. Each wallet has different response times, rate limits, and failure patterns - the orchestration layer handles all of that invisibly. Customers see one payment flow. The complexity is underneath. Each payment request is designed to complete exactly once, even if the app retries after a timeout or the connection drops before the response arrives. The bug that was failing transactions silently is gone.

Booking flow rebuilt for speed. Address search responds as you type. Saved favorite locations load from local cache instantly. Pickup selection is visual. Captain search runs in the background with visible progress. Each step was evaluated for where customers were abandoning the flow and redesigned to remove the friction causing the drop-off.

Custom location SDK. Real-time captain search required high-precision, continuous location tracking. We built a custom location SDK that provides the update rate and accuracy the booking flow needs. Captain positions update with smooth animations as they move. The map feels alive rather than static.

Full funnel instrumentation. We instrumented 40+ analytics events across AppsFlyer, CleverTap, and Firebase, covering the complete journey from app open to ride completion. The team now has visibility into exactly where customers convert and where they drop off. That data drives ongoing optimization.

The payment bug that caused silent failures is gone. Each transaction across all five wallets either completes exactly once or fails with a clear, recoverable error. Revenue that was being lost to silent failures now completes. Customers see a payment flow that works. The complexity of managing five different payment providers happens underneath, invisibly.

Device crashes disappeared. The modular architecture and Compose-based UI eliminated the device-specific rendering issues that were blocking customers from completing bookings. Customers on all Android device configurations use the app reliably.

The booking flow conversion improved because the friction points were removed. Address search responds as you type. Saved locations load instantly. Captain search shows progress. Customers get to the booking confirmation faster and with fewer abandoned attempts.

The engineering team can ship. Feature modules mean payment changes don't touch booking logic, location changes don't touch rewards, and new features don't require manual regression testing across the whole app. Work that previously took weeks now takes days.

The 40+ instrumented events across the full funnel give the product team visibility they didn't have before. Drop-off points are visible. Conversion changes after each release are measurable. The team can optimize based on data rather than intuition.