How Payorth protects your financial data and your customers' information. Every control listed below is implemented and verified in our codebase โ not aspirational.
All traffic is encrypted in transit using TLS 1.2+ with HSTS (HTTP Strict Transport Security) enforced for one year with preload, preventing protocol downgrade attacks.
Sensitive data at rest is encrypted using AES-256 encryption, including OAuth tokens for accounting integrations (Xero, QuickBooks, Sage, Zoho Books). Bank account details and BVN numbers are encrypted and never displayed in full through our API or dashboard.
Payorth uses OTP-based phone verification โ there are no passwords to steal, leak, or brute-force. We rate-limit OTP requests to 5 per minute and signup attempts to 3 per minute to prevent abuse.
Sessions are protected with JWT tokens that expire after 24 hours. An additional 30-minute idle timeout is enforced across all open browser tabs simultaneously โ if any tab is idle, all tabs log out together, preventing session hijacking on shared devices.
For programmatic access, API keys support scoped permissions, rotation, and expiry, backed by database records with a legacy environment variable fallback to prevent lockout during migration.
All data is strictly isolated by organization. Every database query across the entire application โ invoices, contacts, payments, conversations, reminders, credit notes, reconciliation records โ is scoped by organization ID (orgId).
This is enforced at the data access layer, not just the route layer, so even in the event of an application-level vulnerability, cross-tenant data access is prevented by design. Contacts use a composite unique constraint (orgId + phone) as an additional isolation boundary.
Payorth never stores card numbers or bank credentials. All payment processing is delegated to PCI-DSS-compliant providers:
All signature comparisons use constant-time comparison (Node.js
crypto.timingSafeEqual) to prevent timing side-channel attacks. Webhook events are
deduplicated using SHA-256 idempotency keys to prevent double-processing.
Invoice records use optimistic locking (version column) to prevent race conditions during concurrent payment processing.
Every AI-generated financial action (invoice creation, payment recording, status changes) passes through a deterministic anti-hallucination guard that validates amounts, dates, contacts, and currencies before execution. The AI cannot create or modify financial records without passing this validation layer.
An owner approval flow ensures that AI-drafted messages are reviewed before being sent to customers. Progressive verification gates (4-tier trust model) unlock capabilities as your business is verified, preventing abuse of freshly created accounts.
Our API enforces industry-standard HTTP security headers:
Application containers run as non-root users with signal handling via
dumb-init for graceful shutdown. Error responses return generic messages โ stack
traces, internal paths, and database details are never leaked to clients.
Every code change goes through automated security checks before reaching production:
Database migrations run automatically before deployment via a pre-deploy step, ensuring schema consistency without manual intervention.
Payorth is designed with the data protection principles of GDPR, POPIA (South Africa), and NDPR (Nigeria) in mind:
For our complete data practices, see our Privacy Policy.
We take security vulnerabilities seriously and appreciate the work of security researchers who help us keep Payorth safe.
If you discover a security vulnerability, please report it to security@payorth.com. Please include: