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.
Business verification
Registered in India. Built for accountable business.
MSME Registered
Ministry of MSME, Government of India
Udyam Registration No: UDYAM-RJ-17-0675217
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 Auth.js with email-and-password credentials and JWT-backed sessions. Password reset links are time-limited and single-use.
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.
The production baseline keeps the application behind HTTPS, limits database access to the application network, stores uploaded assets privately, and exposes only the traffic required to operate the service.
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