CloudInvoiceTrust center
Security is a product practice, not a badge.
CloudInvoice is built to make the most sensitive parts of invoicing—workspace access, client details, payment status, and production configuration—deliberate. Here is what the product does today, and where its security boundary ends.
Current safeguards
Designed around the data that matters most
Workspace boundaries
Authenticated application reads and changes resolve the current membership first, then scope business records to that organization. This reduces the chance of one workspace seeing another workspace’s invoices or clients.
Account sessions
CloudInvoice uses Better Auth for account and session handling. Email-and-password sessions are configured to expire, rather than remaining valid forever.
Hosted card checkout
Card payments are initiated through Stripe Checkout. CloudInvoice records payment outcome and Stripe payment identifiers; it does not build a card-entry form or retain card numbers in its application database.
Verified payment updates
A payment is recorded only after the Stripe webhook signature has been checked. The webhook handler also prevents a payment identifier from being recorded more than once.
Private invoice access
Client invoice pages use an unguessable public token rather than a sequential invoice ID. The link should still be treated as confidential by the sender and recipient.
Purposeful data storage
The application stores the account, workspace, client, invoice, and payment records required to deliver invoicing. CloudInvoice does not describe this as a certification, audit, or guarantee of compliance.
Operational model
A practical production baseline
Deployment choices are part of the security model.
CloudInvoice’s deployment documentation is designed for a private PostgreSQL database, secrets held outside source control, container-based releases, and narrowly scoped network access. Those controls must be configured by the production operator; they are not enabled merely by cloning this repository.
For a low-cost AWS deployment, the recommended baseline is an EC2 application host behind HTTPS, an RDS PostgreSQL instance that is not publicly reachable, a private S3 bucket for uploaded assets, and security groups limited to expected application traffic.
Read the Privacy Policy for how product data is handled, and review the deployment runbook before connecting a production database or payment account.
Engineering controls
What changes payment state
A client opens an invoice link
The public page is addressed with an opaque invoice token. The sender controls where that link is shared.
Stripe processes card checkout
The card collection experience is hosted by Stripe Checkout after the application creates a checkout session for the invoice.
A verified webhook records the result
CloudInvoice checks the Stripe signature, looks for a successful paid session, and creates an idempotent payment record before updating the balance.
Security reporting
Responsible disclosure belongs in the launch plan.
Before public launch
The service operator should publish a dedicated security-reporting address, an incident contact, a data-processing contact, and the legal entity responsible for CloudInvoice. Those details are intentionally not invented in this codebase.
If you operate this deployment, add a monitored contact channel before inviting customers and document your incident triage, backup, retention, and access-review procedures.
Looking for product availability? See service status. Legal terms and responsibility boundaries are available in the Terms of Service.
Build the invoice experience your clients can trust.
Create a workspace, keep your business records organized, and use payment flows that only record verified card outcomes.
Get started