PAYNORABack to home

Privacy Policy (Foundation — Phase 15A)

This document is a technical foundation for a privacy policy, not a finished legal instrument. PAYNORA does not claim GDPR compliance, or compliance with any other privacy regulation, on the basis of this document alone. Sections marked [TO BE COMPLETED] require a decision or fact this codebase cannot supply on its own (a legal entity name, a jurisdiction, a contact address); sections marked NEEDS LEGAL REVIEW describe an accurate technical fact whose legal sufficiency has not been assessed by counsel. See docs/privacy-data-inventory.md and docs/data-flows.md for the underlying, independently-verified facts this document summarizes — if the two ever disagree, the inventory and flow documents are authoritative, since they're generated by reading the actual code.

1. Data controller / operator

[TO BE COMPLETED] — the legal entity operating a given PAYNORA deployment (name, registered address, jurisdiction) is not fixed by this codebase; it belongs to whoever deploys and operates PAYNORA.

2. Data collected

See docs/privacy-data-inventory.md for the complete, code-verified inventory: account data, organization data, financial/business data, wallet/blockchain data, AI-processing data, analytics data, and technical data (cookies, rate-limit-keyed IP addresses).

3. Purpose of processing

  • Account data: authentication, password recovery, organization membership.
  • Financial/business data: the core product function — tracking receivables, customers, invoices, payments, and reminders.
  • AI processing: drafting reminder content and prioritization insights, always subject to human approval before anything is sent.
  • Analytics: understanding product usage, only when configured and only for organizations that have not opted out (Settings → Privacy).
  • Web Intelligence: answering queries that need current information, only when explicitly triggered by a caller.
  • Wallet/blockchain: detecting and reconciling incoming cryptocurrency payments against invoices.

4. Account / authentication data

Email and a bcrypt password hash (never the plaintext password) are stored to authenticate sign-in. See docs/privacy-data-inventory.md#account-data.

5. Business and financial data

Customer, invoice, and payment records are stored to provide the core product. This data belongs to the organization that created it, not to any individual user — see User rights for what that means for data-subject requests from an individual member of a multi-person organization.

6. AI processing

See docs/privacy-data-inventory.md#ai-processing and docs/data-flows.md#paynora--ai-provider-openrouter--mistral. AI prompts are built per-call and never persisted; only the final, human-reviewed output (e.g. a reminder email's drafted text) is stored, exactly like any manually-written equivalent would be.

7. Analytics

See docs/privacy-data-inventory.md#analytics. Configurable deployment-wide (ANALYTICS_PROVIDER) and per-organization (Settings → Privacy). No IP address is sent; PostHog's geolocation is explicitly disabled on every event.

8. Email

Sent via whichever SMTP relay the deployment operator configures — see docs/data-flows.md#paynora--email-provider-smtp. No PAYNORA-operated email infrastructure exists; the operator's own relay choice governs that relay's own data handling.

9. Telegram

An alternate delivery channel, only used for a customer who has a Telegram chat id on file. See docs/data-flows.md#paynora--telegram-bot-api.

10. Wallet / blockchain

PAYNORA never stores, requests, or transmits a private key or seed phrase — verified structurally (no such field exists anywhere in the schema) and directly asserted in the wallet domain's own test suite. See docs/wallet-architecture.md#4-security-model and docs/privacy-data-inventory.md#wallet--blockchain-data.

11. Web Search

See docs/privacy-data-inventory.md#web-intelligence. A search query is sent to Anthropic only when a caller explicitly triggers a search — see docs/production-integrations.md#web-intelligence's documented note that no automatic trigger exists in the product today.

12. Data retention

See docs/data-retention.md for the complete, verified breakdown of what's kept indefinitely (financial/audit records — deliberately, for accounting/audit reasons), what expires functionally but isn't physically purged (password reset tokens, invitations), and what's actively cleaned up (rate-limit counters, ~24 hours). Specific retention periods as a stated commitment: NEEDS LEGAL REVIEW.

13. Security

See SECURITY.md for the full security model, including the "Privacy & Third-Party Data Boundaries" section added in this phase. Passwords are bcrypt-hashed; every provider credential is server-side only; webhook deliveries are signature-verified before any state change; tenant isolation is enforced at every data-access boundary and independently tested.

14. Third-party processors (subprocessors)

See docs/subprocessors.md for the complete list — every subprocessor is optional and only active when its corresponding *_PROVIDER environment variable is configured.

15. International transfers

No PAYNORA-enforced data-residency guarantee exists for any provider except PostHog's optional EU-hosting configuration (POSTHOG_HOST=https://eu.i.posthog.com). Every other provider's processing region is that vendor's own default routing — see docs/data-flows.md#international-processing. NEEDS LEGAL REVIEW for any deployment with a strict data-residency requirement.

16. User rights

A user can request:

  • Data export — GET /api/account/export (while signed in) returns a JSON export of that user's own account data (email, name, and their organization memberships with role) — see src/server/auth/data-export.ts. This deliberately does not include organization-owned financial data (customers, invoices, payments) — that data belongs to the organization, not to one member, and a single member exporting an entire organization's financial records without the organization's consent would itself be a privacy/security problem. An organization's own data is already visible to its members through the product itself (the Invoices/Customers pages).
  • Account deletion — see Data deletion below.
  • Correction of inaccurate account data — via the existing Settings → General "Organization name" and account fields; no separate "request a correction" flow exists beyond directly editing the field.

Beyond what's listed above, a jurisdiction-specific right (e.g. a formal right to object, a right to restrict processing) is NEEDS LEGAL REVIEW — this document does not claim to implement every right a given regulation might require.

17. Data deletion

src/server/auth/account-deletion.ts#anonymizeUserAccount is a real, working action: it overwrites email/name with an anonymized, unguessable value and replaces the password hash with a random value that can never authenticate — the account can never be identified or signed into again. It is account anonymization, not row deletion: the User row itself is not removed, so nothing that references it (an OrganizationMember row, a Communication.actionProposalId's approver, etc.) is ever orphaned. Organization-owned financial data is never touched by this action — see Data retention for why (accounting/audit requirements). If the requesting user is the sole OWNER of an organization with other members, that organization loses its only administrator once this completes — the action does not block on this today; it is the user's own choice to make, surfaced as a warning at the point of use, not a hard block.

18. Contact information

[TO BE COMPLETED] — depends on the operating entity from §1.

19. Policy updates

[TO BE COMPLETED] — a real update-notification process (e.g. "we'll email you N days before a material change") is an operational commitment this codebase does not implement or claim.

PAYNORA uses a strictly necessary session cookie and a language-preference cookie. Optional product analytics can be managed anytime in Settings → Privacy, once signed in.