Threat Model: Pay-Ins

Status: Draft | Owner: Security Team | Last Updated: 2026-04-03 Methodology: STRIDE | Scope: Pay-In transaction flow end-to-end

Overview

STRIDE threat analysis for Simpaisa's Pay-In product covering mobile wallet collections (JazzCash, Easypaisa, bKash, etc.) across PK, BD, NP, and IQ. Processes 270M+ transactions annually worth $1B+.

---

Data Flow Diagram

┌──────────┐    HTTPS     ┌──────────┐    gRPC     ┌───────────┐
│ Merchant │─────────────▶│ KrakenD  │────────────▶│  Pay-In   │
│   App    │   (signed)   │ Gateway  │  (mTLS)     │  Service  │
└──────────┘              └──────────┘             └─────┬─────┘
                               │                        │
                               │ rate limit             │ Temporal
                               │ auth                   │ workflow
                               ▼                        ▼
                          ┌──────────┐           ┌───────────┐
                          │  Auth    │           │  Operator  │
                          │ Service  │           │  Adapter   │
                          └──────────┘           └─────┬─────┘
                                                       │
                               ┌───────────────────────┤
                               │                       │
                               ▼                       ▼
                          ┌──────────┐           ┌───────────┐
                          │ OTP Flow │           │  Wallet   │
                          │ (SMS)    │           │ Callback  │
                          └──────────┘           └─────┬─────┘
                                                       │
                                                       ▼
                          ┌──────────┐           ┌───────────┐
                          │ SurrealDB│◀──────────│  Webhook  │
                          │          │           │ Dispatcher│
                          └──────────┘           └───────────┘

---

Attack Surfaces

Surface	Entry Point	Trust Level
Merchant API	KrakenD gateway endpoint	Authenticated
OTP flow	SMS delivery + verify API	Partially trusted
Wallet callbacks	Operator→Simpaisa webhook	External
Webhook delivery	Simpaisa→Merchant callback	Outbound
Internal services	gRPC between microservices	Trusted (mTLS)

---

STRIDE Analysis

S — Spoofing

ID	Threat	Likelihood	Impact
S-PI-1	Forged API requests without valid signature	High	Critical
S-PI-2	Spoofed operator callback (fake success)	Medium	Critical
S-PI-3	OTP interception via SIM swap	Medium	High

S-PI-1: Forged requests without signing - Attack: Attacker obtains merchant API key but not signing secret; submits unsigned or incorrectly signed payment requests. - Mitigation: HMAC-SHA256 request signing mandatory on all POST endpoints. Reject unsigned requests with 401. → ADR-017 (API Authentication) - Residual risk: Key compromise. Mitigated by key rotation policy (90-day expiry).

S-PI-2: Spoofed operator callback - Attack: Attacker sends fabricated success callback to Simpaisa's callback endpoint, triggering premature payment completion. - Mitigation: IP whitelist per operator. Callback signature verification. Out-of-band status query to operator before state transition. → ADR-023 (Callback Verification)

S-PI-3: OTP interception - Attack: SIM swap attack intercepts OTP SMS, allowing attacker to authorise payment from victim's wallet. - Mitigation: Operator-side SIM swap detection. Rate limiting on OTP verification attempts (max 3). MSISDN binding to device fingerprint where supported.

T — Tampering

ID	Threat	Likelihood	Impact
T-PI-1	Amount manipulation in transit	Medium	Critical
T-PI-2	Callback payload modification	Low	High

T-PI-1: Amount manipulation - Attack: Man-in-the-middle modifies payment amount between merchant request and operator execution. - Mitigation: Amount included in HMAC signature. TLS 1.3 for all external connections. Amount re-validated at each workflow step in Temporal.

T-PI-2: Callback tampering - Attack: Attacker intercepts operator callback and modifies amount or status fields. - Mitigation: Operator callbacks verified via signature + reconciliation query. mTLS between operator and Simpaisa where supported.

R — Repudiation

