How we built the DEV3 Kerbora: ride hailing with shared test vectors and one lock order

DEV3 Kerbora is a self-hosted ride hailing platform with an admin panel, a dispatch panel with a live map and two Flutter apps, one for passengers and one for drivers.

Stack: Laravel 12, Filament 4 (/admin, /dispatch), a public site, signed trip-share links, a REST API and Flutter.

Decisions that mattered

• The match engine, fare maths, cancel maths, trip split, surge and GPS filter are pure PHP classes. Their test vectors live in JSON that the Dart ports in the apps also run, so server and apps agree to the cent.
• Every entry point goes through one trip engine that locks the trip, then its offers, then drivers in ascending id order, with wallets last. Overdue deadlines are applied lazily before acting, and the scheduled tick only catches idle trips.
• Offer expiry uses whole seconds, so an accept at exactly the expiry second wins.
• Cash-out locks the wallet row itself because a driver earnings wallet may go negative and a hold alone would not stop a double cash-out.
• Card money is applied only when the payment-succeeded event arrives.

Limits: stored-card charging is simulated, and there is no public live demo.

Known gap: there is no pre-authorisation because the shared core has none.

Tell us how you would test dispatch fairness. Questions welcome.