Inside a Ride-Hailing App: How Booking, Matching, Pricing and Payments Work

⏱ 10 min read

A ride-hailing app is really three apps and a set of backend services working together: a passenger app that requests and pays, a driver app that accepts and navigates, an admin panel that sets rules, and a server that matches, prices, tracks and settles every trip in real time. In the Philippines, LTFRB rules shape that design directly, from the 5 km maximum matching radius for TNVS to fare items that must be shown before booking. This guide walks through each part in plain language.

It is written for founders, operators and product managers who want to understand what they are paying a developer to build, or what to ask when evaluating a platform. We explain how the parts commonly work in general terms; your specific design will depend on your service, your scale and the rules that apply to you.

The big picture: three apps, one backend

Think of a ride platform as a marketplace that has to make decisions in seconds. The pieces are:

The apps are mostly screens and sensors. The real logic sits on the server, so rules can change without waiting for every user to update their app. That principle matters a lot in a regulated market where fares change by circular.

Passenger and driver apps are often built with a cross-platform framework so one team can ship Android and iOS together. Our Flutter vs React Native comparison covers that choice, and when native still wins explains the exceptions, such as demanding background location work.

Step by step: the life of a trip

Here is what happens from the moment a passenger opens the app:

1. Location and destination. The passenger app reads the phone’s GPS, suggests a pickup point, and searches for the destination through a places or geocoding service.
2. Quote. The backend asks a routing service for distance and estimated travel time, then the pricing engine produces an itemised fare estimate.
3. Request. The passenger confirms. The trip is created with the status “requested”.
4. Matching. The matching service finds eligible online drivers and offers the trip, usually to one driver at a time or to a small batch.
5. Acceptance. A driver accepts; the trip becomes “matched” and both apps switch to tracking mode.
6. Pickup. The driver app streams location every few seconds; the passenger sees the car approach.
7. Trip. The driver starts the trip, the app records the route, and the drop-off ends it.
8. Settlement. The final fare is computed, payment is captured or cash is recorded, and an e-receipt is issued.
9. Rating and records. Both sides rate each other, and the trip record is stored for support, reports and audits.

At any point before pickup, either side may cancel. That branch matters in the Philippines: under MC 2025-055, booking cancellations can be treated as refusal to convey, and TNCs must report cancellations monthly, as reported by Top Gear Philippines on December 12, 2025. So the trip state machine must log who cancelled, when and why.

Matching: finding the right driver fast

Matching is where most people imagine an “algorithm”. In practice it is a series of filters and a ranking.

Filter: who is eligible

• Driver is online and not on another trip.
• Vehicle type matches what the passenger chose.
• Driver documents and account are in good standing.
• Driver is within the allowed distance of the pickup point.

That last filter has a regulatory number attached. According to GMA News and the Daily Tribune, the LTFRB’s permanent pick-up fare policy, announced in July 2026, sets a 5 km maximum matching radius for TNVS.

Rank: who gets the offer first

Among eligible drivers, the system usually ranks by estimated time to pickup, not straight-line distance. A driver 1 km away across a river or on the wrong side of a divided highway can take longer than one 2 km away on the same road. Good systems use routing estimates for the top few candidates.

Making it fast

Searching every driver for every request does not scale. Platforms store driver positions in a geospatial index, which divides the map into cells so the system only checks drivers in nearby cells. Fresh positions often live in an in-memory store, because they change every few seconds.

Pricing: an engine, not a formula

A fare is a sum of components, each with its own rule. For a Philippine TNVS trip in 2026, reported rules include:

• Base fare by vehicle type. According to the Daily Tribune, from September 28, 2026 these are ₱55 for hatchbacks, ₱65 for sedans, ₱75 for AUVs and ₱165 for premium units.
• Distance and time charges per the official fare matrix.
• Pick-up fare, from ₱24 to ₱120 for hatchbacks up to ₱58 to ₱289 for premium, scaled by distance up to 5 km. It goes 100% to the driver and must be shown separately before booking and on the receipt.
• Surge, where allowed. The LTFRB capped holiday surge at 1x from December 17, 2025 to January 4, 2026 under MC 2025-056; that cap has ended.

Taxis on an app follow different rules: MC 2026-055 caps app booking fees at the lower of 20% of the fare or ₱60, disclosed before booking and itemised on the receipt, according to Philstar.

The passenger sees one number. The pricing engine sees five rules, two caps and an effective date.

Estimate versus final fare

The quote uses a predicted route; the final fare uses the actual one. Your product must decide how to handle the difference, for example by locking the quoted fare or recalculating with a clear explanation. Whatever you choose, the receipt must itemise each component so passengers and auditors can check it.

Payments: cash, wallets and cards

Cash is still common, but digital is growing fast. According to the BSP’s 2025 report on e-payments, reported by the Daily Tribune on August 19, 2026, digital payments made up 64.7% of retail payment volume in 2025, and QR Ph transactions overtook cards.

A ride app’s payment layer usually handles:

• Cash trips, where the platform records the fare and later collects its commission from the driver.
• E-wallets and QR, through a payment gateway that supports GCash, Maya and QR Ph.
• Cards, with tokenised storage handled by the gateway, never by your own servers.
• Driver payouts, calculating earnings net of commission while keeping non-commissionable items, such as the TNVS pick-up fare, whole.
• Refunds and disputes, tied back to the trip record.

Our payment gateway stack guide compares integration approaches in more depth, and accepting GCash and Maya covers wallet specifics.

Maps, location and real-time tracking

Maps power four separate jobs: showing the map, turning addresses into coordinates (geocoding), calculating routes and travel times, and tracking live location. Each may be billed separately by the provider, which is why maps and location API costs deserve early planning.

Live tracking typically works like this:

1. The driver app reads GPS and sends a position update every few seconds while online.
2. The server updates the geospatial index and the active trip record.
3. The passenger app receives updates through a persistent connection, such as WebSockets, or through push messages.

Philippine conditions add challenges: patchy signal in some areas, phones with aggressive battery savers that stop background apps, and GPS drift in dense city centres. Designing for these realities is covered in our offline-first resilience guide.

The admin panel: where policy becomes software

The admin panel is often under-built, yet it is where an operator stays compliant. Essential functions include:

• Driver onboarding and document review.
• Fare tables, pick-up fare bands and surge ceilings with effective dates.
• Service zones and vehicle types.
• Trip search, support tickets and refunds.
• Reports, including monthly cancellation summaries.
• Role-based access so staff only see what they need.

Privacy and security

A ride platform holds names, phone numbers, home and work locations and travel patterns. The Data Privacy Act (RA 10173) applies. A historical example shows how regulators view intrusive features: in February 2020, the National Privacy Commission ordered Grab to halt passenger selfie and in-car audio and video recording, as reported by Newsbytes. Collect only what you need, protect it, and limit who can see live locations. Our post on trust and safety for on-demand apps goes further.