Security

ShegerPay processes payment-verification traffic for hundreds of Ethiopian merchants. Security is a first-class engineering concern, not a marketing checkbox. This page documents how we protect merchant and customer data, and how to responsibly disclose vulnerabilities.

Transport security

All ShegerPay endpoints — API, dashboard, webhooks, status page, and documentation — are served over TLS 1.3 only. TLS 1.2 is permitted as a fallback for clients that cannot negotiate 1.3; older versions are rejected at the edge. We use a modern cipher suite (AEAD only, no CBC, no RC4). HSTS is enabled with max-age=63072000; includeSubDomains; preload and we are on the Chromium HSTS preload list. Certificates are issued by a public CA with CAA-pinned issuers and renewed automatically with 30-day overlap.

Key management

Merchants receive three classes of credentials:

  • pk_live_… — publishable keys safe to embed in client-side code. Scoped to read-only operations only.
  • sk_test_… — sandbox secret keys. Cannot touch live data.
  • sk_live_… — production secret keys. Server-side only.

Keys are stored hashed (Argon2id) at rest. The dashboard shows full key value exactly once, at creation time. Rotation is a single click and supports overlap windows so deploys never break. Compromised keys can be revoked immediately and we publish revocation events to your webhook for audit.

Webhook signature verification

Every webhook delivery is signed with HMAC-SHA256 using your endpoint's signing secret. The signature is in the ShegerPay-Signature header along with a Unix timestamp. To prevent replay attacks, reject any request where the timestamp is more than 5 minutes from server time.

Node.js:

const crypto = require('crypto');

function verifyShegerPayWebhook(payload, header, secret) {
  const [tPart, sigPart] = header.split(',');
  const timestamp = tPart.split('=')[1];
  const signature = sigPart.split('=')[1];
  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${payload}`)
    .digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

Python:

import hmac, hashlib

def verify_shegerpay_webhook(payload: bytes, header: str, secret: str) -> bool:
    t_part, sig_part = header.split(',')
    timestamp = t_part.split('=')[1]
    signature = sig_part.split('=')[1]
    expected = hmac.new(
        secret.encode(),
        f"{timestamp}.".encode() + payload,
        hashlib.sha256,
    ).hexdigest()
    return hmac.compare_digest(signature, expected)

PHP:

function verifyShegerPayWebhook(string $payload, string $header, string $secret): bool {
    [$tPart, $sigPart] = explode(',', $header);
    $timestamp = explode('=', $tPart)[1];
    $signature = explode('=', $sigPart)[1];
    $expected = hash_hmac('sha256', $timestamp . '.' . $payload, $secret);
    return hash_equals($expected, $signature);
}

Failed deliveries are retried up to 5 times with exponential backoff (1m, 5m, 30m, 2h, 12h). After the final attempt, the event is parked and surfaced in your dashboard for manual replay.

Infrastructure

ShegerPay runs on tier-1 cloud infrastructure (AWS / GCP) in the Africa region with multi-AZ failover. Production access is gated by hardware-key 2FA and SSO. We use:

  • Immutable, signed container images
  • Least-privilege IAM with no long-lived credentials in CI
  • Database encryption at rest (AES-256), automated daily snapshots, point-in-time recovery
  • Network-level isolation between sandbox and production
  • Centralized audit logging with tamper-evident hashing
  • Continuous dependency scanning (Dependabot + Snyk)
  • Automated SAST on every PR

Vulnerability disclosure program

We welcome reports from independent researchers. Email [email protected] — PGP key available on request.

Our commitments:

  • Acknowledge receipt within 24 hours
  • Initial triage within 3 business days
  • Status update at least every 7 days until resolved
  • Public CVE and credit (if desired) for any confirmed high-severity issue
  • No legal action against good-faith research that complies with the policy below

Scope: shegerpay.com, api.shegerpay.com, dashboard.shegerpay.com, all official SDKs, the WordPress plugin, and the MCP server.

Out of scope: third-party services we depend on (report directly to them), DoS / volumetric attacks, social engineering of staff, physical attacks, and findings that require already-compromised credentials.

Responsible-disclosure timeline: please give us 90 days to ship a fix before public disclosure. We will work with you to coordinate the timeline if the issue is complex or requires customer migration.

Bug bounty

A formal monetary bug-bounty program is coming soon (expected Q3 2026). In the interim, we offer public credit, swag, and discretionary cash rewards for high-impact reports. Critical findings (RCE, auth bypass, mass data exposure) qualify for cash rewards today — contact [email protected].

Compliance posture

ShegerPay is not in the cardholder data flow and therefore not in PCI-DSS scope as a processor. We follow PCI-DSS-aligned operational controls regardless (network segmentation, key rotation, access logging). For Ethiopian merchants subject to NBE record-keeping requirements, we retain compliance records for 7 years and provide audit-ready exports on request.