دفتر تسوية بوابات الدفع للمتاجر الإلكترونية

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

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

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

سجّل البنك المركزي السعودي 1.77 مليار معاملة تجارة إلكترونية باستخدام بطاقات مدى في 2025، بقيمة 325.2 مليار ريال. وفي 2021 كان العدد 347.7 مليون عملية بقيمة 74.3 مليار ريال. تضاعف العدد 5.1 مرة، بينما تضاعفت القيمة 4.4 مرة تقريباً. (sama.gov.sa)

هذا الفرق مهم للتشغيل: متوسط قيمة المعاملة المحسوب من بيانات مدى انخفض من نحو 214 ريالاً في 2021 إلى نحو 184 ريالاً في 2025. لا يُستخدم الرقم بديلاً عن متوسط سلة متجر بعينه، لكنه يوضح اتجاه الضغط؛ معاملات أكثر، وأسطر أكثر، واستثناءات محتملة أكثر، من دون نمو مماثل في قيمة كل عملية.

وفي السوق الأوسع، ارتفعت حصة المدفوعات الإلكترونية من عمليات التجزئة من 62% في 2022 إلى 85% في 2025. لم يعد ملف التسويات عملاً خلفياً يؤجل إلى نهاية الشهر؛ إنه بنية تشغيل يومية لسوق أصبحت فيه الدفعة الرقمية هي المسار الغالب. (sama.gov.sa)

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

وثائق Stripe تصف تقرير مطابقة الدفعات بأنه وسيلة لربط المبالغ الواصلة إلى البنك بدفعات العمليات التي كوّنتها، مع تفاصيل الإجمالي والرسوم والصافي وفئات الحركة. وتربط التسويات الآلية كل حركة بمعرّف الدفعة ذات الصلة. كما يقدّم تقرير PayPal للمطابقة صفاً لكل عملية، متضمناً الرسوم ووسيلة الدفع ومعلومات التسوية ومعرّف التحويل. هذه أمثلة على بنية التقرير، وليست توصية بمزود أو إثباتاً لتوافر الخصائص نفسها في كل بلد أو عقد. (docs.stripe.com)

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

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

ينشأ الطلب في المتجر، ثم تمر الدفعة بحالات قد تشمل الإنشاء والتصريح والالتقاط والتسوية، بحسب تصميم المزود ووسيلة الدفع. بعد ذلك قد يحدث استرداد أو اعتراض كحركة جديدة تؤثر في الرصيد. وثائق Stripe، مثلاً، تعامل كل حركة تؤثر في الرصيد كسجل مستقل، وتربط الاسترداد بحركة تعاكس الأصل بدلاً من محو العملية السابقة. (docs.stripe.com)

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

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

• order_id: هوية الطلب داخل منصة التجارة.
• payment_id: هوية محاولة أو عملية الدفع لدى المزود.
• settlement_id أو payout_id: هوية الدفعة المجمّعة.
• bank_reference: مرجع الإيداع الظاهر في الحساب البنكي.
• original_payment_id: مرجع الأصل لأي استرداد أو تعديل لاحق.

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

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

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

• إجمالي العمليات الملتقطة
• ناقص الاستردادات
• ناقص الرسوم
• زائد أو ناقص التعديلات
• يساوي صافي الدفعة المتوقعة مع تفسير الرصيد المتبقي

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

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

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

• نسبة الحركات المطابقة في الموعد المحدد.
• قيمة الفروقات المفتوحة وعدد أيام بقائها.
• الهامش المطابق بحسب البوابة ووسيلة الدفع والقناة.
• عدد الطلبات المشحونة قبل اكتمال حالة الدفع المعتمدة داخلياً.