Security
Control environment
Identity, organisation boundaries, workflow permissions, supplier controls, and the audit record work together. No certification status is implied by these descriptions.
Invoice audit trail
One chronological record from intake to payment
Invoice received
Bank change flagged
Coding accepted
Approval requested
Tenant host checks and organisation identifiers scope workspace access. PostgreSQL row-level security policies are enabled across the schema — every organisation-scoped table carries a policy restricting rows to the requesting user’s organisation, as an independent database-level boundary beneath the application layer. Invoice files use a private storage bucket with organisation-folder access policies.
Supabase Auth manages identity and session tokens. Server-side routes validate the signed-in user before protected actions. Paythos applies role-based permissions for Super Admin, Admin, Approver, and Viewer roles, with Super Admin-only team administration.
Production traffic is served over HTTPS. Secrets and service credentials are supplied through protected deployment environment variables. Accounting-integration tokens are protected with AES-256-GCM envelope encryption: each token is encrypted with a per-record data key, which is itself wrapped by a separate key-encryption key, so only the wrapped key is ever stored.
Payment initiation is deduplicated using idempotency keys, so a retried or duplicate request cannot submit the same payment twice. Changes to supplier bank details enter a pending-verification state and are held until reviewed, closing a common invoice-fraud and business-email-compromise vector. Provider webhook handlers verify each provider’s own signature (e.g. Stripe’s signature header, Xero’s webhook signature) before processing an event.
Workflow actions are captured with a double-write pattern: an immutable execution log plus organisation-scoped audit events, recording actor, action, outcome, and timestamp — visible to customers in-app under Audit. Sentry is configured for application error and performance monitoring, with sampling and replay controlled by environment settings.
Cookie preferences default optional storage to denied and integrate with Google Consent Mode v2. Our DPA defines processing instructions, confidentiality, subprocessors, incident support, deletion, data-subject assistance, and international-transfer safeguards.
Paythos does not currently claim third-party information-security certification. We do not describe the service as independently audited against a certification framework. Customers should assess the controls documented here and contact us for information reasonably required for their supplier due diligence.
Live uptime for the application and database is published at paythos.tech/status.
Evaluating Paythos and need to complete a security questionnaire or walk a reviewer through our controls? Our team will work through this documentation with you directly and answer follow-up questions in detail.
Customers are responsible for keeping user access current, assigning least-privilege roles, reviewing proposed GL codes and coding decisions, reviewing approval and routing rules, validating extracted invoice and bank data, securing connected provider accounts, and reporting suspected account compromise promptly.
Our Privacy Policy explains our use of personal data. Our Data Processing Agreement sets out processor obligations and the security measures applied to Customer Data.
If you believe you have found a vulnerability, include reproducible details and avoid accessing or changing other people’s data.