SERVICE_RISK_REGISTER — payment-gateway-service
Sibling: SERVICE_READINESS · SECURITY_MODEL · FAILURE_MODES
This register tracks the structural risks of payment-gateway-service — the ones that survive normal engineering hygiene and require executive awareness or deliberate residual acceptance. Operational, transient incidents are captured in FAILURE_MODES.
Risk scoring uses a 1–5 scale for likelihood and impact, multiplied to a 1–25 score. Owner = single accountable person; status = open | mitigating | accepted | closed. The register is reviewed monthly by the service owner and quarterly by the security committee.
| ID | Risk | Likelihood | Impact | Score | Owner | Status |
|---|---|---|---|---|---|---|
| R-PAY-01 | PCI scope creep | 3 | 5 | 15 | SecOps lead | mitigating |
| R-PAY-02 | Vendor lock-in (single processor dominance) | 4 | 3 | 12 | Service owner | mitigating |
| R-PAY-03 | Regulatory shift in MFS markets | 4 | 4 | 16 | Compliance lead | mitigating |
| R-PAY-04 | Chargeback fraud at scale | 3 | 4 | 12 | Service owner | mitigating |
| R-PAY-05 | Tenant cross-talk via shared infra component | 1 | 5 | 5 | SecOps lead | mitigating |
| R-PAY-06 | Cash-on-arrival drift between desktop and cloud | 3 | 3 | 9 | Service owner | mitigating |
| R-PAY-07 | FX provider dependency / currency volatility | 3 | 3 | 9 | Service owner | mitigating |
| R-PAY-08 | AI false-positive blocking legitimate guests | 2 | 4 | 8 | AI lead | mitigating |
| R-PAY-09 | Vendor sunset of MFS adapter (e.g., HesabPay licensing change) | 2 | 4 | 8 | Service owner | open |
| R-PAY-10 | Webhook delivery integrity (silent drop) | 3 | 4 | 12 | Service owner | mitigating |
R-PAY-01 — PCI scope creep
Risk: A future feature accidentally requires storing, processing, or transmitting card data, dragging us out of SAQ A into SAQ D or worse.
Triggers:
- Product asks for "saved card numbers visible to staff."
- Engineering proposes server-side card collection (e.g., for legacy POS integration).
- A compliance gap in a vendor pushes us to receive raw card data temporarily.
Mitigation:
- Architectural rule: card capture only via processor-hosted UI; codified in
SECURITY_MODEL. - PR template includes a PCI checkbox; PRs touching
payment-gateway-service,bff-tenant-booking-service, orbff-backoffice-servicerequire SecOps review when checked. - CI scanner blocks forbidden field names.
- Annual scope re-validation by external assessor.
Residual: Acceptable for now; quarterly review.
R-PAY-02 — Vendor lock-in
Risk: Disproportionate reliance on Stripe (or PayPal) creates leverage risk on pricing, terms, or feature roadmap.
Mitigation:
PaymentPortabstraction means adding adapters is a 2–3 sprint effort.- Roadmap commits to Adyen and Razorpay adapters within 12 months.
- Per-tenant precedence allows operators to switch primary processor without downtime.
- Reconciliation logic is processor-agnostic.
Residual: Accept; revisit when adding the third processor.
R-PAY-03 — Regulatory shift in MFS markets
Risk: Local regulators (e.g., Da Afghanistan Bank, State Bank of Pakistan) introduce new licensing or AML requirements that affect HesabPay or future MFS adapters, blocking transactions or triggering reporting obligations.
Mitigation:
- Compliance lead monitors regulatory bulletins per region.
- Tenant configuration allows disabling specific adapters per region instantly.
- Quarterly legal review of MFS terms.
- We operate as a merchant on processor records — not as a payment facilitator — keeping us out of most MFS-specific licensing.
Residual: High due to regional volatility; rolling review.
R-PAY-04 — Chargeback fraud at scale
Risk: Coordinated chargeback abuse (friendly fraud, account takeover) erodes margins and damages processor relationship (high chargeback ratio risk).
Mitigation:
- AI fraud scoring annotates risky transactions; high tier requires manual approval at next capture.
- Lock access logs, folio, and guest comms used as standardized evidence packs.
- AI-assisted narrative drafting in chargeback workflow shortens response time to processor deadlines.
- Per-property dashboards highlight chargeback ratio; alerts when above 0.5%.
Residual: Accept; reduce as AI fraud model matures.
R-PAY-05 — Tenant cross-talk
Risk: A code path or shared component leaks data across tenant boundaries.
Mitigation:
- Schema-per-tenant + Postgres role separation makes a successful exfil require a privilege escalation in addition to a code bug — defense in depth.
- Test enforcing cross-tenant SQL fails with
permission denied. - Webhook receiver resolves tenant from out-of-band field then cross-checks against the secret used for verification.
Residual: Low; structural barrier.
R-PAY-06 — Cash-on-arrival drift
Risk: Desktop offline cash receipts diverge from cloud state for long periods, leading to operator confusion or financial discrepancy.
Mitigation:
- Server is authoritative; desktop cache is rebuilt on reconnect.
- Outbox push is idempotent; same
Idempotency-Keyalways collapses. - End-of-shift forces zero
pendingoutbox before close. - Reconciliation against
billing-servicecash drawer events daily.
Residual: Accept; monitor desktop outbox age metric.
R-PAY-07 — FX provider dependency
Risk: A single FX provider outage or sudden rate volatility causes mis-priced authorizations.
Mitigation:
- 24-h rate cache as fallback.
- Roadmap: dual-FX-provider with median quote.
- FX context snapshot on every authorize for finance audit.
Residual: Accept; add second provider in next quarter.
R-PAY-08 — AI false positives
Risk: Fraud scoring causes legitimate guests to be blocked, damaging brand and revenue.
Mitigation:
- AI is advisory by design; no auto-block on score alone.
- HITL gate for tier-
high; operator decides. - Per-tenant precision/recall thresholds; auto-rollback on drift.
- Eval harness on shadow scoring before each model rollout.
Residual: Low; structural separation enforces it.
R-PAY-09 — MFS adapter sunset
Risk: A regional MFS provider (e.g., HesabPay) changes terms or shuts down, leaving us scrambling for an alternative.
Mitigation:
- Per-tenant adapter precedence allows fallback to cash-on-arrival quickly.
- We monitor MFS provider stability quarterly.
- Roadmap includes a second MFS adapter per region within 18 months.
Residual: Open; depends on regional market.
R-PAY-10 — Silent webhook drop
Risk: Vendor or our infra silently drops a webhook; transaction state diverges; revenue lost or guest double-charged.
Mitigation:
- Daily reconciliation back-fills missing state from settlement reports.
- 6-hourly catch-up job (planned) re-fetches from vendor APIs.
- Webhook DLQ with operator alerts.
- Replay tool in
payments-admin-cli.
Residual: Accept; reduce when 6-hourly catch-up ships.
Closed risks
(none yet — service pre-launch.)
Reporting
The risk register is exported to the platform-wide risk dashboard monthly. Score trend (rolling 12 months) and any score ≥ 16 entry triggers escalation to the executive risk committee.