Change list and test notes

Back to the app launcher

Firebase layout, as found

The Driver app also loads the Firebase compat SDK for its wallet screen, pointed at driver-pro-card-login. That was left exactly as it was.

Root cause

The Rider app writes a request to active_trip_request and trips/{id} in driver-pro-card-login. The Driver app was listening to active_trip_request in rider-s-drivers-info. Two different projects, so the request never arrived, no driver was ever assigned, and Admin only ever saw an unassigned request. Everything else downstream (chat, GPS, payment, ratings) failed for the same reason.

Rider app

• Added shared/rider-bridge.v1.js. The original app code and every original Firebase function are untouched.
• tripId is now written next to id, and both hold the same value for the life of the trip.
• A stable riderId is generated once per device and stored, and a riders/{riderId} profile is written, so the Admin rider list is no longer empty.
• Requesting a ride while one is already running is blocked, so a double tap cannot create a second trip.
• Added a payment method selector. The choice travels on the trip record and is visible to Driver and Admin.
• Chat messages, tips, the star rating and the payment status are now written to trips/{tripId} as well as to the live pointer, using transactions so the Driver app cannot overwrite them.
• The driver is now drawn on the rider map from trip.driverLocation, and the status card shows the driver name, vehicle and trip id.
• Clearing a ride before it completes now marks the stored trip CANCELLED instead of leaving it stuck as requested.

Driver app

• Added shared/driver-bridge.v1.js. Login, approval, the wallet, the maps, the ringtone and the whole UI are untouched.
• The driver screens are now wired to the canonical database, which is where ride requests actually appear.
• Accepting a ride runs an atomic transaction: the first driver wins, a second driver is told the ride is gone, and no second trip record is created.
• Accepting writes driverId, driverName, contact and vehicle onto the existing trip.
• Status changes are guarded so a trip can only move forward, and only the driver who owns the trip can move it.
• Live GPS is published to driver_locations/{uid} and attached to the running trip (throttled to one write every three seconds). The legacy drivers/driver_location node is still written, so nothing that read it breaks.
• A safe profile mirror (name, email, phone, vehicle, plate, approval state, presence) is written to the canonical project so Admin can see and manage drivers. SSN, bank details and document photos are deliberately NOT copied: they stay in the driver login project.
• Admin approve and suspend decisions are applied live, without a reload, and mirrored back into the driver login database.
• Completing a cash ride asks the driver whether the money was collected and records the answer as the payment status.

Admin app

• Drivers are read from both projects and merged, so a driver shows up whether they registered in the driver login project or have already used the Driver app.
• The legacy drivers/driver_location GPS node is no longer mistaken for a driver account.
• Approve and suspend now write to both projects.
• Live trips show the trip id, the real driver name and plate, the payment method and status, the tip and a live GPS link.
• Trip history gained trip id, tip, payment and rating columns.
• Revenue is counted once per trip id across completed trips. The old total double counted the active trip and ignored history. Company earnings, driver payouts and completed trip counters were added next to it.
• Added the support chat panel, the missing other half of the support window that already existed in the Rider app.

Shared layer and tests

• shared/rideshare-sync.v1.js holds the rules all three apps agree on: one trip id, forward only status, first driver wins, message merging, fare and payout maths, payment states and revenue totals. It is pure JavaScript with no Firebase import.
• Those rules are covered by unit tests in the repository (tests/sync.test.mjs, run with node --test), including: accepting never mints a new trip id, a second driver cannot claim a taken ride, status cannot go backwards, simultaneous chat messages are merged rather than overwritten, tips go entirely to the driver, and revenue is never double counted.

Hardening after the code review

A second pass over the bridges found races that only show up when two people act at the same moment. All of these are fixed and covered by tests:

• Every write to active_trip_request now runs inside a transaction that refuses to recreate a ride that has just been cleared. A blind write there used to leave a half empty record that all three apps read as a brand new request, and it locked the rider out of booking again.
• The rider apps never write to a trip they do not own, and never write at all without a known trip id.
• Cancelling checks the stored trip inside the transaction, so a ride the driver completed a second earlier cannot be rewritten as cancelled (which would also have removed it from the revenue figures).
• Closing the tip window no longer marks an uncollected cash fare as paid, and no longer stamps a five star rating on a driver the rider never rated.
• COMPLETED and CANCELLED are terminal: nothing moves a finished ride again. Re-accepting a ride you already have cannot rewind it from "driver arrived" back to "on the way".
• The rider profile is merged rather than overwritten, so the phone number and joined date survive.
• Suspending a driver now publishes the offline state before the approval is withdrawn, so the driver does not stay shown as online. Only one admin decision watcher runs at a time, bound to the driver who is actually signed in.
• The Driver app's original listener on the other database can no longer tear down a live trip card.
• Admin can open the details and delete drivers that exist only in the driver login project.

