Security
How LuxeRide protects operator and passenger data: row-level security on every table, an immutable audit trail, and automated compliance enforcement.
Every operator on LuxeRide shares the same application, so passenger and booking data from one company must never be reachable by another, not just hidden by the interface.
A dispatch decision, a cancellation, or a driver reassignment needs a record of who did it and why, not just the current state after the fact.
A driver with an expired license or a vehicle with lapsed insurance is a liability the moment it happens, not something an operator should have to remember to check.
Every multi-tenant table runs PostgreSQL row-level security, enforced by the database itself. An operator’s data is unreachable from another operator’s account at the database layer, not only hidden by application code.
Booking events (cancellation, reassignment, driver rejection, incident report) are written to an event log with actor, type and reason, so any trip’s history can be reconstructed.
Driver and vehicle compliance (license, insurance, registration expirations) is checked automatically, and dispatch is blocked for anyone or anything out of date, not left to manual tracking.
The concrete mechanisms, not a policy statement.
PostgreSQL RLS policies enforce data isolation at the database layer across the schema, not just in application code.
Online payments run through Stripe Connect or Whop. LuxeRide never stores card numbers.
Every cancellation, reassignment, rejection and incident is written to an audit trail with actor, type and reason.
Expired driver licenses, insurance or vehicle registration automatically block dispatch until the document is renewed.
Booking creation and other public-facing actions are rate-limited to prevent abuse.
Core services are checked continuously, with an alert sent the moment something degrades.
From an expiring document to a blocked dispatch.
Driver license, insurance and vehicle registration dates are tracked per record.
Automated checks flag documents approaching expiration.
A driver or vehicle with an expired document cannot be assigned a trip until it is renewed.
An operator’s booking, pricing and passenger data cannot be reached from another operator’s account, enforced by the database.
A driver or vehicle out of compliance is blocked from dispatch automatically, not caught after an incident.
An immutable event log means a cancellation or reassignment can be traced to who did it, when, and why.
Row-level security applies at the database layer to every table, every query, automatically.
Card data is handled by Stripe’s or Whop’s own infrastructure, not stored or processed on LuxeRide servers.
Not after a driver with an expired license already picked up a passenger.
Automated checks run continuously against core services.
No. PostgreSQL row-level security policies enforce data isolation at the database layer for every multi-tenant table, not just in the application interface.
No. Online card payments are processed by Stripe Connect or Whop, whichever the operator has active. LuxeRide never stores card numbers on its own servers.
The compliance engine flags it automatically, and dispatch is blocked for that driver until a valid license is on file.
Yes. Every reassignment, cancellation, driver rejection and incident report is written to an event log with who acted, what happened, and why.
Related pages
See the compliance engine and dispatch board in your own account.
Start free trial