دمج بوابات الدفع في دبي (دليل 2026)

ابدأ بنموذج التاجر قبل اختيار بوابة الدفع#

حدّد من يبيع للعميل، والجهة التي تستلم المال، وبلد التاجر، والعملات والمنتجات ومسؤولية الاسترداد. تختلف متطلبات اعتماد وتشغيل بائع واحد عن الاشتراكات أو السوق متعدد البائعين. دعم المزوّد ميزة في بلد ما لا يثبت تفعيلها لحسابك.

هذا الدليل طريقة تخطيط وقبول؛ ولا يمنح اعتمادًا للترخيص أو PCI أو الأهلية أو الالتزامات القانونية. تحقّق منها مع المزوّد والجهة المحصّلة والمختص المناسب لتدفق الأموال الفعلي قبل الإطلاق.

جهّز أسئلة للمزوّد#

اطلب شروطًا تجارية مؤرخة بدل الاعتماد على نسبة «معتادة» أو وعد تسوية في مقال. المدة المقدرة للاعتماد ليست ضمان إطلاق. احفظ الإجابات وتاريخ سريانها مع مواصفات التكامل.

قلّل التعامل غير الضروري مع بيانات البطاقة#

ادرس صفحة دفع مستضافة أو مكونات معتمدة حتى لا يحتاج التطبيق إلى استقبال بيانات البطاقة الخام. يحدد التنفيذ وبيئة التاجر المسؤوليات المطبقة؛ الحقول المستضافة لا تثبت تلقائيًا أهلية استبيان امتثال بعينه. أكّد النطاق مع الجهة المحصّلة أو مختص مؤهل.

احتفظ بالأسرار في الخادم وافصل مفاتيح الاختبار والإنتاج. قيّد الوصول وحدّد إجراء تبديل المفاتيح. لا تجمع أرقام البطاقات في نماذج الاستفسار أو السجلات أو أحداث التحليلات أو صور الدعم.

حدّد عمل التطبيق#

زر الدفع جزء من العمل. حدّد حالات الطلب والتأكيد والإلغاء والإشعار المتأخر والاسترداد والمطابقة وصلاحيات الموظف وخدمة العميل. للاشتراكات، عرّف التجديد والمحاولة الفاشلة وتغيّر صلاحية الخدمة. ولعدة بائعين، احسم تدفق الأموال والمسؤوليات المعتمدة قبل بناء الصرف؛ منتج الحسابات المرتبطة ليس إعفاءً قانونيًا عامًا.

يحتاج الدفع بلغتين مبالغ وعملات صحيحة ومدخلات مختلطة الاتجاه وأخطاء مفهومة وعودة مكافئة. اختبر الطريقة المفعلة على الجهاز المقصود بدل الاكتفاء بعبارة «يدعم العربية».

راجع تطوير المتاجر للواجهة التجارية، وتطبيقات الويب للإجراءات التشغيلية. استخدم دليل الميزانية لفصل التنفيذ عن رسوم المزوّد والصيانة.

حدّد حالات الدفع قبل ربط صفحة الدفع#

اكتب الحالات أولًا: طلب جديد، انتظار دفع، دفع معلّق، مدفوع، فاشل أو ملغى؛ ثم استرداد مطلوب أو معلّق أو فاشل أو مؤكد. عودة المتصفح إلى صفحة نجاح لا تكفي لاعتبار الطلب مدفوعًا. حدّد التأكيد المرجعي من خادم المزوّد وتحقق من توقيعه والحساب المقصود.

تحوّل المصفوفة أدناه المتطلبات إلى حالات اختبار. إنها خطة قبول تجريبية فارغة، وليست إثباتًا بأن تكاملًا أو حساب تاجر اجتاز الاختبارات.

مخطط توضيحي لحالات التطبيق#

هذا نموذج لتصميم السلوك، وليس وصفًا حرفيًا لواجهة مزوّد بعينه ولا نتيجة اختبار منفّذ. احتفظ بسجل الدفع وسجل الاسترداد منفصلين؛ طلب الاسترداد لا يمحو تاريخ عملية الدفع المؤكدة.

تستخدم الشيفرة أسماء حالات ثابتة لتجنّب التباس اتجاه الأسهم؛ يشرح الجدول معناها والإجراء المطلوب بالعربية.

PAYMENT:
awaiting_payment -> pending -> paid
                        |-> failed / cancelled
                        |-> review_required
 
REFUND:
requested -> pending -> confirmed
                 |-> failed

عرّف الاسترداد الجزئي وتعدد المحاولات صراحة. يسجل الاسترداد المبلغ المطلوب والمبلغ المؤكد؛ ووسم «مسترد» وحده لا يشرح كل رصيد جزئي. تحتاج إعادة الطلب إلى آلية لمنع تكرار الأثر يدعمها المزوّد المختار. اختبر انتقال الحالة ورسالة العميل كلًا على حدة في اللغتين.

يوضح توثيق Stripe للإشعارات التحقق من التوقيع والتعامل مع تكرار الحدث في Stripe. للمزوّدين الآخرين بروتوكولاتهم؛ استخدم توثيق المزوّد وإعداد التاجر المعتمد بدل افتراض تطابق الحقول والضمانات.

افصل القبول التقني عن اعتماد التاجر#

اختبر بمعرّفات تجريبية وبيانات غير حساسة. سجّل إصدار API والبيئة ومرجع الطلب أو الحدث والمتوقع والفعلي. يجب تأكيد أهلية التاجر ومفاتيح الإنتاج والعملات والمحافظ وشروط التسوية والاسترداد بصورة مستقلة قبل الإطلاق. لا تضع أسرارًا أو بيانات بطاقات أو عملاء حقيقيين في الورقة.

طابق مراجع الطلب والدفع والاسترداد والتسوية؛ فهي سجلات مترابطة لكنها لا تعني الشيء نفسه. اختبر الرحلة بالعربية والإنجليزية بما فيها الأخطاء والعودة للمتجر. أرسل بلد التاجر والمنصة ومتطلبات الدفع لتحديد نطاق المتجر أو تكامل تطبيق الويب.