Security and payment controls
Invoice-to-pay control environment
Identity, organisation boundaries, role permissions, immutable invoice payment details, provider verification, and audit records 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.
The payout details captured from each invoice are stored as an immutable snapshot and cannot be edited by a user. First-seen or changed details create a verification hold before payment. Payment initiation uses stable idempotency keys to prevent duplicate submission, and provider webhook signatures are verified before status events are processed. UK GBP payment runs settle through Modulr, an FCA-authorised Electronic Money Institution.
Auto Pilot uses immutable settings and policy versions, strict organisation scope, transactional idempotency, worker leases, emergency stop, and actor provenance. AI reviews redacted evidence; deterministic policy alone authorises allowlisted actions. Payment release, retry, rerouting, and beneficiary authority remain human-only. Sentry is configured for application error and performance monitoring without AI payload bodies.
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 as an AP or payment-control supplier? We can work through your security questionnaire, architecture questions, data flows, and control requirements with the relevant reviewers.
Customers are responsible for keeping user access current, assigning least-privilege roles, reviewing coding decisions and proposed nominal codes, maintaining approval and routing rules, independently verifying beneficiary-detail holds, securing connected provider accounts, and reporting suspected 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.