This page describes how we approach security today, as a company working with founding partners through controlled pilots. It will be extended as PAIVUS moves into general availability and formal certification.
01
Our approach
Security is treated as a property of the system, not a feature added afterward. Financial correctness, data integrity and access control are enforced at the infrastructure and database level — not only in application code — so a bug in one part of the platform cannot silently corrupt a booking, a payment, or a guest record elsewhere.
We would rather be specific about what is true today than make broad claims ahead of formal certification. This page will be updated as our security programme matures, and dated accordingly.
02
Data residency and infrastructure
PAIVUS is hosted on Vercel, with application data held in Supabase, running in the London (eu-west-2) region. For our founding UK and Nigeria partners, this means core operational data resides in the United Kingdom by default, rather than being distributed across an undefined set of global regions.
03
Encryption
Data is encrypted in transit using TLS, and at rest using our infrastructure providers’ standard encryption. Access to production data is restricted to systems and personnel that require it to operate the platform.
04
Financial and data integrity, by design
PAIVUS’s ledger is built as an immutable, double-entry record: financial writes happen atomically, so a booking or payment update either completes in full or does not happen at all — there is no partial or inconsistent state for staff to reconcile by hand.
Every inbound event (a booking, a webhook from a payment or channel partner, a status update) is processed idempotently, so a retried or duplicated message cannot double-charge a guest, double-book a room, or duplicate a ledger entry. Reservation, payment and room-status transitions are enforced through defined state machines at the database level, not left to application logic alone to get right every time.
This is the same design discipline we’d want from any system handling other people’s money and other people’s guests — enforced structurally, not just promised in documentation.
05
Access control
Access within PAIVUS is role-based: staff see and can act on what their role at the property requires, not the full system by default. Material actions — the kind that affect a guest, a room, or a payment — are attributable to the account that performed them.
Multi-factor authentication is available for staff and administrator accounts.
06
ARK: explainable, permissioned, auditable
ARK is designed so its role in the business stays visible and controllable, not opaque:
- Explainable — every recommendation can show the signals and context behind it.
- Permissioned — role-based authority determines who can review, approve or execute an action ARK proposes.
- Auditable — recommendations, approvals, actions and outcomes remain part of the operational record.
ARK is built to support hospitality decisions, not to make unreviewed changes to guest, financial or operational records on its own. Material actions require human approval before execution.
07
Payments
Payment processing is handled through Paystack, a licensed and regulated payment services provider. PAIVUS does not take, store or process card data on its own infrastructure — card details are handled entirely within our payment partner’s environment.
08
Vendors and subprocessors
PAIVUS relies on a small number of infrastructure and payment partners to operate the platform, currently including Vercel (hosting), Supabase (database and backend infrastructure), and Paystack (payments). We review the security posture of any partner with access to customer or guest data before integrating them.
09
Reporting a vulnerability
If you believe you’ve found a security vulnerability in PAIVUS, we want to hear from it before anyone else does. Please report it to hello@paivus.com with enough detail to reproduce the issue.
We ask that you avoid accessing, modifying or deleting data that isn’t yours, and give us a reasonable opportunity to investigate and respond before any public disclosure.
10
Incident response
If an incident affecting customer or guest data occurs, affected founding partners will be notified without undue delay, along with what we know, what we’re doing about it, and what action, if any, they need to take.
11
Compliance
PAIVUS is built with UK GDPR and Nigeria’s Data Protection Act (NDPA) in mind as core operating markets. Further detail on how we collect, use and protect personal data is set out in our Privacy Policy.
12
Contact
Questions about security at PAIVUS can be sent to hello@paivus.com.
Report a vulnerability
Found a security issue in PAIVUS? Let us know before anyone else does.