العميل دفع، لكن فريق المتجر لا يعرف هل يبدأ تجهيز الطلب. هذه هي الفجوة التي يجب أن يمنعها ربط Paymob الجيد: رحلة واضحة للعميل، ونتيجة قابلة للتحقق داخل المتجر، ومرجع يمكن الرجوع إليه عند حدوث مشكلة.
الدليل التالي يشرح الإعداد الأساسي ثم يقترح خطة قبول قبل الإطلاق. لم تُنفذ معاملات على حساب تاجر ضمن إعداد هذا المقال. أسماء بعض الحقول قد تتغير بين الإصدارات، لذلك طابق شاشة إضافتك مع التوثيق الرسمي المرتبط في المصادر، ولا تخلط شرح إضافة قديمة مع نسخة أحدث.
جهّز معلومات الحساب ونسخة الاختبار
قبل تثبيت الإضافة، حدّد بلد الحساب، والعملة المستخدمة في المتجر، ووسائل الدفع المطلوب تشغيلها. راجع مع Paymob أن الحساب مؤهل ومفعّل للوسائل المطلوبة؛ ظهور اسم الوسيلة في موقع الشركة لا يضمن إتاحتها لكل حساب. احتفظ بتأكيد التفعيل لدى الشخص المسؤول عن إدارة المدفوعات.
جهّز نسخة Staging بإعدادات قريبة من الموقع الفعلي، مع HTTPS وخطة رجوع واضحة. سجّل إصدارات WordPress وWooCommerce والقالب ونوع صفحة Checkout. وإذا كان لديك تكامل سابق، وثّق إعداداته قبل أي تغيير، ولا تشغّل مسارين للوسيلة نفسها دون فهم تأثيرهما في إنشاء العمليات وتحديث الطلبات.
ثبّت الإضافة الرسمية واربط الحساب
وفق دليل Paymob، يمكنك تثبيت Paymob for WooCommerce من إضافات WordPress أو تنزيلها عبر WooCommerce Marketplace. بعد التفعيل افتح Paymob Settings. الربط متاح بتسجيل الدخول إلى حساب Paymob والتحقق، أو عبر Manual Setup باستخدام API Key وPublic Key وSecret Key.
من الإعدادات الرئيسية اختر Test أو Live. وفي Payment Configurations راجع تفعيل الوسائل ومعرّفات Integration ID وروابط Webhook. ويميّز الدليل بين Unified Checkout الذي يعيد التوجيه، وPixel المدمج. اختر مسارًا يلائم الحساب والتصميم، ثم اختبره وحده أولًا قبل إضافة خصائص أخرى.
هذه الخطوات تختصر مواضع الإعداد؛ لا تنشر المفاتيح في لقطة شاشة ولا تضع المفاتيح السرية في كود الواجهة. سلّم صلاحية الإدارة لمن يحتاجها فقط، واحفظ بيانات الوصول في وسيلة آمنة يستخدمها فريقك. إذا اختلف اسم حقل، ارجع إلى دليل النسخة بدل تخمين أي قيمة تشبه اسمه.
افصل Test عن Live بوضوح
اصنع بطاقة إعداد بسيطة تتضمن: اسم الموقع، والبيئة، والحساب، والوسائل المفعّلة، وتاريخ آخر تعديل. لا تكتب الأسرار في البطاقة. الغرض أن يستطيع زميلك معرفة هل يختبر متجرًا تجريبيًا أم يعدّل المتجر الحقيقي قبل الضغط على حفظ.
استخدم بيانات الاختبار التي يوفرها المزود للبيئة المخصصة لذلك. لا تعتبر بيانات بطاقة عشوائية اختبارًا صالحًا، ولا تعتبر نجاح فتح صفحة الدفع دليلًا على إتمام عملية. افحص النتيجة من الطرفين: الطلب في WooCommerce والعملية في لوحة Paymob، مع تطابق المبلغ والعملة والمرجع.
راجع إجمالي الطلب قبل إرسال العميل للدفع
ابدأ بمنتج بسيط، ثم أضف الحالات التي يستخدمها متجرك: منتج متغير، وكوبون خصم، وشحن، وسلة تحتوي أكثر من منتج. قارن الإجمالي الظاهر للعميل بالإجمالي الذي يصل إلى عملية الدفع. إذا ظهر اختلاف، أوقف اختبار الإطلاق وحدّد مرحلة الحساب التي تغيرت بدل تعديل المبلغ يدويًا لتجاوز المشكلة.
في مثال افتراضي، متجر يضيف سعر الشحن بعد تغيير المحافظة. السيناريو المطلوب هنا أن يغيّر المختبِر العنوان ثم يتأكد من تحديث الإجمالي قبل إنشاء العملية. هذا اختبار لتكامل متجرك كله، وليس ادعاءً بوجود مشكلة عامة في Paymob أو في إضافة الشحن.
اختبر رحلة العميل والطلب معًا
| الحالة | ما تراجعه في الواجهة | ما تحفظه للتشخيص |
|---|---|---|
| دفع ناجح تجريبيًا | نتيجة واضحة وعودة سليمة | مرجع العملية وحالة الطلب |
| رفض الدفع | رسالة مفهومة وإمكانية التصحيح | سبب الرفض المتاح دون بيانات حساسة |
| إلغاء العميل | عدم إيهامه بنجاح العملية | حالة العملية والطلب بعد العودة |
| تأخر الاستجابة | منع المحاولات العشوائية المتكررة | وقت الحدث والسجلات المرتبطة |
نفّذ السيناريوهات من الهاتف ومن جلسة زائر غير مسجل. راجع اتجاه العربية، وعدم تغطية زر الدفع بعناصر عائمة، ووضوح حالة الانتظار. إذا كان المتجر يتيح الشراء للمسجلين فقط، اختبر حساب عميل حقيقي الصلاحيات بدل الاعتماد على جلسة المدير.
ماذا تراجع إذا لم تتحدث حالة الطلب؟
ابدأ بمرجع العملية، ثم إعداد Webhook الخاص بالتكامل. يوضح دليل WooCommerce أن إعداد Webhook جزء من الربط، وأن الوسائل المدمجة مثل Apple Pay وGoogle Pay تحتاج تحققًا من تفعيلها مع مدير الحساب. لا تضف وسيلة لمجرد أن زرها موجود إذا لم تُستكمل متطلباتها.
قارن وقت إنشاء العملية بوقت وصول الحدث في سجلات الموقع. هل وصل الطلب إلى الدومين الصحيح؟ هل رد الخادم بخطأ؟ هل منعته قاعدة حماية؟ اجمع دليلًا قبل تعديل الإعدادات، واطلب من الاستضافة فحص الطلب المحدد إذا كانت المشكلة في الوصول. لا تعطل الحماية كلها كتجربة على الموقع الحي.
الانتقال للإطلاق وتسليم التشغيل
بعد قبول الاختبارات، راجع إعداد Live وبياناته ووسائله كلًّا على حدة. نجاح Test لا يفعّل الحساب التجاري تلقائيًا. أي تحقق بمعاملة حقيقية يحتاج اتفاقًا مع صاحب المتجر على المبلغ وطريقة المتابعة؛ لا تصفه باختبار مجاني لأن له حركة مالية فعلية.
سلّم الفريق طريقة البحث برقم الطلب والعملية، وخطوات تصعيد المشكلة، ومن يملك قرار الاسترداد. راقب الطلبات الأولى بعد الإطلاق حتى تتأكد أن ما اختبرته يعمل في البيئة النهائية. احتفظ بإجراء رجوع يوقف الوسيلة المتأثرة عند الحاجة مع توضيح البدائل المتاحة للعميل.
هل أغيّر الطلب يدويًا إذا ظهرت رسالة نجاح؟
لا تعتمد على الرسالة وحدها. طابق سجل البوابة مع الطلب، وتحقق من طبيعة حالة العملية، ثم عالج سبب عدم المزامنة. ستجد مسار تشخيص مفصلًا في الدفع نجح والطلب ما زال معلقًا، بينما يساعدك دليل اختيار البوابة إذا لم تحسم التكامل المناسب بعد.
المصادر والمراجعة
المعلومات وخطوات الإعداد تعكس الوثائق التالية وقت المراجعة. قوائم الاختبار إرشادات للتطبيق، ولا تعني تنفيذ اختبارات على متجر أو حساب دفع فعلي. راجع توثيق نسختك قبل التنفيذ.
منهجية إعداد المحتوى