Second review pass: five defects fixed

• Driver write loop. Applying an admin approve or suspend decision wrote a fresh timestamp to the same record the decision listener watches, so the listener fired again and wrote again. A pending or suspended driver's tab would write to Firebase without stopping. The decision is now applied once per actual change, and that branch no longer writes to the watched record at all. Measured in the browser test: the same scenario used to produce a thousand writes in two and a half seconds, it now produces at most two.
• One rider could delete another rider's live request. Clearing a finished ride used to delete the shared live pointer without looking at what was in it. Rider A closing a stale window could wipe rider B's brand new request. Clearing is now a transaction that only removes the pointer when it really is that rider's ride.
• Stale mirrors could revert newer information. Copying a live snapshot onto the stored trip could turn a completed ride back into an in progress one, undo a cancellation, or move a payment backwards. All mirrors now go through a protected merge: completed and cancelled are terminal, status and payment never move backwards, and ratings, tips and chat are never unwritten.
• Refused writes. A permission or network failure in the rider app used to become an unhandled promise rejection and silently skipped the stored trip update. Both stages are now handled, the app carries on, and the failure is logged as a warning.
• Misleading accept message. A driver tapping Accept again on a ride they already have was told another driver had taken it. That is now treated as what it is: a no-op on their own ride.

Real time driver location on the rider map

The Driver app's device GPS was already working and already publishing. The Rider app was reading the wrong copy of it.

What the Driver app does (unchanged): navigator.geolocation.watchPosition with high accuracy, started when the driver goes online and when a ride is accepted, stopped when the driver goes offline with no ride, logs out or is locked. Every fix writes to four places:

• drivers/driver_location in the driver login project, the original legacy node, still written;
• drivers/{uid}/location in the driver login project;
• driver_locations/{driverId} in the canonical project, every fix, unthrottled;
• active_trip_request.driverLocation and trips/{tripId}.driverLocation, at most once every three seconds to keep the write rate sane.

The mismatch: the Rider app only ever read the last of those, the throttled copy carried on the trip record. So the car could move at best once every three seconds, only when the whole trip record changed, and it froze completely if that one write was skipped. The live per driver feed that the Driver app was already publishing was not being read by anyone except the Admin dashboard.

The fix: the Rider app now subscribes to driver_locations/{driverId} for the driver assigned to its own trip, so the car moves as the driver moves. Details:

• The driver id comes from trip.driverId on the rider's own trips/{tripId}. A fix is only used when it belongs to that driver, and when the trip stamped on it matches. A rider can never follow another driver, another rider's ride or an old trip.
• The live feed is now stamped with tripId, tripStatus, vehicle and plate, so the rider can verify the car it is watching, and the feed is marked offline when the driver goes offline or the tab closes.
• Following starts when a driver is assigned and stops on COMPLETED and CANCELLED, using the existing status values.
• The copy on the trip record is kept as a fallback, so a rider still sees the car if the per driver node cannot be read.
• The rider map now shows 📍 pickup, 🚗 the driver and 🏁 the destination. The map moves to the car ONCE, when it first appears; after that the marker moves and the map does not, so panning and zooming stay under the rider's control.
• A line under the trip status says how fresh the position is ("Driver location: live", "8 seconds ago"), and an old fix turns the car grey rather than pretending it is current.
• The Rider app never asks for the rider's own location, so there is no second permission prompt, and the Driver app still runs exactly one watchPosition watcher no matter how often it goes online or accepts.

Rider payment information

The payment data was always being written. Nothing in the Rider app ever displayed it: the rider only saw the fare estimate before the ride and the tip window at the end. Traced end to end, the money for a ride lives in one place, trips/{tripId} in the canonical project, mirrored on active_trip_request while the ride runs:

What was added, all reading that same record:

