Skip to main content

Security and Compliance

Related docs: Payment Architecture · Requirements

1. PCI-DSS SAQ A Compliance​

Pakashop qualifies for PCI-DSS SAQ A (the most reduced scope) because it never collects, processes, transmits, or stores raw card data.

PrincipleImplementation
No raw card dataCard payments redirect to Flutterwave's hosted payment page; Pakashop never sees card numbers, CVV, or expiry
No card data in logsComplianceLogger scrubs PANs matching /\b\d{13,19}\b/ from all log lines
Encrypted transportAll API traffic over TLS 1.2+ (Cloudflare + Nginx with Cloudflare Origin Certificate)
Scope boundaryFlutterwave is the Cardholder Data Environment (CDE); Pakashop is out of scope

Prohibited Development Patterns:
To maintain PCI-DSS compliance, developers are strictly prohibited from implementing routes that handle raw card data. All card entry must occur on hosted gateway pages, ensuring that Pakashop servers remain outside the Cardholder Data Environment (CDE).

2. Bank of Zambia (BoZ) NPS Act​

Pakashop operates as a marketplace platform and complies with the National Payment Systems Act through its licensed partners.

2.1 Delayed Settlement (Escrow-Avoidance Model)​

To avoid the requirement for an escrow license while ensuring buyer protection, Pakashop implements a delayed settlement model. Customer funds are held in the provider's licensed ecosystem and are only released to vendors after delivery is confirmed.

2.2 Licensed Partners​

The platform integrates exclusively with Bank of Zambia licensed entities for all financial operations, including PawaPay and Flutterwave.

3. Zambia Data Protection Act 2021​

  • Consent: Explicit user consent is required and logged for all payment operations.
  • Masking: PII (phone numbers, emails) is automatically masked at the application layer before being written to logs.
  • Enforcement: A centralized compliance utility ensures that data minimization rules are applied consistently across all services.

3.2 Data Processor Agreements​

Pakashop maintains formal agreements with all third-party data processors, including payment gateways, image hosting providers, and notification services, ensuring that user data is handled in accordance with the 2021 Act.

3.3 Subject Rights​

The platform provides native mechanisms for users to exercise their rights to access, rectify, or erase their personal data, including the anonymization of historical transaction records upon account deletion.

4. General Security Measures​

4.1 Authentication and Control​

  • Authentication: JWT-based session management with short-lived access tokens and secure refresh mechanisms.
  • Authorization: Role-based access control (RBAC) enforced across all administrative and vendor interfaces.
  • Identity: Integration with established OAuth providers to reduce the platform's credential management surface.

4.2 Transport and Edge Security​

  • Encryption: Enforced TLS 1.2+ for all traffic, secured by high-grade certificates.
  • Edge Protection: Utilization of a Web Application Firewall (WAF) to block common attack patterns and enforce rate limiting across sensitive endpoints.

4.3 Input and Data Integrity​

All incoming data is strictly validated against defined schemas. Payment amounts and settlement figures are calculated server-side based on immutable order items to prevent client-side manipulation.

4.4 Webhook and Integration Security​

Gateway integrations use cryptographic signatures (HMAC or secure hashes) to verify the authenticity of incoming notifications. Verification occurs on raw request payloads before any business logic is executed.

4.5 Dependency and Lifecycle Management​

The platform utilizes automated vulnerability scanning in the CI pipeline to identify and block compromised dependencies. Security patches and runtime versions are reviewed and updated on a regular quarterly cycle.

5. Multi-Factor Authentication (MFA) and TOTP​

Pakashop enforces a strict, robust Multi-Factor Authentication (MFA) system to secure accounts, particularly partner and administrative roles.

5.1 Role-Based Enforcement Rules​

  • Elevated Roles (Mandatory): Users with the role of PLATFORM_ADMIN, SHOP_OWNER, or DELIVERY_AGENT must enroll in and verify at least one MFA channel. Upon initial registration or login, if MFA is not enabled, the system intercepts the session and issues a restricted mfa_setup token with a 30-minute expiration. The user cannot access protected resources or issue session cookies until MFA setup is completed.
  • Standard Roles (Optional): Users with the role of CUSTOMER or SERVICE_PROVIDER can optionally enroll in MFA via their profile configuration.

5.2 Supported Channels​

The system supports three fully redundant verification methods:

  1. Authenticator App (TOTP): Powered by speakeasy (standard RFC 6238 TOTP) and qrcode for visual provisioning. base32 secrets are encrypted using aes-256-cbc with a SHA-256 derived key prior to database storage.
  2. Email Verification: Transactional emails containing 6-digit cryptographically secure numeric codes. Tracked in the EmailOtp database table.
  3. SMS / WhatsApp: Powered by Twilio Verify service. Integrates strict try-catch handlers to catch Twilio outages gracefully, raising a custom SMS_SERVICE_UNAVAILABLE error instead of breaking the main login pipeline.

5.3 Challenge Tokens and Intermediate State​

Partial authorization sessions do not receive cookies. Instead, the backend operates a secure intermediate state machine utilizing a short-lived JWT token (5-minute expiration) with the mfa_login claim and user metadata. If a user has multiple active verified channels, they are presented with a method selection screen to choose where their OTP code is sent.