BarnamBarnam / Security and trust
Security and trust
Money accounts must be dependable. This page says what we keep and how, and the security steps ahead.
Approved device
Session and role
Accounting rules in the database
Chained history
Several layers, from the device to the books
Every request passes several gates before it reaches the accounts. If one fails, the next is still in place.
The path of one entry, from request to history
Requestfrom the user's device
Deviceis it approved?
Roleis it allowed?
Transactionall or nothing
Database rulesdo the books balance?
Historychained and recorded
Data and accounts
- Accounting rules in the database: debits equal credits; closed invoices and closed days cannot be edited; these are PostgreSQL constraints.
- An append-only ledger: corrections are made only with a reversing or adjustment entry and the original stays.
- Money as whole rials: no decimals and no silent rounding.
- Every action completes or does not happen: each request runs in one transaction; an error means nothing was recorded.
- No duplicate entries: a double click or a retry does not create a second document.
Access and sign-in
- Passwords: stored with argon2id and a separate "pepper" kept outside the database; weak passwords are rejected.
- Sessions: an access token lasts 10 minutes; a refresh token is single-use, and reusing it closes the whole session.
- Live checks: deactivating a seller or blocking a device takes effect from the very next request.
- Device approval: a user's first device is trusted; later devices do not work until an admin approves them.
- Temporary lock: after several wrong passwords the account is locked for a while.
- Roles: a seller sees only their own rows and columns; the limit is enforced in the database, not just in the app's interface.
Isolation and history
- Stall isolation: every stall has its own database and credentials; credentials are derived from one master secret and are not stored in the database.
- Chained history: the activity log is hash-chained and a nightly check verifies it is intact.
Backups and monitoring
- A daily backup of every stall is taken and each backup is test-restored into a temporary database.
- Every request carries a trace ID; on a server error only that ID reaches the user and internal details stay inside.
- The API contract runs under automated tests and every database change is a numbered, immutable migration.
Security: what is built and what comes next
Security: what is built and what comes next
The status of each item at a glance:
Sign-in with number and PIN, and device approvalWorks in the appBuilt
Two-step verification for adminsA second sign-in layer for adminsPlanned
An independent penetration testA security review by an independent third partyPlanned
Automatic card-terminal connectionCard payments recorded automaticallyPlanned
Offline modeKeep working through an internet drop without risking the booksPlanned
Real SMS deliveryAutomatic debt and due-date reminders to customersComing soon
Report a vulnerability
If you find a weakness, please report it responsibly and do not disclose it before it is fixed. We reply to every report.
Report toinfo@barnam.ir
A demo on your own load and invoice
Let us walk one real load from arrival to settlement together. The demo is free of obligation and uses sample data.