كيف يمكن تجنب خصم المبلغ مرتين للطلب بعد دمج الدفع في المتجر الإلكتروني عابر الحدود؟

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

أولًا، ميّز بين تكرار الإشعارات والخصم الفعلي مرتين

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

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

تكامل الدفع في نظام المتجر الإلكتروني عبر الحدود: يجب أن يرتبط مفتاح عدم التكرار بعملية الأعمال نفسها

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

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

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

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

منع الطلبات المتزامنة أهم من تعطيل الزر

يمكن أن يقلل تعطيل الزر من الأخطاء، لكنه لا يمنع الإرسال المتكرر من عدة علامات تبويب أو الأجهزة المحمولة أو الاستدعاء المباشر للواجهة. يجب أن يضمن النظام الخلفي القيود الأساسية في قاعدة البيانات، مثل تفرد رقم محاولة الدفع، وتفرد رقم المعاملة لدى القناة ضمن حساب التاجر المعني، وعدم إنشاء عدة محاولات دفع نشطة للطلب نفسه من دون قواعد واضحة.

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

يُنصح بتصميم سير العمل على النحو التالي: التحقق من الطلب وإنشاء محاولة دفع → الاتصال ببوابة الدفع → حفظ النتيجة الواردة → انتظار الإشعار أو الاستعلام النشط → تحديث الطلب بشروط محددة. وعادةً لا يُنصح بإبقاء معاملة قاعدة البيانات مفتوحة مدة طويلة أثناء استدعاء خدمة دفع خارجية.

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

يجب أن تكون معالجة إشعارات رد الاتصال «قابلة للاستلام المتكرر، لكن لا تُطبّق إلا مرة واحدة»

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

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

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

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

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

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

يركز القبول التقني على سلوك النظام بعد وقوع الأعطال

عند تقييم حلول الدفع للمتاجر الإلكترونية العابرة للحدود، يُنصح بطلب عرض السيناريوهات التالية، لا الاكتفاء بإتمام عملية دفع عادية واحدة:

• إذا قبلت بوابة الدفع الطلب لكن انتهت مهلة الواجهة، فهل تظل إعادة المحاولة مرتبطة بالمعاملة الأصلية؟
• إذا حاولت صفحتان إتمام الدفع في الوقت نفسه، فهل يمنع النظام إنشاء محاولات دفع مكررة غير خاضعة للرقابة؟
• إذا تكرر إشعار النجاح أو وصل بترتيب غير صحيح، فهل تُسجل المعاملة مرة واحدة فقط ويُنفّذ الشحن مرة واحدة فقط؟
• إذا تعطلت الخدمة بعد الخصم وقبل حفظ السجل في قاعدة البيانات، فهل يمكن استعادة الحالة من خلال الاستعلام ومطابقة السجلات؟
• إذا وصلت المعاملة القديمة بنجاح بعد تغيير القناة ونجاح المعاملة الجديدة، فهل يمكن تحديد المبلغ الزائد المحصّل والتعامل معه؟

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