• A Payment Information section in the Rider app showing trip fare, tip, final fare, method, status, reference, the time of the last payment update and the attempt count. It appears as soon as a ride is requested and updates itself whenever the Driver, Admin or the payment system changes the trip. No refresh.
• The same summary inside the existing Trip Complete popup, added above the tip buttons. The stars, the tip grid and the Submit button are untouched.
• Card details are never shown. Anything that looks like a card number is reduced to its last four digits and any security code is stripped, so a stored value like "Visa 4111111111111111" displays as "Visa •••• 1111".
• FAILED joins the existing status list (PENDING, AUTHORIZED, CHARGED, CASH_DUE, PAID). No competing status system was introduced.
• A Retry Payment button that appears only when the payment actually failed. It runs against the same trip and the same payment reference inside a transaction, so it cannot create a second trip, a second payment record or a second charge, and a second tap after a successful retry does nothing.
• The payment section stays visible after the ride is cleared, reading the stored trip, so the rider can still see what they paid for their last ride.

Road distance and road time, from the routers already in the project

Two road routing services were already configured here, and both are now used for what they are good at. Nothing new was added, no API key, nothing paid.

• Google Directions, already loaded by the Rider app, prices the ride. It resolves the typed addresses itself, so a quote can be produced before the map has drawn anything.
• OSRM, already used by the Driver app through Leaflet Routing Machine, is the fallback for the quote and is what works out the driver's road distance and ETA to the pickup. Nominatim, also already used by the Driver app, turns an address into coordinates when only OSRM is available.

The rider quote is now priced only from a road route. Straight line distance and average speed guesses are not used for it at all. If neither router answers, the ride is not created and the rider is told to check the addresses: better than the old behaviour, which quietly used 5 miles, 10 minutes and $18.50.

The driver's pickup distance and ETA are now real. The request card used to read "~5 mins (1.8 miles)" because nothing ever wrote pickupDistance or pickupEta. The road route is worked out from the driver's current GPS to the rider's pickup, shown on the request card, refreshed as the driver gets closer, and saved to the trip once the driver owns it so the rider and Admin see the same numbers.

Estimated and actual stay apart on the one trip record: estimatedRoadMiles and estimatedRoadMinutes from the road route before the ride, actualTripMiles and actualTripMinutes from the driver's GPS and the clock afterwards, alongside the existing fields. The fare formula was not touched.

Upfront pricing, quoted from the road route

What was wrong with the fare. The request carried miles: document.getElementById('miles').value || 5, minutes: ... || 10 and a fare of "$18.50" whenever the fare box still showed $0.00. So any ride where the route lookup did not answer, which is every ride if the map key is restricted or billing is off, was quoted at $18.50 for 5 miles and 10 minutes, whatever the real trip was.

What it does now. The rider is quoted before the ride from the expected ROAD ROUTE, using the pricing table Admin already controls. No second pricing system: the arithmetic is the one the Rider app has always used, base plus distance plus time, floored at the minimum, plus the booking fee, times the period multiplier, with an airport flat rate replacing all of it.

• The route comes from the map's road route when it answers. When it does not, the road distance is estimated from the pickup and dropoff coordinates with a road factor and a speed band, and the trip records routeSource: "estimated" so nobody mistakes it for a real route. The silent 5 miles, 10 minutes and $18.50 are gone.
• The rider sees the price itemised before requesting: base fare, distance, time, minimum if it applies, booking fee, multiplier, and the upfront price, with a line saying the price is fixed and the driver's GPS records the actual distance and time separately.
• The whole quote is saved on trips/{tripId} as fareQuote, with quotedFare, quotedMiles, quotedMinutes and routeSource.
• When the ride finishes, the driver's GPS distance and clock time are stored separately, as before, and the fare the meter WOULD have produced is recorded as meteredFare with the difference in fareVarianceAmount and fareVariancePercent. The rider is charged the price they were quoted. Admin shows the meter underneath the estimate so you can see how the two compare before deciding whether to change anything.
• If no pricing table has been saved yet, the same starting rates the apps already carried are used, so a quote is never missing. Whatever Admin saves under pricing always wins.

For the reported trip, Riviera Beach to Fort Lauderdale airport with no route service answering, the quote is $74.26 for an estimated 60.97 miles and 73 minutes, against the old $18.50.

Why a 57 mile drive still read 4.2 miles