ID	Threat	Likelihood	Impact
R-PI-1	No audit trail on OTP verification	Medium	High
R-PI-2	Merchant disputes transaction initiation	Medium	Medium

R-PI-1: OTP audit gap - Attack: Without OTP verification audit trail, disputed transactions cannot be attributed to the genuine wallet holder. - Mitigation: Full audit logging of OTP lifecycle: request, delivery confirmation, verification attempt, result. Immutable AuditEntry in SurrealDB. → ADR-031 (Audit Trail)

R-PI-2: Transaction initiation dispute - Attack: Merchant claims they did not initiate a transaction. - Mitigation: Request payload with HMAC signature stored in encrypted Transaction record. Idempotency key logged. W3C trace ID for full request lineage.

I — Information Disclosure

ID	Threat	Likelihood	Impact
I-PI-1	Internal table names in error responses	Medium	Medium
I-PI-2	MSISDN leakage in logs	Medium	High

I-PI-1: Verbose error messages - Attack: SurrealDB or internal service error messages leak table names, field names, or stack traces to API consumers. - Mitigation: Error sanitisation at KrakenD layer. Generic error codes returned to merchants. Detailed errors logged internally only. → ADR-012 (Error Handling)

I-PI-2: PII in logs - Attack: MSISDN, account numbers logged in plaintext to centralised logging. - Mitigation: PII masking in structured logging. MSISDN truncated to last 4 digits in non-debug logs. → PII-HANDLING-STANDARD

D — Denial of Service

ID	Threat	Likelihood	Impact
D-PI-1	OTP flood — no rate limiting	High	High
D-PI-2	Payment initiation flood	Medium	High

D-PI-1: OTP flood - Attack: Attacker triggers massive OTP sends to arbitrary MSISDNs, exhausting SMS budget and degrading operator relations. - Mitigation: Rate limit: 3 OTP requests per MSISDN per 15 minutes. Global OTP rate limit per merchant. CAPTCHA on retry. → RATE-LIMITING-POLICY

D-PI-2: Payment flood - Attack: Compromised API key used to submit millions of payment requests. - Mitigation: Per-merchant rate limiting at KrakenD (configurable RPS). Anomaly detection on volume spikes. Circuit breaker on operator adapters.

E — Elevation of Privilege

ID	Threat	Likelihood	Impact
E-PI-1	IDOR via merchantId manipulation	Medium	Critical
E-PI-2	Cross-merchant data access	Low	Critical

E-PI-1: IDOR via merchantId - Attack: Attacker modifies merchantId in API request to initiate payments on behalf of another merchant. - Mitigation: merchantId derived from authenticated API key at gateway layer — never from request body. Server-side enforcement. → ADR-019 (Tenant Isolation)

---

Risk Matrix

Threat	Likelihood	Impact	Risk Level	Mitigation Status
S-PI-1	High	Critical	Critical	Implemented
S-PI-2	Medium	Critical	High	Implemented
S-PI-3	Medium	High	High	Partial
T-PI-1	Medium	Critical	High	Implemented
T-PI-2	Low	High	Medium	Implemented
R-PI-1	Medium	High	High	Planned
R-PI-2	Medium	Medium	Medium	Implemented
I-PI-1	Medium	Medium	Medium	Implemented
I-PI-2	Medium	High	High	In progress
D-PI-1	High	High	High	Implemented
D-PI-2	Medium	High	High	Implemented
E-PI-1	Medium	Critical	High	Implemented
E-PI-2	Low	Critical	Medium	Implemented

---

ADR Cross-References

Mitigation Area	Related ADR / Standard
API authentication	ADR-017 API Authentication
Callback verification	ADR-023 Callback Verification
Audit trail	ADR-031 Audit Trail
Error handling	ADR-012 Error Handling
Tenant isolation	ADR-019 Tenant Isolation
Rate limiting	RATE-LIMITING-POLICY
PII handling	PII-HANDLING-STANDARD
Logging	LOGGING-STANDARD