الدفعات للتجار الفرعيين والتجميع التلقائي للأموال: إدارة أموال الشبكة

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

مسار المال داخل الشبكة

ChariPay منصة دفع مغربية، مزوّد خدمات دفع (PSP) تشغّله Chari Money، مؤسسة أداء مرخَّصة من بنك المغرب. وفضاء التوزيع فيها موجَّه إلى المجمِّعين وشبكات الامتياز وشبكات الوكلاء. وأيًّا كانت الشبكة، يسلك المال فيها الطريق نفسه:

1. 1يؤدّي زبون تاجرٍ فرعي. والآلية المنشورة لتحديد المحفظة التي يُقيَّد لها المبلغ هي المعامل config.settlement في جلسة الدفع؛ أما أدوات الاستخلاص الأخرى، كالروابط، فتُعالَج مسألتها عند الإعداد.
2. 2يُقيَّد المبلغ في محفظة التاجر الفرعي. وتتبع المستخلصات التوزيع المحدَّد عند إعداد الشراكة؛ ولا يُجمَع شيء في وعاء مشترك.
3. 3يغذّي التجميع التلقائي حساب التجميع الخاص بكم، يوميًا أو أسبوعيًا.
4. 4تنطلق الدفعات بموافقة مزدوجة: فالطالب والموافِق مختلفان دائمًا.
5. 5يُعَدّ لكل تاجر فرعي كشف شهري، وتطابقون المجموع بفضل المراجع التي تحملها كل حركة.

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

وقبل الإعداد، يمكنكم رؤية ما يبدو عليه حساب الأداء وحركاته وتصدير CSV الخاص به: ابدؤوا في وضع الاختبار. ثلاثة حقول — الاسم، والبريد الإلكتروني المهني، والمؤسسة — ثم رابط تفعيل يصلكم بالبريد لاختيار كلمة المرور، ثم بوابة التاجر حيث تنشئون بأنفسكم مفتاح الاختبار. هناك تُجرون أداءات ببطاقة الاختبار وتصدّرون الحركات، دون أي مال حقيقي. الأمر مجاني، بلا حد زمني ودون موافقة تنتظرونها: ولا يشترط التحقق من مؤسستكم (KYB) إلا الانتقال إلى الإنتاج. أما فضاء التوزيع نفسه فيُحضَّر مع فريق الإدماج.

التجميع التلقائي للأموال: يومي أو أسبوعي

يتم التجميع التلقائي نحو حساب التجميع الخاص بكم، بوتيرة يومية أو أسبوعية. ولا ننشر عنه معيارًا آخر؛ والأهم أنه لا إجراء يوميًا عليكم القيام به لتركيز مال الشبكة.

ويتم اختيار الوتيرة عند الإعداد، مع فريق الإدماج. ويتوقف على أمرين: إيقاع استخلاص نقاط البيع لديكم، وحاجاتكم من الخزينة على المستوى المركزي.

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

سقوف الرصيد وتنبيه submerchant.near_cap

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

وحين يقترب تاجر فرعي من سقفه، يتلقى نظامكم الحدث submerchant.near_cap عبر ويب هوك موقَّع. وما يُعقل فعله حينها:

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

ولتلقّي هذا الحدث، يجب أن تكون نقطة استقبال الويب هوك مشتركة فيه؛ ويُستحسن اعتماد لائحة صريحة من الأحداث، إذ تعني اللائحة الفارغة الاشتراك في كل الأحداث. والتصريح بنقطة الاستقبال، والتوجيه حسب الترويسة Chari-Event-Type، وإزالة التكرار على Chari-Event-Id، كلها مفصّلة في التجار الفرعيون عبر API.

الدفعات للتجار الفرعيين: طالب واحد وموافِق واحد

