خدمات ربط بوابة الدفع في الإمارات ومنطقة الشرق الأوسط
تربط MotionPexels بوابات الدفع الإلكتروني للتجار في الإمارات والسعودية ومنطقة الشرق الأوسط وشمال أفريقيا. نبني ربطًا يعمل في بيئة التشغيل الفعلي لا في بيئة الاختبار فقط، مع معالجة سليمة للفشل وإعادة المحاولة وعمليات الدفع المعلقة.
ما الذي يتضمنه ربط جاهز للتشغيل الفعلي
استجابة النجاح من واجهة API هي بداية العمل لا نهايته. هذه الأجزاء هي التي تحدد هل يصمد الربط مع عملاء حقيقيين.
مراجعة المتطلبات
نفهم نموذج عملك وأسواقك المستهدفة وحجم عملياتك وحالاتك الخاصة قبل كتابة أي سطر برمجي.
صفحة مستضافة أو ربط عبر API
توصية واضحة بين صفحات الدفع المستضافة والربط المباشر عبر API، بحسب حاجتك إلى التحكم ومتطلبات الامتثال.
مصادقة 3DS2
مسارات مصادقة تعمل عبر المتصفحات والأجهزة والبنوك المصدرة، مع مخرج بديل عند فشل أي خطوة.
التوكنة (Tokenization)
حفظ آمن لبيانات الدفع على شكل رموز، فتعمل المدفوعات المتكررة والاشتراكات من دون التعامل مع بيانات البطاقة الخام.
إشعارات Webhooks ومنع التكرار
معالجة موثوقة لأحداث الدفع غير المتزامنة، ومفاتيح لمنع التكرار (idempotency keys) حتى لا تؤدي إعادة المحاولة إلى خصم العميل مرتين.
إعادة المحاولة والمسارات البديلة
سلوك محدد عند انتهاء المهلة وتعطل البنك المصدر وفشل المصادقة، فلا يصل العميل إلى طريق مسدود.
الاستردادات والمطابقة المحاسبية
مسارات استرداد وتقارير تتيح لفريقك المالي مطابقة المدفوعات مع الطلبات والتسويات.
تغطية الاختبار
اختبارات للمسارات الناجحة وحالات الرفض والتفويض الجزئي وانتهاء المهلة واحتكاك 3DS، قبل الإطلاق.
وسائل الدفع التي نربطها
البطاقات
Visa وMastercard، ومصادقة 3DS2، والتوكنة، ورموز الشبكات (network tokens)، وصفحات مستضافة أو ربط عبر API، وتقليل حالات الرفض، وروابط الدفع.
Apple Pay والمحافظ
Apple Pay على الويب وداخل التطبيق، وGoogle Pay وSTC Pay، بما يشمل التحقق من التاجر وإعداد النطاق والشهادات.
وسائل الدفع المحلية
مدى (السعودية)، وKNET (الكويت)، وBenefit (البحرين)، وOmanNet (عمان)، وUAEFTS وغيرها من المسارات المحلية.
الشراء الآن والدفع لاحقًا
تابي وتمارا وبوست باي، مع مسارات فحص الأهلية ومعالجة الاسترجاع والنزاعات.
وسائل أخرى
التحويلات البنكية، والوسائل النقدية، وPayPal، والخدمات المصرفية المفتوحة، ومسارات إعادة التوجيه.
قائمة التحقق التي نعمل بها
هذا هو الترتيب الذي نعمل به في ربط نموذجي.
- تأكيد المتطلبات: الأسواق والعملات ووسائل الدفع وحجم العمليات وقواعد الاسترداد
- اختيار صفحة الدفع المستضافة أو الربط المباشر عبر API
- تصميم حالات الدفع: معلقة، ومفوّضة، ومحصّلة، وفاشلة، ومستردة
- تنفيذ المصادقة، بما فيها 3DS2 وما يحدث عند فشلها
- إضافة معالجة إشعارات Webhooks مع التحقق من التوقيع ومنع التكرار
- بناء منطق إعادة المحاولة والمسارات البديلة لانتهاء المهلة ومشكلات البنك المصدر
- إعداد الاستردادات والإلغاءات والتحصيل الجزئي
- إضافة السجلات والتقارير حتى تظهر حالات الرفض وعمليات الدفع المعلقة
- اختبار المسارات الناجحة والفشل والرفض والحالات الحدّية في بيئة الاختبار
- إطلاق محكوم، ثم مراجعة أسباب الرفض الفعلية
نقاط الفشل الشائعة
عمليات دفع عالقة في حالة معلقة
لا تؤكد البوابة العملية، ولا شيء يحسمها. لا يعرف العملاء هل خُصم المبلغ، ويلاحق فريقك الطلبات يدويًا. الحل هو معالجة سليمة لإشعارات Webhooks، وفحص للحالة، ومسار محدد عند انتهاء المهلة.
حلقات 3DS
مسار مصادقة معطل لا يظهر في بيئة الاختبار. يُعاد العملاء الحقيقيون إلى الخطوة نفسها فيتركون الشراء. الحل هو الاختبار عبر المتصفحات والأجهزة والبنوك المصدرة، ومعالجة كل نتيجة.
ارتفاع مفاجئ في الرفض
ينخفض معدل القبول بعد الإطلاق بلا سبب واضح. غالبًا يكون السبب في الإعدادات، مثل إعدادات المصادقة أو التوجيه أو إعادة المحاولة، لا في البطاقات نفسها.
إذا كان لديك ربط قائم تظهر عليه هذه الأعراض، فاطلع على خدمة تحسين معدل القبول.
المدة وخطوات العمل
تعتمد المدة على عدد وسائل الدفع، وعلى اختيارك صفحة مستضافة أو ربطًا عبر API، وعلى حجم ما يجب تغييره في نظامك الحالي. نقدّم لك عرضًا فيه الجدول الزمني والنطاق قبل بدء العمل، فلا تفاجئك إضافات في منتصف المشروع.
تعمل مباشرة مع ليث محمد، المؤسس. يملك نحو تسع سنوات من الخبرة في المدفوعات وتقنياتها، منها منصب مدير هندسة الحلول في Checkout.com، وعمل مع تجار في أنحاء المنطقة.
ما الذي يحدد حجم جهد الربط
- عدد وسائل الدفع والأسواق
- صفحات الدفع المستضافة أو الربط المباشر عبر API
- الاشتراكات والبطاقات المحفوظة والتوكنة
- قواعد الاسترداد والإلغاء والتحصيل الجزئي
- حجم التغيير المطلوب في صفحة الدفع الحالية
- متطلبات التقارير والمطابقة المحاسبية لدى الفريق المالي
أساسيات الأمان التي نبنيها
تتعامل برمجيات الدفع مع بيانات حساسة. نتجنب لمس بيانات البطاقة الخام حيثما تكفي صفحة مستضافة أو رمز، ونتحقق من توقيعات إشعارات Webhooks، ونُبقي الأسرار خارج الشيفرة والسجلات.
ونصمم لمتطلبات PCI-DSS و3DS2 منذ البداية، بدلًا من إضافتها في النهاية.
الأسئلة الشائعة
كم يستغرق ربط بوابة الدفع؟
يعتمد ذلك على وسائل الدفع التي تحتاجها، وعلى اختيار صفحة مستضافة أو ربط عبر API، وعلى نظامك الحالي وحجم الاختبار المطلوب. نعطيك الجدول الزمني في العرض بعد مراجعة متطلباتك.
هل يؤثر الربط المستضاف أو المباشر في نطاق PCI-DSS؟
غالبًا نعم. مع صفحات الدفع المستضافة تذهب بيانات البطاقة مباشرة إلى مزوّد الدفع، وهذا يقلل عادةً نطاق PCI-DSS الذي تتحمله. أما مع الربط المباشر عبر API فتتولى جزءًا أكبر منه. تعتمد التزاماتك الدقيقة على إعدادك وعلى الجهة المستحوذة (acquirer).
كيف أختار بوابة الدفع؟
ابدأ بالأسواق ووسائل الدفع التي تحتاجها، ثم قارن التسوية والتسجيل وخيارات الربط والدعم. تأكد أن المزوّد يدعم وسائل الدفع المحلية التي يستخدمها عملاؤك. ونساعدك على تقييم الخيارات وفق متطلباتك.
هل يمكنكم نقلنا من بوابة دفع إلى أخرى؟
نعم. يحتاج النقل إلى خطة للرموز المخزنة والاشتراكات القائمة وإشعارات Webhooks والتقارير، وإلى تحويل محكوم، حتى لا يتأثر العملاء الحاليون.
كيف تختبرون ربط الدفع؟
نختبر في بيئة الاختبار المسارات الناجحة وحالات الرفض والتفويض الجزئي وانتهاء المهلة والطلبات المكررة واحتكاك 3DS. ثم نراجع أسباب الرفض الفعلية بعد إطلاق محكوم.
هل أنت مستعد لنناقش مشروعك؟
احجز مكالمة مدتها 30 دقيقة. نستمع إليك ونطرح الأسئلة الصحيحة، ثم نخبرك بصراحة إن كنا نستطيع مساعدتك وكيف.