Security

One business can never see another

Every record carries the business it belongs to, and the database itself refuses to return rows from any other business. The rule lives in PostgreSQL, not only in our code. An application query that forgets to filter returns nothing, rather than someone else’s ledger.

Rekoda connects as a role that is not the table owner and cannot switch that rule off. We test this the only way it can honestly be tested: two businesses sharing one database connection, checking that neither sees the other.

We cannot read your codes or your keys

There is no password to steal, because Rekoda has none. You sign in with a code sent to your WhatsApp number. That code is never stored, only a keyed hash of it, using a secret held outside the database, so a copy of the database alone will not reveal a working code.

Session tokens are stored the same way. Payment provider keys are encrypted before they are written down, and are never logged, echoed back, or shown in the dashboard.

Rekoda never holds your money

Payments go to your own Paystack account, settling to your own bank account. Rekoda reads what happened so it can build your records; it is never a step the money passes through. If Rekoda disappeared tomorrow, your money would be unaffected.

Records are added to, not rewritten

The ledger, stock movements and the audit trail are append-only. The application is not permitted to update or delete them, and that permission is withheld by the database. A correction is recorded as a correction, so the history of a figure stays readable.

Backups and recovery

Continuous archiving lets us restore to a point in time, rather than to whenever the last nightly dump happened. Restores are rehearsed rather than assumed, and the rehearsal checks that the restored ledger still balances.

Reporting a vulnerability

If you find a security problem, please report it before disclosing it publicly. See SECURITY.md for how to reach us. We will not pursue anyone acting in good faith.