Retail fraud is rarely sophisticated. It is a void raised after hours, a discount nobody approved, a return processed against no invoice, cash that never reached the bank. ambar 27’s security model is built around making those things visible — and hard to do without leaving a name attached.
Hiding a menu item is not security. Every screen in ambar 27 checks the current user’s role against the specific action being attempted — so a user who guesses a URL gets refused, not served.
The person who raises a payment should not be the person who approves it, and neither should be the person who releases the cheque. Planners make that separation structural rather than a policy people are trusted to remember.
Counter terminals are shared, staff turnover is real, and a password written on a sticky note is normal. Two-factor on the accounts that matter, and controlled user provisioning, are the minimum.
When something is wrong at month end, the question is always the same: who did this, and when. Activity logging across the application means that question has an answer, and everyone on the floor knows it does.
| Question | Answer |
|---|---|
| Where is the data stored? | In a MySQL database on infrastructure you own or rent in your own name — an on-premise server, or your own cloud account in your chosen region. There is no shared multi-tenant database. |
| Can ambar 27 staff see it? | Only with access you grant, for support you request. You hold the server credentials. Access can be revoked by you at any time without our cooperation. |
| Is data sent to third parties? | Only where you configure an integration, and only the fields that integration needs — invoice data to your GSP for IRN, message content to WhatsApp, payment data to Razorpay. Each uses your own account. |
| What about biometric data? | Face recognition stores numeric descriptors in your own database and matches locally on your server. No images or biometric data are sent to any external service. |
| Transport security | HTTPS throughout, with automatic certificate management through Caddy. Integration calls to GSP, WhatsApp and payment providers are made over TLS. |
| Backups | Scheduled database and file backups to storage you control, with a retention policy agreed at implementation and a restore tested before go-live. |
| Deletion and exit | Your data is yours. Full standard-format dumps on request, and on exit you keep the server, the database and the documentation. |
Deletion is a permissioned action, and in practice most deployments do not grant it at all — sales are voided instead, which leaves the original record, the void, the reason and the user who did it in the voided-sales register. Close-day history makes an after-the-fact change visible even if someone has the rights.
Discount groups and the discount planner define the ceiling by category, customer group or code before the negotiation happens. Exceeding it requires a user holding the override permission, and the override is recorded against the invoice with the approving user’s name.
Authentication is handled in-application with optional TOTP two-factor. If SSO against an identity provider is a requirement for your deployment, raise it during scoping — it is an integration discussion rather than a product limitation.
Their account is deactivated, which revokes access immediately while preserving every transaction, approval and activity record they created. History is never removed with the user, because the audit trail is the reason it exists.
Yes — void registers, close-day history, approval trails on planners, the inventory log and the report-access register are all available as reports, permissioned separately so an auditor can be given read access to exactly those.
We would rather answer the hard control questions before you buy than after. Book a session and bring the person who signs off your books.