الانتقال إلى المحتوى الرئيسي
كل المقالات
دليل9 دقائق قراءة

الدفع في منصات السوق الإلكترونية بالمغرب: الاستخلاص لحساب البائعين، لكل منهم محفظته

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

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

الدفع في منصات السوق الإلكترونية بالمغرب: لماذا يعقّد الوعاء المشترك كل شيء

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

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

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

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

النموذج: كل بائع تاجر فرعي مُدقَّق بمحفظته الخاصة

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

ما يقدّمه لكم النموذج عمليًا:

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

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

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

طلبية واحدة، جلسة واحدة، محفظة واحدة تُقيَّد لها المبالغ

في منصة السوق الإلكترونية، جلسة الدفع هي وحدة العمل. تتحول الطلبية إلى جلسة: تنشئون الجلسة من جهة الخادم، وتعيدون توجيه المشتري إلى صفحة الدفع المستضافة — بالبطاقة مع ‎3-D Secure —، وتتلقون النتيجة عبر ويب هوك موقَّع. وما يميّز هذه الجلسة عن جلسة تاجر عادي يكمن في معامل واحد: config.settlement، الذي يحدّد محفظة التاجر الفرعي التي يُقيَّد لها المبلغ.

مسار الطلبية خطوة بخطوة:

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

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

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

مال كل بائع محدَّد منذ لحظة الاستخلاص

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

ومن جهة أنظمتكم، يتيح لكم مرجعان ربط كل أداء بقاعدة بياناتكم:

  • metadata الخاص بكم، وهو كائن مسطّح ترفقونه بالجلسة — مثلًا { "sellerId": "v_204", "orderNumber": "1042" } — ويعود كما هو في حدث الأداء؛
  • وorderId الخاص بكم، الذي يحمله حدث الجلسة أيضًا.

استرجعوا طلبيتكم إذن بهاتين القيمتين: أما externalId الخاص بالجلسة فلا يعود في الحدث. واحتفظوا في metadata بمعرّفات تقنية — البائع، والطلبية، والسلّة — بدل المعطيات الشخصية للمشتري.

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

التجميع والدفعات والاستردادات

بعد تحديد المال، يبقى تحريكه. ويوفّر فضاء التوزيع أربع لبنات:

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

وتخضع الدفعات لقاعدة الأعين الأربع: من يطلب ليس أبدًا من يوافق، ويُخطَر نظامكم بالنتيجة عبر ويب هوك موقَّع — payout.completed حين تُنفَّذ الدفعة، وpayout.failed حين تفشل. حدّدوا إذن منذ اليوم الأول من يُعدّ الدفعات في فريقكم ومن يوافق عليها.

وإدارة هذه التدفقات — اختيار وتيرة التجميع، والسقوف والتنبيهات، والدفعات، والمطابقة — مفصّلة في مقال التجميع والدفعات داخل الشبكة.

منصات الخدمات: النموذج نفسه لمقدّمي الخدمات

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

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

ثلاث نقاط خاصة بالخدمات:

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

الإعداد مع فريق الإدماج

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

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

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

أسئلة شائعة

كيف أستخلص لحساب عدة بائعين في منصة سوق إلكترونية بالمغرب؟

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

هل يجب تدقيق كل بائع قبل أن يبيع؟

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

هل يمكن إضافة البائعين دفعةً واحدة؟

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

كيف يؤدّي المشتري ثمن طلبيته؟

بالبطاقة، في صفحة الدفع التي تستضيفها ChariPay، مع ‎3-D Secure: يؤكّد حامل البطاقة العملية لدى بنكه. وتُقبل افتراضيًا Visa وMastercard وMaroc Pay. ينشئ خادمكم الجلسة، ويعيد توجيه المشتري، ثم يؤكد الطلبية عند استلام الويب هوك الموقَّع. والجلسة لا تستخلص إلا بالبطاقة؛ أما النقد في الوكالة فيمرّ بأداة أخرى هي رابط الدفع لاستعمال واحد.

ما الوثيقة التي يتلقاها كل بائع؟

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

هل أحتاج إلى مطوّر لربط منصة سوق إلكترونية؟

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

هل يمكن لمنصة خدمات أن تطبّق النموذج نفسه على مقدّمي خدماتها؟

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

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

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

بقلم فريق ChariPay.

اقرؤوا بعده

مستعدون للتجربة بأنفسكم؟

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

  • مجاني ودون التزام
  • وضع الاختبار منذ التسجيل
  • لا موافقة تنتظرونها