The first version of the odometer only ran between Start Trip and Complete Trip. Two things followed from that, and both produced the old placeholder numbers:

• If the driver never pressed Start Trip, and the app allows going straight from arrived to completed, nothing was ever measured and no startedAt was recorded. The trip card then fell back to its built in "4.2 mi" and "12 mins", which is exactly the pair being reported.
• Between accepting and starting, nothing was tracked at all, so the first part of the drive existed nowhere.

Tracking now runs for the whole time the driver owns the ride, from the moment they accept. The single track is marked at arrival and at Start Trip, so it splits into the drive to the rider and the ride itself without a second GPS system. The ride is measured from Start Trip when it is pressed, and from the arrival when it is not, so a forgetful driver still produces a real distance. If startedAt is missing at completion it is filled in from the arrival time and the record says startedAtEstimated, so the duration is real rather than zero.

The trip card is also refreshed every second from the live measurement, in every stage of the ride, so the app's own placeholders can never be what the driver reads.

Measured, not displayed. The engine is checked against the reported trip: Riviera Beach to Fort Lauderdale airport, a road route of 57.45 miles where the straight line between the two addresses is 48.78. Fed a realistic GPS trace of that drive, the odometer reports 57.45 miles, an error of 0.00%. A ten mile leg reports ten miles. Nothing was hard coded to display 57: the same code measures whatever is driven.

Real mileage and real trip time

What was wrong. Nothing in any of the apps ever measured how far a car drove. The driver screen read activeTrip.tripMiles || "4.2 mi" and activeTrip.tripDuration || "12 mins", and nothing anywhere wrote tripMiles or tripDuration. So every trip displayed those two constants. The only distance in the system was the route estimate the rider's map produced before the ride, which is not the distance driven, and no duration was calculated at all.

Mileage. While a ride is in progress the driver app now accumulates real distance between consecutive GPS fixes using the haversine formula, on the same fixes the live map already publishes. No second GPS system was created. Bad data is filtered: movements under 6 m are jitter, fixes accurate to worse than 100 m are not measured with, and anything implying more than about 139 mph is rejected. A long gap counts the straight line rather than losing the distance. Two impossible steps in a row re-anchor the odometer, so one bad fix, or a stale position left over from before the ride, cannot wedge it at zero for the whole trip.

Time. startedAt is stamped when the driver presses Start Trip and completedAt when they end it, and the duration is completedAt - startedAt. GPS frequency cannot shorten it: a twenty minute ride reads twenty minutes even if only three fixes arrived.

Both are saved to the canonical trips/{tripId} record as distanceMeters, tripMiles, tripMilesValue, tripDurationSeconds, tripDurationMinutes and tripDuration, with the GPS fix counts kept for auditing. The driver sees them live on the trip card and again on the completion summary, the rider sees them on the payment card, and Admin shows them on the live ride and in each rider's trip table.

Double clicking the wrong file

The package contains two files that both look like the Admin app. Only one of them can be opened by double clicking, and the other one failed silently, which is indistinguishable from a broken login.

• admin.html inside admin-package/ now shows a red banner when it is opened as a local file: it explains that a browser will not load the app's shared code that way, names admin-standalone.html as the file that does work, and gives the local server as the alternative. The banner is a plain script, not a module, so it still appears when the modules are blocked, which is exactly when it is needed.
• admin-standalone.html now reports its own state as soon as it opens, with no button press: build, whether it was opened as a local file, whether the shared code loaded, whether the email is on the admin list, and whether each Firebase project can be reached.
• A page opened as a local file often has no usable browser storage, and the Firebase SDK keeps the session there. The session is now held in memory on a file:// page, so storage restrictions cannot block a sign in.

Telling you why a login failed

The Admin login card has a Run connection test button. It reports the build that is loaded, whether the page was opened as a local file or over http, whether the shared code loaded, whether the email is on the admin list, whether each Firebase project can actually be reached, what the last sign in attempt returned from each project, and whether the browser thinks it is online. One press answers "why can I not log in" without another round trip.

Running Admin on your own computer

Copying admin.html to a computer and opening it did not work, for two reasons.

