Security

How we protect
merchants & travelers.

A marketplace that moves money and knows where people are driving owes both sides real answers about security. Here they are: the actual boundaries the platform is built on, not a badge wall.

The boundaries

Four walls, each enforced in code.

Security here isn’t a policy document. It’s where the system physically refuses to do the wrong thing.

Traveler ↔ platform

Hardened sign-in, isolated data

Sessions use server-generated random tokens and passwords hashed with scrypt, never stored in the clear. In production, authentication rides on signed JWTs with Postgres row-level security, so every table access is checked server-side, row by row.

Merchant ↔ platform

Deny-by-default merchant access

The merchant console is role-based (owner, manager, viewer, admin) and denies by default. Merchants are scoped strictly to their own resources: anything that isn't yours doesn't error, it simply doesn't exist. Admin routes reject non-admin credentials. Both behaviors are covered by tests.

Merchant ↔ traveler

Travelers stay anonymous to merchants

No API returns a traveler's identity or location to a merchant. Matching happens entirely on our side, and merchants receive aggregate analytics only. In the database this is structural, not policy: no rule grants merchants access to traveler tables at all.

Payments

No card numbers, no float math

Raw card data never touches our systems. Payment is tokenized through Apple Pay and our payment provider. Money is handled as integer cents, never floating point. Orders carry idempotency keys so a retried request can't double-charge, and order state can only move through whitelisted transitions.

Discipline in the details

The habits behind the walls.

Boundaries hold because of the boring work around them: what gets logged, what never does, who’s verified, and what’s written down forever.

Payment features run in clearly-labeled sandbox mode until live payment credentials are provisioned. We never present a test surface as a live one.

  • Append-only audit log: every sensitive action (sessions, offer lifecycle, order decisions, moderation, flag changes) is appended to an audit log that can't be rewritten, and each order carries its full state history.
  • Verified merchants only: a listing goes live only after a verification lifecycle with proof of business identity. Misrepresentation is grounds for removal, and moderation actions are themselves audit-logged.
  • No key material in the codebase: configuration is environment-only, credential files are ignored by version control, and continuous integration runs secret scanning to catch anything that slips.
  • Logging redlines: payment credentials, auth tokens, precise location histories and voice audio are never written to logs. Observability uses IDs and coarse context only.
  • Fail-closed engineering: strict compile-time concurrency checking, transport security on by default, and versioned local stores that refuse data from unknown future schema versions rather than guessing.

Found a vulnerability? Tell us first.

We welcome responsible disclosure. Email us with steps to reproduce and we’ll respond to every legitimate report. Please give us a reasonable window to fix an issue before sharing it publicly, and don’t access data that isn’t yours while demonstrating one.

Email support@hitdahiway.com

Privacy commitments live in our privacy policy; merchant data terms in the merchant agreement.