Access enforced where the data lives
Permission checks run in the database and on the server, not in the interface. Hiding a button is never treated as a security measure.
Security
This page describes practices that are implemented in the product. It deliberately avoids claims we cannot demonstrate.
Permission checks run in the database and on the server, not in the interface. Hiding a button is never treated as a security measure.
Every customer, invoice, payment, message and document belongs to exactly one company. A request for another company's record is refused at the data layer.
Owners, admins, managers, analysts and viewers have different powers. Actions with financial consequences require sufficient authority and, where configured, a second person's approval.
A browser confirmation page is never accepted as proof of payment. Payment events are verified with the provider server-side and recorded once, so a repeated notification cannot create a duplicate payment.
Provider secrets and service credentials live in server-side secret storage. They are never included in the interface, in browser storage or in application logs.
Financial, administrative, permission, approval and configuration actions are recorded with who acted, what changed, when, and from where. Ordinary users cannot alter or remove those records.