• admin.html is not the whole app. It imports shared/rideshare-sync.v1.js (the trip, fare, payment and merge rules) and shared/firebase-canonical.v1.js (which Firebase project is which). One file leaves those behind.
• Browsers refuse to load ES modules from a file:// page. Even with the shared folder beside it, a double click produces "blocked by CORS policy: Cross origin requests are only supported for protocol schemes". That is a browser security rule, confirmed by loading the real file in a real browser.

So there is now a download page with two forms of the same working app: admin-standalone.html, one file that opens by double click because the shared code is inlined and no local import remains, and riders-admin-package.zip, the normal layout with the shared folder and a one command local server. The Firebase configuration, both projects, the login and every feature are the working code, copied as is.

No cash on the rider screen, even on an old trip

Trips taken before the card only change still carry paymentMethod: "Cash" in the database, and the Rider app was faithfully printing it. A rider should not be shown a payment type they can no longer use, so:

• The Rider app never renders Cash. Where a stored trip says cash or nothing, it shows the card on the account, or "Credit or debit card" when there is none. That is a display decision: the stored record is not touched.
• Admin has a Convert Cash Trips to Card button next to the trip history controls, for when you want the data itself cleaned up. It rewrites the method to the rider's card, keeps the old value in paymentMethodBefore, moves a CASH_DUE status to CHARGED with paymentStatusBefore recorded, and leaves fares, references and everything else alone. Nothing is deleted, and running it twice changes nothing the second time.

Card only, and the driver never handles money

Riders pay by credit or debit card. Cash is gone from the Rider app, and the driver is never asked to collect anything.

Rider app

• The payment list no longer offers cash. It shows the card on the account, and nothing else.
• A ride cannot be requested without a card. Asking for one without a card says: "Add a credit or debit card before requesting a ride. Cash is not accepted", opens the card box and scrolls to it.
• Choosing a category is not the same as having a card: "Credit Card" as a preference does not open the gate, an actual card reference does.
• A new Card on file box adds or updates the card. Only the brand and the last four digits are stored. The number and the security code never reach the database, and the number is wiped from the form as soon as it is read. With a Stripe publishable key configured, Stripe's own field is mounted and the card never touches this site at all.
• No trip can be created as cash: even if an old value were still lying in the browser, it is replaced by the card.
• The rider still sees the total fare and the payment status throughout, and everything still lands on trips/{tripId}.
• Nothing is faked. A card saved without a payment provider reads pending, not paid. The states stay PENDING, AUTHORIZED, CHARGED, PAID, and only a real processor can honestly move the last step.

Driver app

• The cash collection prompt is gone. No "did you collect $XX from the rider".
• Completing a trip now shows a driver summary: Trip Completed, rider, trip id, pickup, destination, distance and time when known, payment status, and the driver's own earnings as the headline figure.
• The rider's fare is never presented as the driver's money. A $55.00 fare shows the driver $22.00 as earnings with a separate line reading "Rider fare $55.00. Your share is 40% of the fare." The calculation is the one the app already used, untouched.

Trip record

driverEarnings now sits next to driverPayout, carrying the same number under the name the dashboards ask for. Payment state still only moves forward, and a card trip that has been charged or paid can never fall back to a cash state, even from a stale mirror. Older cash trips still read and settle exactly as they always did: history is not rewritten.

The stuck ride, the wrong payment status and the zero total

Three symptoms, three separate causes, none of them a Firebase project mismatch. Rider, Driver and Admin all read the ride data from driver-pro-card-login, and Admin additionally reads registrations from rider-s-drivers-info. That part was correct.

"Another ride is active right now"

active_trip_request is a single shared node. If a tab closes mid ride, or a ride is finished only in the trip record, the pointer is left aiming at a ride that is over, and then nobody can book. Forever. The stored trip is the authority now: a pointer to a finished ride is released, and a request with no driver that has been sitting for more than half an hour is treated as abandoned, marked cancelled in history and released. A genuine ride in progress still blocks, and the rider is told which ride, what state it is in, which driver has it and how long it has been running.

Admin said PENDING while the Rider app said AUTHORIZED

Both were reading the correct field on the correct record. They were reading different rides: Admin quoted the newest trip by timestamp, the Rider app showed the ride that device was on. Admin now quotes the ride that is happening now when there is one, names the trip id beside the status, and marks it as a live ride. With nothing running it falls back to the newest finished ride, as before.

Trips: 2 / $0.00

