Security
Your billing data, on your own server
Ottsa runs on your own hosting, so your clients, invoices and server credentials stay in your database, not ours. This page explains how Ottsa protects that data and the controls it gives your team.
How Ottsa protects your data
Your data stays with you
Ottsa runs on your hosting with your own database, and we never receive your clients, invoices or credentials. The license check sends only your license key, an install ID, the domain and folder Ottsa runs in, and the Ottsa and PHP versions.
Encryption
Server and service passwords, transfer codes, gateway tokens, mail accounts and API secrets are encrypted in the database with your site's own key. Staff and client passwords are hashed, and on HTTPS sites browsers are instructed to keep using a secure connection.
Backups you control
Daily or weekly database backups are stored on the private disk, with as many kept as you choose, ready to download. Restoring one is a standard SQL import into an empty database.
Signed updates
Every update is checked against Ottsa's signing key before it is applied, and the files it changes are backed up first. Updates install from the admin area, without SSH.
Secure development
Before it ships, every change passes static analysis, rules that forbid risky functions, and the full test suite on PHP 8.4 and 8.5. The source is plain PHP, so you can read exactly what runs on your server.
Web protections built in
A strict Content Security Policy on every page, CSRF protection and rate-limited sign-ins. Ottsa connects only to servers at public addresses unless you explicitly allow a private one.
In your admin area
Controls for your team
-
Two-factor authentication
For staff and clients, using an authenticator app with recovery codes. You can require it for administrators, for clients or for both.
-
Staff roles
Decide what each role can do, such as viewing billing, answering tickets in specific departments, managing servers or importing data.
-
Audit log
Sign-ins, changes and refunds are recorded with who acted, when and from which IP address. IP addresses can be removed from older entries after a period you set.
-
Client data requests
Export a client's data as a zip file, erase a client while keeping the invoices the law requires you to retain, and choose how long old records keep personal data.
-
Scoped API tokens
Give each integration only the permissions it needs, and revoke a token without affecting others. API docs
Audit log
Sample entries-
MK
Invoice INV-10482 refunded
Maya K. · 81.2.69.142 · 2 min ago
-
JD
API token billing-sync created
Jon D. · 192.0.2.17 · 40 min ago
-
JD
Backup ottsa-2026-10-30.sql.gz downloaded
Jon D. · 192.0.2.17 · 1 h ago
-
Wrong two-factor code entered
priya@ · 203.0.113.9 · 3 h ago
-
MK
Role Support updated
Maya K. · 81.2.69.142 · Yesterday
Payments and card data
Card numbers never reach Ottsa. Your clients enter them in your gateway's own secure fields, such as Stripe's Payment Element, and Ottsa stores only the gateway's token, the card brand, the last four digits and the expiry date.
This keeps Ottsa outside your PCI DSS cardholder data environment, so you can usually complete the shortest self-assessment questionnaire with your gateway.
Gateway webhooks are verified before any invoice is marked as paid.
Privacy and GDPR
Your clients' personal data is stored in your own database, and you are its controller. As a company, Ottsa never receives it, so we process none of your clients' data.
Data exports, erasure and retention rules are built into the admin area, so you can handle your clients' requests yourself.
To learn what we hold about you as our customer, read our Privacy Policy.
Found a vulnerability?
Responsible disclosure
We welcome reports from security researchers. Email [email protected] with the steps to reproduce the issue and a description of its impact.
Report a vulnerabilityWhat we promise
- A reply within 2 business days.
- Regular updates until the issue is resolved.
- Public credit when we release the fix, if you wish.
- No legal action for good-faith research that follows these rules.
What we ask
- Test only against your own install, such as a trial on your own hosting.
- Do not access, modify or delete data that does not belong to you.
- Do not use denial-of-service attacks, spam or social engineering.
- Allow us reasonable time to fix the issue before disclosing it publicly.
Need a security questionnaire completed?
Send it to us and we will complete it.