تخضع كل دفعة لموافقة مزدوجة: فالطالب والموافِق مختلفان دائمًا. ومن يطلب ليس أبدًا من يوافق. وهي القاعدة نفسها المطبَّقة على كل العمليات الحساسة في المنصة — الدفعات، والتسويات، وتجميد الحسابات — وتستند إلى بقية المنظومة: فسجل التدقيق مسلسل تشفيريًا، ولا يمكن إعادة كتابة التاريخ؛ ويُحمى الوصول إلى بوابة التاجر بالمصادقة الثنائية (TOTP)، وإعادة المصادقة قبل كل عملية حساسة، وجلسات مؤمَّنة.

أما ما يعود إليكم فهو التنظيم البشري:

1. 1عيّنوا من يُعدّ الدفعات ومن يوافق عليها، في وظيفتين مختلفتين — إدارة الشبكة من جهة والإدارة المالية من جهة أخرى، مثلًا.
2. 2عيّنوا بديلًا لكل موافِق، حتى لا يعطّل غيابه المسار.
3. 3اسحبوا دون تأخير صلاحيات أي متعاون يغادر الفريق.

وتصلكم نتيجة كل دفعة عبر ويب هوك موقَّع: payout.completed حين تُنفَّذ، وpayout.failed حين تفشل. اربطوا الثاني بتنبيه للفريق المالي، وحلّلوا الفشل قبل طلب أي شيء من جديد. ولا نصف هنا طريقة احتساب الدفعة: فهي تتبع التوزيع المحدَّد عند إعداد الشراكة. أما ضوابط الوصول نفسها — المصادقة الثنائية، والموافِقون، والسجل — فمفصّلة في تأمين الوصول إلى بوابة التاجر.

حملات الاسترداد الجماعية

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

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

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

أما الاسترداد الفردي — زبون واحد وطلبية واحدة — فمسطرته موصوفة في استرداد مبلغ لزبون.

الكشف الشهري لكل تاجر فرعي

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

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

وإن ظهر فارق بين كشف تاجر فرعي ومجاميعكم، فابحثوا أولًا عن مشكلة فترة — أداء في آخر الشهر مؤرَّخ بتوقيت UTC — أو مشكلة ربط: فالمراجع تحسمها.

مطابقة تدفقات الشبكة

تحمل كل حركة في الحساب مرجع البيع أو الاسترداد أو الدفعة التي تفسّرها؛ وتميّز بوابة التاجر بين المبلغ المدفوع والرسوم والصافي، ويحتفظ تصدير CSV بهذه المراجع — من بوابة التاجر أو عبر GET /v1/transactions/export.csv (حتى 10 000 سطر؛ وفوق ذلك قسّموا حسب الفترة بـfrom/to). والطوابع الزمنية بتوقيت UTC؛ والمغرب على UTC+1: فعلى أداة المطابقة لديكم أن تحوّل.

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

أسئلة شائعة

بأي وتيرة يتم التجميع التلقائي للأموال؟

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

هل يمكن أن تنطلق دفعة دون موافقة؟

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

ماذا يحدث حين يقترب تاجر فرعي من سقفه؟

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

كيف أعرف أن دفعة قد فشلت؟

عبر الحدث payout.failed الذي يُرسل بويب هوك موقَّع؛ أما الدفعة المنفَّذة فتُرسل payout.completed. اشتركوا بنقطة الاستقبال في الحدثين، ووجّهوا حسب الترويسة Chari-Event-Type، وأزيلوا التكرار على Chari-Event-Id. اربطوا الفشل بتنبيه للفريق المالي، وحلّلوا سببه قبل طلب دفعة جديدة. ولا تعيدوا المحاولة آليًا: فكل طلب جديد يمرّ مرة أخرى بالموافقة المزدوجة.

هل يمكن الاسترداد لزبناء كثيرين دفعة واحدة داخل الشبكة؟

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

هل يتلقى كل تاجر فرعي كشفًا؟

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

كيف أطابق مستخلصات شبكة كاملة؟

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

الخطوة التالية

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