The riders table showed only money that had settled, and neither of that rider's rides had completed. It now reads "2 rides, $50.90 in fares" with the settled amount beneath, so a fare is never invisible just because the ride has not closed out yet.

Payment Method: Not specified

That rider record carries no card because it is the record the Rider app creates on the device, not the registration record that holds the card. Where the account has no card but the rider's rides do, Admin now shows the method used on the ride and says plainly that it came from a ride rather than from the account.

Fares in the Rider Information view

The payment summary only added up rides that had finished, so a rider with two rides still running read $0.00 for everything and looked as though the fare was missing. It now separates what is settled from what is not:

• Total Fares (all trips), every ride whatever its state;
• Total Paid (completed) and tips, as before;
• Not settled yet (in progress), the fares of rides still running;
• Last Trip Fare with the status of that ride;
• and, once rides have completed, what those rides produced: 40% plus tips to drivers, 60% to the company.

In the trip table inside the view, a ride that has not finished now shows its fare marked "not settled" instead of a bare $0.00 in the Final Fare column.

Who and how much, in both trip tables

Live Active Rides & Trip Requests and Ride Request & Trip History now carry, for every ride: the rider name with the rider id underneath, the driver name with the driver id (and plate) underneath, and the fare split into three columns.

• Fare, the amount for the ride, with any tip shown beneath it;
• Driver 40%, and when a tip exists, the driver's total with the tip added;
• Company 60% for Rider's Transporters.

A $32.40 fare reads $12.96 to the driver and $19.44 to the company, and the two always add back to the fare. Tips sit on top and go entirely to the driver, so they never reduce the company share. These are the same numbers the Driver app pays out and the dashboard totals already used, now from one shared calculation rather than three copies of the arithmetic.

Payment method on the rider record, ready for Stripe

The registration page always wrote safe card metadata, and it never wrote a card number, a security code or an expiry date. Those stay in the form and are thrown away. What was missing was one agreed shape, so the rider record now carries:

riders/{uid}
  savedCard             "Visa \u2022\u2022\u2022\u2022 4242"
  paymentMethodType     "card"
  paymentMethodLabel    "Credit/Debit Card"
  paymentMethodStatus   "pending"  (no provider yet)  or  "ready"  (Stripe holds it)
  paymentMethodId       ""  or  "pm_..."
  paymentMethodAddedAt  timestamp
  cardBrand, cardLast4  kept, nothing was removed

Admin reads that shape whatever wrote the record, shows the Stripe id and marks a Stripe backed method as ready. When a rider row has no card at all it now says which fields it looked for and which source the row came from, instead of leaving "None saved at registration" hanging.

How Stripe drops in

shared/stripe-config.v1.js holds one value, the publishable key. Paste it there and the registration page loads Stripe.js, mounts Stripe's own card field, hides its own card inputs (they stay in the page), and turns the card into a PaymentMethod. The card is typed into an iframe served by Stripe and never touches this site. Firebase then stores only the brand, the last four, the pm_ id and a status.

Leave the key empty and nothing changes: the current form keeps working and keeps storing only brand and last four.

The secret key never goes in this repository. Creating a PaymentMethod needs only the publishable key. Charging it, refunding and paying drivers need the secret key and must run on a server. The trip record is already shaped for that: PENDING, AUTHORIZED, CHARGED, PAID, one payment reference per trip.

Locked out of a login

Both login screens can now get you back in without anyone deleting or recreating a Firebase account:

• Send password reset email on the Admin card and the Driver card. It asks Firebase for a reset in both projects and reports which ones accepted it.
• The failure message now shows the most useful error rather than simply the last one. "Wrong password" from one project no longer hides "email and password sign in is switched off" or "too many attempts" from the other.
• The Admin login card shows which build is loaded, so a stale cached page can be spotted at a glance instead of being mistaken for a broken login.

The floating trip messenger

A 💬 button now sits in the top right corner of the Rider app and the Driver app. It stays hidden until a driver accepts the ride, then it appears with an unread badge, and it opens a popup messenger for that trip.

