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