Identity and access
Every account is rooted in a verified phone number. Registration and sign-in start with an SMS one-time code; codes carry a short expiry and failed attempts are counted and capped, so a code cannot be brute-forced. Once an account exists, stronger or more convenient methods can be added on top of it — a password, email one-time codes, passkeys, and Continue with Google or Apple, including native Sign in with Apple on iOS.
Passkeys are enrolled on an already-authenticated account and bound to your domain's WebAuthn relying-party ID, so a credential issued for one operator cannot be replayed against another.
Roles are scoped per service using separate permission sets — taxi, shop, parking, services, analytics, tenant settings, and core user management are each their own grant. A regional support agent can be given ride visibility without financial reconciliation, and a marketplace operator cannot touch platform infrastructure settings.
Destructive actions require step-up authentication. Ownership transfer, API key management, and account deletion each demand a freshly minted, single-use elevation token on top of a valid session, so a stolen session alone is not enough. Sessions are listable and individually revocable, and a password reset revokes every active session on the account.
Data and encryption
Traffic is served over TLS. Payment provider credentials — API keys, client secrets, and webhook signing secrets — are encrypted with AES-256-GCM under a fresh random nonce before they reach the database, and are decrypted only inside the process that needs to call the provider. They are never returned to a client: the API exposes credential schemas and capability status, never the secret itself.
Phone numbers and email addresses are masked wherever they would otherwise land in logs. The masking is one-way and fail-closed — only the last two digits of a number, or the first character and the domain of an address, survive — so a streamed or leaked log line never carries a full contact detail.
Sensitive operations write to audit tables retaining the actor, origin metadata, and a structured event payload. Tenant configuration changes, API key issue and revocation, release actions, and content edits each keep their own trail.
Production discipline
Reliability is a product feature. Every service emits structured logs, traces, and metrics, and a built-in dashboard surfaces system health to operators in real time. Releases are versioned with a dated scheme, and every database migration ships with its own rollback script, so reversing a release is a known path rather than an improvisation.
Was this article helpful?
