نموذج العمليات والضوابط

Epara ليست مجرد صفحة دفع للتاجر. بصفتها مالك المنصة، يجب على الشركة التحكم في حركة المال بسجلات دقيقة وقابلة للتدقيق وغير قابلة للتلاعب. لذلك Operator Backoffice منفصل عن Merchant Dashboard.

مكاتب التحكم

المكتب	المسؤولية
Merchant Onboarding	KYB والاتفاقية وملف النشاط وcapability وجاهزية go-live.
Risk Desk	مراجعة مخاطر الدفع والتاجر والمستهلك والمزود والسرعة.
Payout Control	طلبات Payout والوجهة والجدول ونتيجة provider.
Ledger Control	double-entry ledger وbalance projection وضوابط no-negative-balance.
Reconciliation	مطابقة ملفات provider/bank مع سجلات المنصة.
Provider Operations	صحة provider وroute decision وcredential وإعادة المحاولة.
Webhook Control	endpoint التاجر وتسليم الأحداث وretry وأدلة التوقيع.
Audit Evidence	permission checks وaudit trail وimmutable record وhash evidence.
Compliance Control	KYC وKYB والاتفاقيات والحدود المالية وتطبيق policy.
Support	إدارة حالات consumer وmerchant وpayment.

مبدأ maker-checker

العمليات الحساسة تحتاج طالبا وموافقا منفصلين.

العملية	Maker	Checker
Merchant live activation	Onboarding operator	Privileged operator
Payout approval	Payout operator	Finance approver
Risk hold release	Risk analyst	Risk approver
Pricing policy change	Product/finance operator	Governance approver
Provider credential rotation	Technical operator	Security approver
Balance adjustment	Finance operator	Finance approver

حدود Ledger

لا يجب أن توحي كل شاشة في Operator UI بأنها تحرك المال. بعض الشاشات تنشئ evidence فقط ولا تكتب Ledger.

العملية	هل تنشئ Ledger movement؟
Merchant onboarding review	لا
KYB evidence upload	لا
Webhook endpoint create	لا
Provider route config change request	لا
Payment capture	نعم
Refund success	نعم
Payout paid	نعم
Balance adjustment approved	نعم
Risk hold create/release	غالبا لا، لكنه قد يؤثر على available balance

قرارات المخاطر

Risk ليس فقط "احتيال أو لا". في Epara النتائج هي:

Decision	المعنى
allow	العملية يمكن أن تستمر.
monitor	العملية تستمر مع دليل مراقبة.
review	تحتاج مراجعة operator.
hold	المال أو capability يتم حجزه مؤقتا.
block	العملية أو capability يتم منعها.

ضوابط Provider route

اختيار provider يجب أن يراعي:

صحة provider.
طريقة الدفع المدعومة.
العملة، خصوصا IQD.
capability الخاصة بالتاجر.
الرسوم وسلوك settlement.
حالة provider credential.
سجل retry وfallback.
قيود risk أو compliance.

كل اختيار يجب أن يسجل كـProvider Route Decision.

نموذج Reconciliation

Reconciliation يقارن سجلات الدفع والـledger في Epara مع ملفات provider أو bank أو network.

الحالة	الإجراء
matched	سجلات المنصة والمزود متطابقة.
provider_missing	لدى Epara سجل غير موجود في ملف provider.
platform_missing	ملف provider يحتوي سجلا غير موجود في Epara.
amount_mismatch	المبلغ مختلف.
currency_mismatch	العملة مختلفة.
duplicate	نفس provider reference ظهر أكثر من مرة.
unresolved	يحتاج تحقيق يدوي.

Reconciliation difference لا يجب أن يعدل balance مباشرة. إذا احتاج الأمر تصحيحا، يتم فتح balance adjustment request بموافقة maker-checker.

أدلة التدقيق

كل عملية جدية يجب أن تجيب:

السؤال	الدليل
من فعلها؟	actor id وrole وsession/device evidence.
بأي صلاحية؟	Permission Check.
متى حدثت؟	timestamp.
ماذا تغير؟	before/after أو object state.
لماذا حدثت؟	reason code أو note أو linked case.
هل أثرت على المال؟	Ledger movement أو explicit no-ledger evidence.
ماذا يحدث عند retry؟	idempotency result.

Checklist العمليات الحية

Merchant onboarding وKYB سجلات دائمة.
live activation يستخدم maker-checker.
API credential secrets لا تظهر raw في القوائم.
Webhook delivery موقع وقابل لإعادة المحاولة.
Payment capture وrefund وpayout idempotent.
Ledger بنموذج double-entry ومتوازن.
Reconciliation differences لا تعدل balances مباشرة.
Provider credentials مشفرة وقابلة للدوران.
Operator action يكتب Audit Trail.
Sensitive file access عبر token ومحدود زمنيا.