Information Security Policy
Last updated: 10 October 2026
1. Purpose
This policy sets out how Alphastrive Company Limited (RC 7467693), trading as PaySphere, protects the platform, its data, and the people who use it. It applies to everything that touches PaySphere: the web app, the mobile app, the API, the database, and the staff who work on it.
2. Scope
This policy covers: the paysphere.ng website and API; the PaySphere iOS and Android apps; all data stored in Supabase; all data processed by our third-party providers; and all staff, contractors, and systems with access to production data or infrastructure.
3. Data in Transit
All connections to paysphere.ng and our API are encrypted with TLS 1.2 or higher. We use HTTPS everywhere and redirect all plain HTTP requests to HTTPS. API calls between our backend and processors (Flutterwave, Dojah, Bitnob, Sotel, Supabase) are also made over HTTPS. We do not make unencrypted outbound requests that carry user data.
4. Data at Rest
The database is hosted on Supabase with encryption at rest. Transaction PINs are hashed using bcrypt before storage — we never store the raw PIN. BVN data is not stored raw; we retain only the masked display value and the name returned by the verification result. Gift card images are stored with access controls that prevent public URLs from working without authorisation.
5. Access Controls
Database access is governed by Supabase Row Level Security (RLS) policies. Each user can only read and write their own records. API routes that handle financial operations require a valid user JWT from Supabase Auth. Admin endpoints require an additional admin flag set on the user's record — a regular JWT is not enough. Service role keys are environment variables and never exposed client-side. Staff with direct database access use individual accounts with MFA.
6. Authentication
Users sign in with email and password via Supabase Auth, or with Google OAuth. Passwords are hashed by Supabase (bcrypt). Session tokens are JWTs with a short expiry and are validated server-side on every protected API call. We enforce a 4-digit transaction PIN for all financial operations (withdrawals, trades, eSIM purchases, crypto operations). PIN attempts are rate-limited and the account locks after a configurable number of wrong attempts.
7. Rate Limiting
Every API endpoint has a rate limit keyed to the user's IP address or authenticated user ID. Limits are enforced using Upstash Redis. A too-many-requests response (HTTP 429) is returned when the limit is exceeded. Financial endpoints (withdrawal, trade creation, eSIM purchase, PIN verification) have tighter limits than read-only endpoints.
8. Third-Party Security
We only send user data to processors we have contractually committed to data protection obligations. Webhook events from Flutterwave are verified against the payment hash before we act on them. Bitnob webhooks are verified with an HMAC secret. We do not pass user credentials to third parties. We review our processor list at least once a year.
9. Secrets and Keys
API keys, service role keys, and signing secrets are stored as environment variables in Vercel. They are never committed to the source code repository. We rotate keys when a member of staff with access leaves. The Supabase service role key is only used server-side in API routes — it is never exposed in the browser or in the mobile app bundle.
10. Vulnerability Management
We run npm audit on the web and mobile codebases as part of our deployment pipeline. We apply dependency updates for known security vulnerabilities within 14 days of disclosure. Critical vulnerabilities (CVSS 9.0+) are patched within 24 hours. We do not use end-of-life versions of Node.js or React Native in production.
11. Logging and Monitoring
Sentry monitors crashes and API errors in real time. PII masking is configured so personal data does not appear in error reports. Supabase logs record authentication events, including failed login attempts. Upstash records rate-limit hits by IP. We review security-related alerts on a daily basis. Unusual withdrawal or trade patterns trigger Telegram alerts to the admin team.
12. Staff Access
Access to production data is granted on a need-to-know basis. We do not give contractors access to raw user data unless the task specifically requires it, and access is revoked when the task is done. Staff with admin access are required to use strong unique passwords and MFA. Offboarding includes immediate revocation of all credentials.
13. Incident Response
We have a separate Incident Response Procedure at paysphere.ng/legal/incident-response. If we become aware of a security incident that puts user data at risk, we follow that procedure — which includes notifying the NDPC within 72 hours and notifying affected users without undue delay.
14. Physical Security
PaySphere has no physical servers. All infrastructure is cloud-hosted (Vercel for compute, Supabase for database, Upstash for caching). Physical security of those data centres is covered by those providers under their own security certifications. Staff laptops that have production access use full-disk encryption.
15. Backup and Recovery
Supabase takes automatic daily backups of the database. Point-in-time recovery is available. In the event of a data loss incident, we can restore the database to within a recent snapshot. We test restore procedures at least once per year.
16. Security Testing
We maintain an automated security test suite that checks: authentication bypass attempts, unauthenticated access to protected routes, injection payloads, and HTTP security headers. We run this suite against staging and production before significant releases. Manual penetration testing is planned at least once per year.
17. Policy Review
This policy is reviewed at least once a year and after any significant security incident. The Data Protection Officer (Abiodun Tolulope, [email protected]) is responsible for keeping it current.
18. Contact
Security concerns or vulnerability reports: [email protected]. For data protection matters specifically: [email protected].