أعدّت MagicPay هذا الدليل لمساعدة الشركات التي تختار بنية دفع على الفصل بين الربط واتخاذ القرار والتشغيل. يتتبع الدليل دفعة من إرسال الطلب إلى المزود حتى تسجيل النتيجة المؤكدة في الطلب والسجلات المالية. ويعرض منظور MagicPay بوصفها مزوداً تقنياً، مع إطار عملي لتقييم مشروعك.
1. افصل الربط عن التنسيق بحسب الوظيفة
بوابة الدفع هي طبقة الربط التي تحوّل طلب الشركة إلى صيغة يفهمها مزود الدفع، وترسله ثم تعيد الاستجابة. أما تنسيق المدفوعات فينسّق اختيار الاتصال المؤهل والخطوة التالية بحسب النتيجة وتتبع العملية. ليست هاتان فئتين متعارضتين من المنتجات؛ فقد تضم البوابة وظائف توجيه وتشغيل أيضاً. حدّد الفاصل عبر مسؤولية كل خطوة، لا عبر اسم المنتج.
- سؤال الربط: وفق أي عقد لواجهة API يُرسل الطلب، وإلى أي مزود؟
- سؤال التنسيق: لماذا اختير هذا الاتصال، وأي نتيجة تحدد الخطوة التالية؟
2. ارسم رحلة الدفع لطلب واحد
أنشئ مرجع الطلب ومرجع الدفع، واختر اتصالاً مؤهلاً ثم أرسل الطلب. قد يتطلب المسار إتمام العميل للمصادقة؛ وقد تصل النتيجة فوراً أو تظل معلّقة. وصول العميل إلى صفحة العودة لا يكفي لإثبات الدفع. تُحدَّث الحالة بإشعار خادم موثَّق أو استعلام حالة وفق وثائق المزود. قد يكون التفويض والتحصيل وتحويل الأموال إلى الحساب مراحل منفصلة؛ اربط تنفيذ الطلب بالمرحلة المؤكدة المناسبة.
3. ابدأ قرار التوجيه بشروط الأهلية
يحدد التوجيه المزود المستخدم قبل بدء المحاولة. تحدّ العملة وطريقة الدفع وحساب التاجر واتفاقية المزود أولاً من الخيارات المؤهلة؛ ثم تُطبَّق قواعد الأولوية أو التكلفة داخل هذه المجموعة. وجود اتصالات متعددة لا يعني وحده وجود بديل قابل للاستخدام. عند تقييم قاعدة توجيه، اسأل متى تُطبَّق وأين يُسجَّل قرارها ومن يستطيع التراجع عنها إذا عملت بصورة خاطئة.
4. احسم النتيجة غير المعروفة قبل إعادة المحاولة
انتهاء المهلة لا يثبت أن المزود لم يعالج الطلب. سجّل المحاولة الحالية ثم استعلم عن حالتها باستخدام مرجع المزود، أو انتظر إشعاراً موثَّقاً. إرسال تحصيل جديد إلى مزود آخر بينما النتيجة الأولى مجهولة قد ينتج دفعتين ناجحتين. عند إعادة إرسال الطلب نفسه تقنياً، اتبع شروط المزود لمنع التكرار: استخدم مفتاح العملية نفسه والمعلمات نفسها ضمن النطاق ومدة الاحتفاظ المدعومين فقط. المفتاح لدى مزود لا يمنع تكرار عملية لدى مزود آخر.
- ميّز عطل الاتصال المؤقت عن الرفض النهائي؛ فليس كل رفض قابلاً لإعادة المحاولة.
- ابدأ محاولة جديدة فقط عندما تسمح النتيجة السابقة وقواعد المزود، وحدّد عدد المحاولات وحدود الانتظار.
- إذا بقيت النتيجة مجهولة، حوّل العملية إلى المراجعة؛ إنشاء مفتاح جديد لا يحسم حالتها.
5. صمّم سجل التشغيل مستقلاً عن استجابة الدفع
يجب تتبع مرجع الطلب ومعرّف كل محاولة ومرجع المزود والمبلغ والعملة وسبب القرار وانتقالات الحالة معاً. تحقّق من الإشعارات بطريقة المزود، وامنع الإشعارات المكررة أو الواصلة بترتيب مختلف من إتمام الطلب مرتين. هذا السجل لا يحل محل دفتر المحاسبة أو مطابقة الحساب البنكي. افصل طلب الاسترداد عن الاسترداد المكتمل، والتحصيل الناجح عن الأموال التي وصلت إلى الحساب. عيّن مسؤولاً لمعالجة الفروق بين سجلات الطلب والمزود والمالية.
6. اختر الطبقة بحسب عبء العمل الفعلي
قد يكفي الربط وتتبع الحالة الأساسي لشركة تستخدم مزوداً واحداً ومسار حالات واضحاً. أما تعدد المزودين أو تغيّر قواعد التوجيه أو وجود قائمة دفعات غير محسومة أو تتبع استردادات متفرق، فيستدعي تقييم مسؤوليات التنسيق بشكل مستقل. زيادة الطبقات ليست أفضل دائماً؛ فهي تضيف إدارة قواعد ونقاط تعطل جديدة. اربط القرار بالعمل اليدوي الذي يؤديه الفريق اليوم وبالمسؤولية التشغيلية التي يستطيع تحملها، لا باسم المنتج.
- ما القرارات التي تُتخذ يدوياً اليوم، وعلى أي بيانات تعتمد؟
- عندما تبقى دفعة معلّقة، من أين يبدأ الفريق ومن يملك مسؤولية التحقيق؟
- ما الذي يتغير في إجراءات الطلبات والمالية عند إضافة مزود؟
7. اختبر الانتقال بالمدفوعات القائمة قبل الربط الجديد
احصر المراجع الحالية والمدفوعات المفتوحة ومسارات الاسترداد وتصدير السجلات. لا تفترض إمكانية نقل بيانات وسائل الدفع المحفوظة؛ تحقّق مع المزود المعني من نطاق الرموز والأذونات اللازمة. اختبر على طلب تجريبي مضبوط النجاح والرفض النهائي وانتهاء المهلة والإشعار المتأخر والإشعار المكرر. حدّد من يتابع المحاولات المفتوحة عند التراجع. يجب أن تقارن التجربة الموازية القرارات فقط، وألا تبدأ تحصيلين منفصلين للطلب الحقيقي نفسه.
- من يتولى الاستعلام والاسترداد والمطابقة للمدفوعات المتبقية في النظام القديم؟
- أي معيار قبول يوقف الانتقال ويستدعي التراجع عن قاعدة أو اتصال؟
- هل يستطيع فريق التشغيل تتبع دفعة نموذجية من الطلب إلى السجل المالي؟
8. قيّم MagicGate ضمن هذا الإطار
تشمل MagicGate، البنية التقنية الموجهة للشركات من MagicPay، ربط مزودي الدفع وتنسيق المدفوعات معاً. لذلك لا يحصر التمييز العام في هذا الدليل MagicGate في الربط وحده. وضّح عبر رحلة طلب محدد الاتصالات المطلوبة وشروط التوجيه وإعادة المحاولة واستعلام الحالة وسجلات التشغيل. وحدّد بشكل منفصل دور المؤسسة المرخصة التي تتولى حركة الأموال والحسابات والاتفاقيات؛ فالطبقة التقنية لا تقوم مقام هذا الدور.