• Same conversation on both sides. The messages live where they already lived, on the canonical trip record at trips/{tripId}/messages, mirrored on the live trip pointer. Nothing was moved and no second chat system was created.
• Real time in both directions through Firebase listeners: the popup reads trips/{tripId}/messages directly as well as the copy on the live pointer, and merges them. No refresh, no polling, no copying HTML between boxes, no localStorage as the message store.
• Every message carries a stable mid, plus sender, senderId, senderName, text and a timestamp. The same message arriving from two listeners is shown once, and two identical lines sent in the same millisecond stay two separate messages. De-duplication never clears the chat.
• The header shows who you are talking to and the trip reference. The X closes the popup only: the trip, the listeners and the conversation carry on, and anything that arrives while it is closed raises the unread badge.
• The chat card that was already on both pages is untouched and shows the same conversation.

Every place a rider can exist

The rider panel now collects riders from four sources and merges them, richest record first:

1. riders/{uid} in the registration project, written by the registration page;
2. riders/{riderId} in the canonical project, written by the Rider app;
3. users/{uid} with role: "Rider", in either project, which the registration page also writes;
4. riders rebuilt from the trips they took.

The note under the table now names each source with its count, or NOT READABLE and the Firebase error code when the rules refuse a read. adminRiderSources() in the browser console returns the same thing as data. An empty panel can now be explained in one glance instead of guessed at.

The registration app writes to the other project

The registration page (registrationlogin.html) creates the Firebase Authentication account and then writes riders/{uid}, drivers/{uid} and users/{uid} into rider-s-drivers-info. The Admin dashboard was reading riders from driver-pro-card-login only. Drivers appeared because the driver list was already merged across both projects; riders were not. That is the whole reason the Registered Passengers table stayed empty while people were registering.

Admin now listens to riders in the registration project as well and merges three sources: registered riders, the records the Rider app saves, and riders rebuilt from the trips they took. The note under the table counts each source.

The registration record also carries safe card metadata, which is now shown: cardBrand, cardLast4, paymentMethodType, paymentMethodStatus, paymentMethodId and paymentMethodAddedAt. The registration page deliberately does not store the card number or the security code, and Admin displays only the brand and the last four digits.

One thing to fix in the registration page: it also writes the rider's and driver's password into the database in plain text. Admin never displays it and warns when it finds one, but it should not be there at all: the Firebase Authentication account is what signs people in, so that field is redundant.

Why the rider panel looked empty

The panel was correct, the data was not there. Two causes, and the old code could not tell them apart:

• The rider record was written with a transaction. A Firebase transaction has to READ the node before it writes it. If the rules let the Rider app write riders/{riderId} but not read it, the write failed and no rider ever appeared. The save now falls back to a plain update, which needs no read, and the Rider app says on the page when even that is refused.
• Admin had no error handler on the riders listener. A read refused by the rules left the list empty and printed "No riders registered yet", which reads exactly like "nobody has signed up". The listener now reports the real Firebase error under the table.

On top of that, the passenger list no longer depends on the riders node existing at all. Every trip carries riderId and riderName, so Admin rebuilds the list from ride history and merges the saved profiles on top when they are readable. A rider who has taken a trip is always listed, with their trips, fares and payments, and the note under the table says which source the rows came from.

Rider information and payments in Admin

What the rider record already holds. One writer, one path: the Rider app writes riders/{riderId} in the canonical project with riderId, fullName, email, phone, createdAt, lastSeen and source. The rider id is generated on the device and kept, so it survives page loads. Admin was already listening to that exact path, so there was no database mismatch to fix: the data was simply thin, and the dashboard only showed four columns of it.

What the payment system holds. There is no payment provider connected, so there is no card brand field, no last4 field, no payment method id and no processor transaction id. What exists per trip is paymentMethod (the label the rider chose), paymentStatus, paymentReference (derived from the tripId), paymentUpdatedAt, estimatedFare, finalFare, tipAmount and, after a failure, paymentAttempts. Reporting that is the honest answer: no card storage was invented to fill the gap.

Added to Admin, reading those same records:

• The riders table gained Rider ID, Trips and total spent, the payment state of the last ride, and Account Status, alongside the name, email, phone and joined date that were already there.
• A Rider Information view: profile, registration date, last seen, account status, a payment summary (trips, completed, cancelled, total paid, tips, last payment), and a table of that rider's trips with trip id, date, pickup, destination, driver, status, estimated fare, final fare including tip, payment method, payment status and the payment reference with its timestamp.
• Trips are matched by an exact riderId comparison and nothing else, so one rider's payment information can never appear under another rider. A trip with no rider id belongs to nobody.
• Cards are shown as brand and last four only, read out of the stored label for display. Full numbers and security codes are never stored and cannot be rendered: the masking runs before anything reaches the screen.
• The open rider view follows the existing realtime listeners, so a payment moving to PAID updates it with no refresh, using the existing status values.

