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.