OSJ Pay

الحل الذي صممناه

1. 01حلول الدفع

   تكامل برمجي متين وشامل مع بوابة "ميسّر"

   دمجنا عمليات الدفع بالبطاقات الموثقة بنظام (3-D Secure)، وبطاقات الخصم المحلية عبر شبكة "مدى"، إضافة إلى المحافظ الرقمية، وكل ذلك من خلال الربط بـ "ميسّر". قمنا بهندسة النظام بحيث ترتبط كل عملية دفع بمعرف الفاتورة (Invoice ID) التي تسددها؛ لضمان القدرة على تتبع كل هللة تُخصم لتعود بدقة للمدرسة المعنية، ولولي الأمر المحدد، ولرسم دراسي محدد دون أي مجال للبس أو التخمين.

2. 02المحافظ الرقمية

   تضمين آمن ومحترف لمحافظ Apple Pay و Google Pay

   قمنا بتنفيذ خطوات التوثيق المعقدة لملكية النطاق (Domain) والتاجر المطلوبة من آبل وجوجل. وبرمجنا أزرار الدفع بحيث لا تظهر وتزعج المستخدم إلا إذا كان جهازه يدعم المحفظة. النتيجة أن ولي الأمر يمكنه من خلال هاتفه تسديد رسوم الفصل الدراسي بالكامل باستخدام بصمة الوجه (Face ID) في ثوانٍ معدودة، دون الحاجة للبحث عن بطاقته أو كتابة أي أرقام يدوياً.

3. 03الأمان السيبراني

   لا نثق أبداً في الروابط كدليل على نجاح الدفع

   في الأنظمة المالية الصارمة، عودة العميل من صفحة الدفع إلى موقعنا لا تثبت أنه دفع فعلاً. لذا لا نعتمد عليها؛ بل يرسل الخادم (Server) الخاص بنا طلباً مباشراً ومشفراً إلى خوادم "ميسّر" للتأكد من حالة العملية الفورية، ثم نطابق المبلغ المسحوب والعملة مع الفاتورة الأصلية لدينا. بهذه البنية، حتى لو حاول أحدهم التلاعب في روابط الإحالة (Callbacks)، لن يتمكن من إجبار النظام على تسجيل أي رسوم كـ "مدفوعة" بالخطأ.

4. 04موثوقية الأنظمة

   إدارة تعارض إشعارات الدفع (Webhooks) والإحالات

   قد يصل إشعار الدفع من بوابة ميسّر (Webhook) قبل أو بعد عودة العميل للصفحة، وقد يصل مرتين، أو قد يتعطل كلاهما. لحل هذه المعضلة، برمجنا تحديثات الحالة لتكون متطابقة (Idempotent) ومرتبطة بمعرف العملية الفريد. أيهما يصل للخادم أولاً ينفذ تحديث الحالة، وأي طلب لاحق يُهمل بأمان. وفي الحالات النادرة التي ينقطع فيها الاتصال تماماً، يتولى نظام "المطابقة الدورية" (Reconciliation) المبرمج في الخلفية التقاط وتأكيد عملية الدفع لاحقاً.

5. 05معالجة السيناريوهات النادرة

   التحوط للثغرات والأخطاء التي تكلف أموالاً فعلية

   وفرنا حماية برمجية ضد نقر المستخدم المتكرر لمنع سحب المبلغ مرتين. وعالجنا حالات تراجع العميل أو انقطاع الإنترنت أثناء شاشة الأمان (3-D Secure). كما قمنا ببرمجة المبالغ الرياضية بنظام "الهللات" بدلاً من الكسور العشرية لتجنب أخطاء التقريب المحاسبي، ودعمنا إمكانية الاسترداد الجزئي للمبالغ، وقمنا بترجمة رموز الخطأ الغامضة لبوابة الدفع إلى رسائل رفض واضحة باللغة العربية البسيطة للمستخدم.

6. 06هيكلية تعدد المدارس والكيانات

   عزل صارم وموثوق لبيانات المدارس والعائلات

   تعمل كل مدرسة داخل المنصة كـ "تاجر" منفصل تماماً برقم تعريفي وحساب بنكي ورسوم وسجلات مستقلة. كما يمكّن النظام ولي الأمر من سداد رسوم جميع أبنائه، في فصول أو مدارس مختلفة، من خلال حساب موحد واحد. هذا الفصل الصارم للبيانات بين المدارس مطبق في عمق قاعدة البيانات (Database Level) وليس مجرد إخفاء بصري في واجهة الموقع.