The Rider app also gained a small My Details box (name, email, phone) that writes into the same riders/{riderId} record, because nothing in the apps ever collected an email or a phone number. It merges, so a blank field never wipes something already stored, and no second rider record is created.

The missing driver profile

A Firebase Authentication account and a database record are two different things. Creating the user, in the Firebase console or anywhere else, does not create drivers/{uid}. Nothing in these three apps ever created it: every drivers/{uid} write in the whole project is an update() for approval, presence or GPS that assumes the record already exists. There has never been a registration flow in the Rider, Driver or Admin file, only error messages that mention one. That is why a driver can sign in successfully and still be told there is no profile.

Added, without deleting or resetting anything:

• When a sign in succeeds and no profile exists, the Driver app now shows a Complete your driver profile panel on the login screen. It writes exactly one record, drivers/{auth.currentUser.uid}, in the project the driver signed in to, with name, email from the account, phone, vehicle and plate, marked approved: false and Pending Approval. The administrator approves it as usual.
• The write is a transaction that MERGES: if anything already exists under that key, including an approval decision or presence data, it is kept and only the empty fields are filled.
• If a profile already exists somewhere else for the same email, under a push key for example, it is copied onto the Firebase UID with its approval intact, and the original record is left in place and marked supersededBy, so the Admin list shows the driver once rather than twice. Nothing is deleted.
• The panel reports exactly what was checked in both projects, so "the record is not there" is never confused with "the database rules would not let me read it".
• Sensitive fields stay where they are. Only name, email, phone, vehicle, plate, approval and presence are mirrored into the canonical project for the Admin dashboard.

Run driverProfileDiagnostics() in the browser console on the Driver app, after signing in, for a straight answer about the live database: the account, the UID, which project holds the session, whether the profile exists, every path that was checked with found, absent or denied, and any other record carrying the same email.

Driver sign in

Same shape as the admin problem. The Driver app signs in against rider-s-drivers-info and nowhere else, so a driver whose Firebase account was created in driver-pro-card-login could never get past the login screen, whatever they typed. What changed:

• Sign in is tried in both projects, the driver login project first, then the canonical project. The account only has to exist in one of them, and the login card says which one let the driver in.
• The driver profile is looked for in both projects too. When both hold a record, the real registration record wins over the stub that an approve or suspend click leaves behind, so names, vehicles and documents are never lost.
• Approval is read from both records: suspended anywhere means suspended, approved anywhere means approved.
• Everything the driver does afterwards, going online, GPS, accepting, chat, status changes, now accepts a session from either project. The original checks are still there and still run.
• The login card now says exactly what went wrong: which projects were tried and the Firebase error code, or that the credentials were fine but no drivers/{uid} profile exists, naming the exact record to create, or that the account is waiting for approval, or suspended.
• Logging out clears both projects.

Run driverSyncStatus() in the browser console on the Driver app to see the signed in account, which project holds the session, where the profile was found, the approval state, the current trip and the last GPS fix.

Admin sign in

The Admin dashboard used to sign in against one project only: driver-pro-card-login. If the admin user was created in rider-s-drivers-info instead, the login could never succeed, and the only feedback was a bare "Login failed" box. Two changes:

• The login is now tried in BOTH projects, canonical first, then the driver login project. The admin account only has to exist in one of them. The dashboard still reads and writes ride data in the canonical project, and it says on screen which project signed you in.
• Failures now say what actually happened: which projects were tried and the Firebase error code, including the common one where email and password sign in is switched off in that project.

The authorized address is still driverandridersapp@gmail.com. Typing anything else says so instead of failing silently. If a second admin address is needed, it goes in the ADMIN_EMAILS list in the Admin app.

What to check on the live databases

• The canonical realtime database rules must allow the Rider app to read and write trips, active_trip_request, riders, support_chats, drivers and driver_locations. That is how the apps already worked.
• A driver appears in Admin as soon as they sign in to the Driver app once. If you also want drivers who have never opened the app, the driver login project has to allow the Admin dashboard to read drivers. If it does not, the dashboard says so in a note under the driver table and carries on.

Back to the app launcher