Security

Your data is yours alone

For us security is not a feature of one module but the posture of the company: decisions taken on day one of the architecture and never loosened since. Below we state plainly what we do — and where our limits are.

1 · Tenant Isolation

Every company's data in its own database

The most common mistake in multi-tenant systems is keeping all customers in the same table and separating them with a column. One forgotten filter there shows another company's data. We refuse to take that risk in the first place.

A separate database per company: your products, sales, stock, cash and customer accounts live in a database kept apart from other businesses.
Tenant identity only from the signed sign-in token: which company you belong to is resolved from the verified session token — never from the address bar, a header or the request body.
Belt and braces: even though the databases are already separate, a second tenant filter still sits in the query layer.
Per-company backups: backup and restore can be performed for a single business without touching its neighbours.

Connection details are stored encrypted

The connection details for company databases are stored encrypted in the central registry (AES-256-GCM). The decryption key is not kept inside the database; it is supplied from outside as an environment variable.

Even if the central registry leaked, connection details would not be in plain text.
The key is mandatory in production — start-up without it is refused.
Product, sales and cash data are never held in the central registry; they exist only in the company's own database.

2 · Identity and Sign-in

A password alone is not a door

Signing in to business software is opening the till. We build the identity layer accordingly.

🔑

Argon2id storage

Passwords are stored irreversibly with the memory-hard Argon2id algorithm. Plain text, MD5 and SHA are never used. The same computation is run even for a non-existent user, so response timing cannot reveal whether an email address is registered.

🕳️

Breached passwords rejected

When a new password is set it is checked against known breach lists and refused on a match. The check uses k-anonymity: the password itself, and even its full digest, never leaves our systems — only the first five characters of the digest are queried, and the comparison happens on our side.

🔐

Two-step verification

TOTP-based two-step verification with an authenticator app can be enabled on any account. Turning it off requires both the password and a current verification code, and revokes all other sessions — a stolen session cannot lift the protection on its own.

🎫

Short-lived session tokens

The access token is verified with an asymmetric signature (RS256) and expires in 15 minutes. The refresh token is stored server-side and rotated on every use; reuse of an old token is treated as a theft signal and revokes that entire session family.

🖥️

Session list and forced sign-out

A user can see their own active sessions (one entry per device/browser) with last-used and expiry times. An administrator with user-management permission can revoke all sessions of an account in one action — critical when someone leaves.

⏳

Attempt limits

Repeated wrong passwords lock the account temporarily, and at the two-step verification stage a challenge dies after a set number of wrong codes. Sign-in endpoints are additionally rate-limited.

The module gate

There is a second gate next to permissions: a request belonging to a module the business has not enabled is refused on the server even if you hold the permission. A disabled module is not merely hidden from the menu.

The check happens on the request pipeline, not in the interface.
Every command and query declares the permission it requires.
For a record you may not see, the answer is “not found” rather than “not permitted” — existence is not leaked.

3 · Authorisation

Permissions live on the server, not the screen

Hiding a button is not security: the interface runs on the user's device and can be modified. Here the permission check runs on a shared pipeline right before the code that does the work — a feature is never left to “remember” it.

Role-based permissions: cashier, waiter, courier, manager and owner operate with different permission sets.
A check at every endpoint: the same operation passes through the same gate whether it is called from another screen or directly.
Exceptions can require approval: sensitive actions such as comps, voids and refunds require manager permission and are written to the audit trail.

4 · Audit Trail

A record that cannot be altered afterwards

An audit record is only evidence if it cannot be changed later. That is why our logs only accept inserts — nothing is overwritten or deleted.

A hash chain in the business log

The business audit log in your own company database records who changed which record, when, and with which before and after values. Every row carries the cryptographic digest of the previous one — the rows are chained together.

If a row is later modified, deleted, or a row is inserted in between, the chain breaks and this surfaces as soon as the calculation is re-run. The owner can run that verification from the console; the result reports the first point where the chain breaks.

System and session log — a scope difference

Sign-ins, two-step verification events and administrative actions are kept in a separate system/session log. That log also contains the IP address and device/browser information at the time of the action, retained to detect unauthorised access and to serve as evidence in disputes.

It is append-only as well (no updates, no deletes), but it carries no hash chain. The chain is specific to the business audit log in the company database — we do not generalise that claim.

5 · Payments

Your card details never sit with us

Subscription payments are taken on the secure payment page of iyzico, a licensed payment institution. Your card number, expiry date and security code never pass through Prefux servers and are not stored by Prefux.

The payment page opens on iyzico's side; card fields never exist in our application.
What we keep is the outcome of the payment: amount, date and a transaction reference.
When the payment notification arrives, the amount is verified against the pending transaction record we wrote beforehand.

Transport and infrastructure

Encrypted connections enforced: HSTS tells the browser to connect over HTTPS only.
Framing protection: the console cannot be embedded inside another site (against clickjacking).
Content-type and referrer policies are applied through hardened security headers.
Rate limiting is applied both per company and separately on sign-in endpoints.
Dependency scanning runs automatically on every change; a package with a known vulnerability breaks the build pipeline.

6 · Data Lifecycle

Deletion is not destruction; it is making data unidentifiable

Commercial and financial records cannot be deleted under the law. Personal data can be — and is. We do not confuse the two.

No hard delete: records are marked as deleted and automatically excluded from queries; history stays intact.
Account deletion means anonymisation: name, email, phone, password and two-step verification details are irreversibly cleared; commercial records remain but can no longer be linked to you.
We wrote it out item by item: which data is erased, which is retained, for how long, and why — set out on a dedicated page.
Correction discipline: an incorrect line in stock and cash records is never deleted; it is corrected with a counter-entry, and both records stay visible.

Account Deletion and Data Retention

Let us answer your security questions

If you are running a corporate assessment or want the detail behind any point above, write to us and we will explain exactly how it works.