Your data is encrypted in transit and at rest. We follow SOC 2, ISO/IEC 27001, and PCI DSS practices and intend to pursue independent audits; we do not hold those certifications or reports today. Security-relevant actions are recorded in an audit log. If you find a security issue, email [email protected].
Frameworks and audits
QairoPay is a product of UpLevel Technologies LLC. We have not yet completed any independent security audit or certification. We design our controls around the following frameworks and intend to pursue formal audits as the platform moves out of pilot:
- SOC 2 — we follow the AICPA Trust Services Criteria for security, availability, and confidentiality, and intend to pursue a SOC 2 examination.
- ISO/IEC 27001 — we follow its information-security management practices and intend to pursue certification.
- PCI DSS 4.0 — we follow its requirements in how we design card-related features. Card data is handled by our licensed card-issuing partner, and we intend to complete the PCI assessment that applies to our role before the card program leaves pilot.
Payment, card, and fiat conversion services are provided through licensed partners and are currently in test or pilot. See the Compliance page for details.
Encryption
Data is encrypted in transit and at rest.
In transit
- All external traffic uses TLS. Customer-facing domains enforce HTTPS with HTTP Strict Transport Security (HSTS).
- Traffic between our service providers is encrypted and authenticated.
At rest
- Databases and object storage are encrypted at rest by our infrastructure providers.
- Sensitive fields are also encrypted at the application layer, with keys held in Google Cloud KMS.
- Card numbers are handled by our card-issuing partner and are not stored on systems we operate.
Key management
Signing keys and encryption keys are held in Google Cloud KMS, and other secrets in Google Cloud Secret Manager. Application code does not store raw key material.
Access control
Customer authentication
- Email and password sign-in with rate limiting.
- TOTP-based multi-factor authentication.
- Session cookies are
HttpOnlyandSecure. - Single sign-on via SAML 2.0 and OIDC is available on eligible plans.
Tenant isolation
Every customer record is tagged with a tenant identifier, and the application scopes every request to the tenant making it.
Internal access
- Role-based access control based on least privilege.
- Access to production systems is limited to the people who need it and requires multi-factor authentication.
Infrastructure
QairoPay runs on a small set of managed providers in the United States:
- Cloudflare — edge network, static sites (Pages), edge logic (Workers), object storage (R2), key-value storage (KV), and queues.
- Railway — the core API and background workers.
- Neon — managed PostgreSQL, our system of record.
- Google Cloud KMS and Secret Manager — custody of signing keys, encryption keys, and secrets. We use Google Cloud for key custody only.
Infrastructure and application changes go through code review before they are deployed.
Data handling and retention
QairoPay processes the minimum data required to deliver the service. Categories and retention windows are documented in the Privacy Policy; this section covers the technical handling.
- Tenant data is retained for the life of the contract plus 30 days, after which it is deleted or anonymized.
- Audit events are retained for at least 12 months.
- Backups are encrypted and managed by our database provider.
- Customer-initiated export and deletion are supported on request.
Monitoring and audit log
Security-relevant actions, such as sign-ins, administrative operations, role changes, and key operations, are recorded in an audit log that application users cannot edit.
- We monitor the platform for errors and unusual activity.
- Customers can receive platform events through signed webhooks.
Incident response
We have an incident response process for investigating and containing security incidents.
- If an incident affects your data, we will notify you without undue delay and within any period required by law or your contract.
- After a significant incident, we share a summary with affected customers covering the cause, timeline, and fixes.
Vulnerability disclosure
We welcome reports from independent security researchers acting in good faith. We do not currently run a bug-bounty program.
- Please do not run denial-of-service tests, social engineering, or physical tests.
- Give us a reasonable chance to fix an issue before you disclose it publicly.
- We will acknowledge your report and keep you updated as we work on a fix.
Shared responsibility
Security is a shared responsibility. QairoPay secures the platform; customers secure their use of it. The most common customer-side responsibilities:
- Enforce SSO and MFA across your team; review member access regularly.
- Treat API keys as secrets — rotate on staff change, store in a secret manager, never embed in client code.
- Verify webhook signatures on every callback and reject unsigned payloads.
Reporting a security issue
To report a suspected vulnerability or active incident, contact [email protected]. Please include a clear reproduction path and any artifacts that demonstrate impact.
For security questionnaires and vendor reviews, email [email protected].
This page is informational and does not modify the contractual obligations defined in your QairoPay Master Services Agreement, Data Processing Addendum, or Security Schedule. Where this page conflicts with executed contract language, the contract governs.