๐Ÿ”’ Security

How Payorth protects your financial data and your customers' information. Every control listed below is implemented and verified in our codebase โ€” not aspirational.

Encryption

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.

TLS 1.2+ HSTS Preload AES-256 at Rest

Authentication & Session Security

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.

Passwordless Auth Rate-Limited OTP Cross-Tab Idle Timeout

Multi-Tenant Data Isolation

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.

orgId Scoped Queries Data-Layer Enforcement

Payment Security

Payorth never stores card numbers or bank credentials. All payment processing is delegated to PCI-DSS-compliant providers:

  • Paystack (Nigeria โ€” NGN) โ€” HMAC-SHA512 webhook signature verification
  • Stripe (United States โ€” USD) โ€” HMAC-SHA256 webhook signature verification
  • M-Pesa (Kenya โ€” KES) โ€” IP whitelist + CheckoutRequestID validation (M-Pesa does not sign callbacks)
  • Yoco (South Africa โ€” ZAR) โ€” HMAC-SHA256 webhook signature verification
  • Mobile Money (Ghana โ€” GHS) โ€” Paystack-backed HMAC-SHA512 verification

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.

No Card Storage HMAC Signatures Timing-Safe Compare Idempotent Webhooks

AI & WhatsApp Security

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.

Anti-Hallucination Guard Owner Approval Flow Progressive Verification

Infrastructure & HTTP Security

Our API enforces industry-standard HTTP security headers:

  • Content Security Policy (CSP) โ€” restricts which resources the browser can load, preventing XSS
  • X-Frame-Options: DENY โ€” prevents clickjacking attacks
  • X-Content-Type-Options โ€” prevents MIME type sniffing
  • Referrer-Policy: strict-origin-when-cross-origin โ€” controls referrer information leakage
  • Permissions-Policy โ€” disables camera, microphone, geolocation, and FLoC tracking

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.

CSP Enforced Non-Root Containers Sanitized Errors

Supply Chain & CI/CD Security

Every code change goes through automated security checks before reaching production:

  • Trivy container scanning โ€” blocks deployment on Critical/High vulnerabilities
  • Gitleaks secrets detection โ€” prevents accidental credential commits
  • Dependency auditing โ€” checks for known CVEs in all packages
  • License compliance โ€” blocks AGPL/GPL/SSPL licenses that could create legal exposure
  • SBOM generation โ€” CycloneDX software bill of materials for full transparency
  • Pinned CI/CD action SHAs โ€” prevents supply chain attacks through compromised GitHub Actions

Database migrations run automatically before deployment via a pre-deploy step, ensuring schema consistency without manual intervention.

Container Scanning Secrets Detection SBOM

Data Protection & Compliance

Payorth is designed with the data protection principles of GDPR, POPIA (South Africa), and NDPR (Nigeria) in mind:

  • Data export โ€” download all your data at any time through the dashboard
  • Data deletion โ€” request complete account and data deletion
  • Audit logging โ€” all financial actions logged with timestamps, actor IDs, and organization context
  • Data minimization โ€” API responses return only the fields needed for each operation
  • No third-party advertising โ€” we do not sell your data or use advertising cookies

For our complete data practices, see our Privacy Policy.

GDPR Principles POPIA Aligned Full Audit Trail

Responsible Disclosure

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:

  • A description of the vulnerability and its potential impact
  • Steps to reproduce the issue
  • Any relevant screenshots or proof-of-concept code
Our commitment: We will acknowledge reports within 48 hours and provide an initial assessment within 5 business days. We will not take legal action against researchers who report vulnerabilities responsibly.