What protects the money and the data
A page for those who assess the system technically: partners, integrators and owners comparing vendors. Point by point — how the protection works.
Access and keys
Passwords and PINs
Stored as irreversible hashes (Argon2id). A password cannot be recovered, only reset. Not even an administrator can read a PIN.
Secrets outside the code
External service credentials and database connection strings live in a server-side secrets store — not in the repository, not in client code.
Short-lived sessions
Access tokens last minutes; refresh tokens live in protected storage. Sessions are revoked on termination or role change.
Server-side permissions
Every action is checked on the server against a permission code. A hidden button in the UI is convenience, not protection.
Brute-force protection
Failed login and PIN attempts are counted, with temporary lockout.
Integration keys
One key, one venue. Another venue’s data is unreachable by design. Revocation is immediate.
Money and history
Immutable documents
A posted document is never edited. Corrections are reversals, and the history stays intact.
Hash-chained events
Each receipt event is linked to the previous one by a checksum, so a change to an earlier record would be detected.
Audit log
Who, what, when, before and after. The log is append-only.
Integer minor units
All amounts are stored in satang and rounded only for display, so errors do not accumulate.
Idempotent payments
Every payment carries its own key: a repeat never charges twice, including after an offline period.
Concurrent registers
One receipt cannot be closed by two registers, one stock balance cannot be deducted twice. Covered by automated tests.
Changes do not break a working venue
Updates are installed automatically under rules we developed from our own operating experience.
- A database backup is taken before every migration
- Migrations run against a copy of the production database first, production second
- Destructive changes ship in two releases: the code stops reading the column, and only a week later is it dropped
- Deployment is forbidden during lunch and dinner service — restarting in front of a guest is not acceptable
- After a release: scenario checks and log observation
- A rollback plan is written before the deploy, not after
How we enter your account
Some problems can only be diagnosed from inside the venue’s account. That is a separate mechanism, not “a shared password the developer keeps”.
- Support sign-in goes through a separate panel with its own account and a second factor
- Every entry is recorded: which support person, which venue, when
- What a support engineer does lands in the same audit log as your own staff’s actions
- Your employees’ passwords and PINs are not visible to us — they are stored as irreversible hashes
- Integration keys are shown once at issue; not even we can recover them
What happens when something fails
No internet
The register keeps selling and printing; sales are sent to the server automatically afterwards, without duplicates.
Printer down
Sales continue; the receipt reprints from the receipts screen, and the kitchen display covers the kitchen.
External service unavailable
The operation falls back to the manual path, a retry creates no duplicate, and the manager sees the failure.
Need detail for a technical review?
We answer integrator and partner security questions and walk through the system on demo access.