How Primue actually protects your data.
Not a checklist of buzzwords — this page describes the real mechanisms behind the product, in plain language, so you know exactly what’s protecting your business data.
Tenant isolation, enforced by the database
Every table is scoped with Postgres Row Level Security, not just application-layer checks. A query for another tenant's data is rejected by the database itself, before it ever reaches your code.
Tamper-evident signatures
Each signature is chained: its record hash is computed from the document hash, the signer's details, and the previous signature's hash. Edit any earlier record and every hash after it stops matching — the tampering is mathematically detectable, not just logged.
Real payment rails, never your card or wallet data
Primue never sees or stores card numbers or crypto wallet keys. Payments run through Stripe's hosted checkout (PCI-DSS compliant) or, where a tenant has connected it, NOWPayments' hosted crypto checkout. Primue only ever stores the resulting transaction record.
Real authentication
Sign-in runs on Supabase Auth (email/password), with session cookies and server-side verification on every request — not a client-side flag that can be spoofed.
Baseline practices
TLS encryption in transit for every request.
Encryption at rest for the underlying Postgres database.
Secrets (API keys, service credentials) live in environment variables, never in source control.
Every API route re-verifies the caller's session and tenant on the server — a client can't just claim a tenant ID.
Webhook payloads (e.g. from Stripe or NOWPayments) are signature-verified before anything is written to the database.
Roadmap — being upfront
Two-factor authentication, a dedicated audit-log viewer, and formal SOC 2 certification are not live yet. We’d rather tell you what’s actually built today than list features that don’t exist. If a specific control matters for your compliance requirements, ask — contact us directly.