رسالة العميل تقول «المبلغ اتخصم»، ولوحة المتجر تقول Pending payment. لا توجد هنا خطوة سحرية اسمها تغيير الحالة إلى مكتمل. المطلوب أولًا معرفة هل توجد عملية صحيحة تخص هذا الطلب، وما حالتها الفعلية، ولماذا لم تنعكس النتيجة في المتجر.
هذا مسار تشخيص عملي لمشكلات المزامنة في WooCommerce، وليس تعليمات لتجاوز تحقق بوابة الدفع. استخدمه لجمع الأدلة وتحديد الجهة المسؤولة عن المشكلة. لا تعتبر صورة من تطبيق العميل أو صفحة شكر دليلًا كافيًا لاتخاذ قرار مالي أو إرسال الطلب دون التحقق من سجل المزود.
حدّد المقصود بكلمة «نجح»
هل ظهرت رسالة نجاح في المتصفح؟ أم توجد عملية في لوحة البوابة؟ وهل حالتها تدل على تحصيل المبلغ أم مجرد تفويض؟ المصطلحات تختلف بين التكاملات، ولذلك ارجع إلى معنى الحالة لدى مزودك. كذلك حجز مبلغ على بطاقة العميل ليس مساويًا بالضرورة لتحصيل نهائي يمكن ربطه بطلب جاهز للتنفيذ.
في WooCommerce تعني Pending payment انتظار الدفع، بينما تكون Processing عادة لطلب مدفوع ينتظر التنفيذ. أما Completed فتدل على اكتمال التنفيذ، وقد تختلف حركة الحالات بحسب نوع المنتج والتكامل. لذلك لا تستخدم Completed كزر إصلاح عام. هذه الحالات تصف مسار الطلب، ولا تغني وحدها عن مراجعة العملية المالية.
اجمع ملفًا صغيرًا للحالة قبل التعديل
احفظ رقم الطلب، ووقت إنشائه، والإجمالي، والعملة، وطريقة الدفع، والمرجع الموجود في ملاحظاته. ثم افتح لوحة المزود وابحث عن العملية المطابقة. استخدم أقل قدر لازم من بيانات العميل، ولا تنسخ معلومات بطاقة أو مفاتيح API في الملاحظات أو صور الدعم.
| العنصر | التحقق المطلوب |
|---|---|
| رقم الطلب | أن المرجع يعود إلى الطلب المقصود لا محاولة أخرى |
| المبلغ والعملة | مطابقة الإجمالي النهائي دون افتراض التشابه |
| وقت العملية | ترتيب المحاولات مع مراعاة المنطقة الزمنية |
| الحساب والبيئة | تمييز حساب الإنتاج عن حساب الاختبار |
| حالة العملية | فهم التحصيل والتفويض والإلغاء وفق المزود |
إذا وجدت عمليتين، لا تختَر الأقرب في الوقت فقط. قد يكون العميل أعاد المحاولة أو فتح أكثر من تبويب. اربط كل محاولة بمرجعها، وحدد إن كانت إحداهما فاشلة أو معلقة أو محصلة. هذه الخطوة تمنع معالجة عملية أخرى بالخطأ أو مطالبة العميل بمبلغ سبق دفعه.
تتبع انتقال النتيجة إلى الموقع
بعد ثبوت العملية، افحص كيف يفترض أن يصل تحديثها: عودة المتصفح، أو Callback، أو Webhook، بحسب التكامل. عودة العميل ومسار الإشعار من الخادم ليسا الشيء نفسه. مثلًا يخصص توثيق MyFatoorah إعداد Webhook لتحديث الحالة عند فقدان أو تأخر العودة؛ راجع الإعداد المقابل في بوابتك.
اكتب تسلسلًا زمنيًا: إنشاء الطلب، إنشاء العملية، تغير حالتها، إرسال الحدث، استجابة الموقع، ثم ملاحظة الطلب. إذا كانت خطوة بلا دليل فابدأ منها. هذا أفضل من إعادة حفظ كل الإعدادات؛ لأنك قد تخفي السبب وتفقد القدرة على تفسير ما حدث في الطلبات السابقة.
هل وصل الحدث أم رُفض قبل وصوله؟
إذا لم يصل الإشعار، راجع الدومين وHTTPS والوجهة المسجلة. فكر في التغييرات الأخيرة: نقل استضافة، أو تغيير دومين، أو تفعيل حماية، أو وضع كلمة مرور على Staging. اطلب من فريق الاستضافة مراجعة الطلب المحدد بوقته ومساره، بدل طلب فتح كل الاتصالات الخارجية.
إذا وصل ورد الخادم بخطأ، اقرأ الرسالة المرتبطة بالحدث. افحص سجل التكامل وأخطاء PHP في التوقيت نفسه. قد تكون المشكلة في بيانات غير متوقعة أو تعارض أو إعداد التحقق. لا تتجاوز فحص توقيع الإشعار ليعمل التحديث؛ أصلح تطابق إعداد التحقق بالطريقة المعتمدة من المزود.
وصل الإشعار، لكن الحالة لم تتغير
هنا تحتاج فحص الربط بين العملية والطلب، وطبيعة الحدث الذي وصل، وأي تخصيص يغيّر الحالات بعد تحديثها. راجع ملاحظات الطلب بالترتيب: هل تغيّرت الحالة ثم أعادها مكون آخر؟ هل الحدث يخص محاولة قديمة؟ هل المبلغ أو العملة مختلفان؟ لا تعالج هذه الحالات كلها بإعادة إرسال الحدث نفسه.
على نسخة اختبار، أعد سيناريو مشابهًا مع أقل عدد من التغييرات اللازمة. إذا ثبت دور تخصيص معين، اختبر إصلاحه مع بقية وظائف المتجر قبل النشر. لا تعتمد كودًا عامًا يضع كل الطلبات في Processing عند زيارة صفحة الشكر؛ بذلك يصبح الوصول لصفحة بديلًا خطيرًا عن تحقق الدفع.
كيف تعالج الطلب المتأثر دون تكرار التحصيل؟
عندما تتأكد من العملية ومطابقتها، استخدم إجراء المزامنة أو استعادة الحالة الذي يقره تكاملك أو دعمه. إن كانت إعادة إرسال حدث متاحة، تحقق من أنها تتعامل مع التكرار بطريقة سليمة ومن أن الحدث الصحيح هو الذي سيعاد. إعادة محاولة دفع جديدة ليست هي إعادة إشعار بعملية موجودة.
إذا احتاج الفريق تعديلًا يدويًا بعد التحقق، وثّق السبب والمرجع ومن اتخذ القرار، واختر الحالة الموافقة لمرحلة الطلب الحقيقية. تأكد من عدم إرسال شحنة أو رسالة مكررة نتيجة إجراء آلي مرتبط بالحالة. معالجة طلب واحد لا تعني أن السبب العام انتهى؛ اختبر الإصلاح قبل متابعة بقية الحالات.
لا تخلط الاسترداد بتصحيح الحالة
يوضح WooCommerce الفرق بين الاسترداد الآلي عبر بوابة تدعمه والاسترداد اليدوي الذي يحتاج تنفيذ حركة المال خارج المتجر. لذلك فإن إظهار Refunded لا يثبت وحده أن الأموال عادت إلى العميل. إذا تقرر الاسترداد، راجع مرجعه ونتيجته لدى المزود، وليس اسم الحالة فقط.
وفي مثال افتراضي لعميل دفع مرتين، افصل بين قرار رد العملية الزائدة وبين إصلاح الطلب الأصلي. احتفظ بمرجع كل عملية، ولا تنفذ الاسترداد من لوحتين في الوقت نفسه. اتفق داخل الفريق على مسؤول واحد للإجراء حتى لا تتحول مشكلة المزامنة إلى مشكلة مالية إضافية.
ما الذي ترسله للدعم؟
أرسل وصفًا مختصرًا قابلًا لإعادة الفحص: الطلب المعني، ومرجع العملية، والوقت مع المنطقة الزمنية، والحالة في كل لوحة، وإصدارات التكامل، ورمز الخطأ بعد تنقيح البيانات الحساسة. أضف التغيير الأخير الذي سبق المشكلة وخطوة الاختبار التي أجريتها. عبارة «البوابة لا تعمل» تؤخر الوصول إلى السبب.
بعد الإصلاح، راجع عينة من الطلبات في الفترة المتأثرة وابحث عن النمط نفسه، ثم أضف السيناريو إلى قائمة اختباراتك عند التحديث. ولمنع أخطاء الإعداد من البداية، راجع دليلي Paymob مع WooCommerce وMyFatoorah مع WooCommerce بحسب مزودك.
المصادر والمراجعة
المعلومات وخطوات الإعداد تعكس الوثائق التالية وقت المراجعة. قوائم الاختبار إرشادات للتطبيق، ولا تعني تنفيذ اختبارات على متجر أو حساب دفع فعلي. راجع توثيق نسختك قبل التنفيذ.
منهجية إعداد المحتوى