الجواب القصير. بطاقة الزبون لا تدخل تطبيقكم أبداً: ينشئ خادمكم طلبية معلَّقة بمبلغ محسوب عنده، ويسجّلها عند البوابة، ويرسل الزبون إلى صفحة الدفع الخاصة بها. وحين يعود الزبون إلى موقعكم، فهذه العودة إشارة لا دليل: يسأل خادمكم البوابة عن الحالة الحقيقية، أو يتلقى webhook موقَّعاً، وعندها فقط تصير الطلبية مدفوعة. لكل طلبية مفتاح عدم تكرار كي لا تخصم النقرة المزدوجة أو الـ webhook المستلَم مرتين ولا تُعدّ مرتين. وكل أسبوع يُطابَق كشف البنك مع الطلبيات، والاسترداد يمر عبر واجهة البوابة لا عبر تحويل يدوي أبداً. عشرة أسابيع، اثنان منها تجريب بمبالغ صغيرة.
هذا الدليل موجّه إلى التاجر أو المسيّر الذي يريد التحصيل بالبطاقة في تطبيقه أو متجره، وإلى المؤسس المقيم في فرنسا الذي يريد البيع بالدينار لزبائن في الجزائر، وإلى المسؤول الذي يجب أن يقارن عرض سعر «دمج الدفع» بآخر. لا يعيد أي نموذج اقتصادي نختار، الموصوف في دليل المنصة التجارية ودليل SaaS، ولا كيف نحصّل عند الكاونتر، الموصوف في دليل الصندوق؛ بل يصف ما يُبنى بين تطبيقكم والبوابة، ويمدّ صفحتنا عن هندسة البرمجيات.
ما تقوله الوثائق
المدخل إداري قبل أن يكون تقنياً، وهو علني. تصف بوابة CIBWEB التابعة لـ GIE Monétique مسار التاجر: إنشاء حساب وإيداع طلب «يعالجه التجمع ويبتّ في قبوله في أقل من 24 ساعة» بعباراته هو؛ اجتياز «الاختبارات التقنية للدمج في منصة الدفع الإلكتروني»؛ الحصول على «ترخيص الدخول في الاستغلال». وشروط الأهلية التي تعرضها هي التسجيل في السجل التجاري أو سجل الحرف والتسجيل في البطاقية الوطنية للموردين الإلكترونيين. وما يفرضه ذلك: نتحقق من التسجيلين في الأسبوع الأول قبل كتابة أي سطر، ومدة مرحلة الاختبارات تُطلب كتابةً لأن البوابة لا تعطيها.
الآلية التقنية هي آلية صفحة دفع مستضافة، موثَّقة من أطراف ثالثة. تصف الوثائق غير الرسمية لبوابة SATIM التي قرأناها تسجيل طلبية يعيد معرّفاً وعنوان صفحة دفع، ومبلغاً «مضروباً في 100» قبل الإرسال، وحداً أدنى 50 ديناراً، وعنوان عودة وعنوان فشل، ثم تأكيداً في الخادم يعيد الحالة ورمز إجراء ورمز موافقة. وتميّز بيئة اختبار وبيئة إنتاج. نقول ذلك بحذر: إنها وثائق طرف ثالث، والمعاملات الدقيقة تُعاد قراءتها في دليل الدمج الذي يسلّمه بنككم أو مدمجكم. وما يفرضه ذلك: الهندسة نفسها أياً كان المزوّد، طلبية عندكم، صفحة عندهم، تأكيد من المصدر.
المجمّعون يوثّقون الجزء الذي تنساه المتاجر: الإشعار. تصف وثائق مجمّع جزائري يدعم CIB والذهبية webhook يُرسل عبر HTTPS بنوع حدث، «checkout.paid» مثلاً، وتوقيع HMAC-SHA256 للنص الخام للطلب محسوباً بمفتاحكم السري، ورداً 200 منتظَراً من خادمكم، ومفاتيح اختبار ببادئة، وحقلاً يميّز الوضع الحقيقي من وضع الاختبار؛ وتوضح أن الـ webhook لا يستطيع الوصول إلى خادم محلي، ومن هنا النفق أثناء التطوير. وما لم نجده: شبكة رسوم رسمية، أجل تحويل منشور، سياسة إعادة إرسال webhooks؛ الثلاثة تُطلب كتابةً، والأدلة الخارجية التي تذكر نسباً تتناقض، ولهذا لا نذكر أياً منها.
دفعة واحدة، من شاشة الزبون إلى كشف البنك
الدفع لا يُفهم على مخطط واجهة بل على مسار دفعة حقيقية، وعلى المحطة التي يحق فيها تصديقه.
المحطة الأولى، عندكم: يصادق الزبون على سلته، فيجمّد خادمكم السطور ويحسب المبلغ وينشئ الطلبية معلَّقة برقم ومفتاح عدم تكرار، ويسجّلها عند البوابة مرسلاً إليها المبلغ؛ خادمكم هو من يقول المبلغ، لا الشاشة أبداً. الثانية، عند البوابة: يُرسل الزبون إلى صفحة دفعها، الوحيدة التي ترى البطاقة. الثالثة، على هاتف الزبون: يُدخل بطاقته CIB أو الذهبية والرمز المستلَم بالرسالة القصيرة حسب مسار بنكه. الرابعة، العودة: يعود المتصفح إلى عنوان النجاح عندكم بمعرّف في الرابط. هذه هي الإشارة. تصل أحياناً قبل الدفع، وأحياناً بعده، وأحياناً لا تصل أبداً.
المحطة الخامسة، الوحيدة التي تهم: يسأل خادمكم البوابة عن حالة الطلبية، أو يتلقى الـ webhook الموقَّع، ويقرأ «مدفوع» من المصدر. هذا هو الدليل، وهنا فقط تغيّر الطلبية حالتها. السادسة: مدفوعة، وصل مُرسَل على WhatsApp والبريد وفق دليل الإشعارات، مخزون محجوز. ثم بعد يوم إلى ثلاثة أيام يظهر سطر في كشف البنك المستحوذ، صافياً أو قبل العمولة حسب عقدكم، وتربطه المطابقة برقم الطلبية؛ وما لا يتطابق يصير سؤالاً يُطرح على البنك لا فارقاً يُكتشف عند الإقفال.
«عودة المتصفح هي ما يُرى أولاً ويُصدَّق آخراً.»
الدفع الإلكتروني في تطبيق، في خمس طبقات
خلف هذه المحطات الست خمس طبقات، وواحدة فقط تخصكم حقاً.
الشاشة: السلة، زر الدفع، صفحة الانتظار، صفحتا النجاح والفشل؛ تعرض الحالة ولا تقررها أبداً، وشاشة نجاح تقول «مدفوع» لأن الرابط يحتوي كلمة نجاح هي أول عيب نصلحه. خادمكم: الطلبية وآلة حالاتها، المبالغ المحسوبة في الخادم، مفتاح عدم التكرار، السجل؛ الطبقة الوحيدة التي تكتب «مدفوعة»، وبعد التحقق من المصدر فقط. البوابة: صفحة الدفع المستضافة، التسجيل، الحالة، الاسترداد؛ SATIM مباشرة عبر بنككم، أو مجمّع يحمل العقد والصفحة؛ البطاقة لا تعبر الحدود بين هذه الطبقة وطبقتكم أبداً.
البنك والشبكة: البنك المستحوذ الذي يدفع لكم، البنك المصدر للزبون، الشبكة البينية للبنوك، GIE Monétique الذي يرخّص؛ الرسوم وأجل التحويل والعقد تُتفاوَض هنا، ولا سطر كود يغيّرها. الإشراف: مطابقة الكشف ↔ الطلبيات، الطلبيات المعلَّقة طويلاً، webhooks المرفوضة لتوقيع غير صالح، استردادات الشهر؛ شاشة تُقرأ كل أسبوع تُبنى مثل لوحة قيادة المسيّر. والاختيار بين SATIM مباشرة ومجمّع يُتخذ كتابةً في الأسبوع الأول مع رسوم كل منهما وأجل تحويله، ولا يغيّر شيئاً في الطبقتين الثانية والخامسة: وهذا سبب كتابة آلة الحالات قبل وصل أي أحد.
حالات الطلبية، وما يحق له تغييرها
آلة الحالات هي قلب الدمج، والرسم الذي يُعاد قراءته مع الزبون قبل أول سطر.
سبع حالات. أُنشئت: السلة مجمَّدة والمبلغ محسوب. في انتظار الدفع: الطلبية مسجَّلة عند البوابة والصفحة مفتوحة. مدفوعة: قُرئت الحالة من المصدر. مسلَّمة: مُسح الطرد أو قُدمت الخدمة. فاشلة: رفض البنك. منتهية: ثلاثون دقيقة بلا تأكيد، وحُرر المخزون. مستردَّة: كلياً أو جزئياً، مؤرَّخة، بالسبب. ثلاثة أحداث تدفع المسار العادي: المصادقة في الخادم، حالة «مدفوع» المقروءة عند البوابة، التسليم الممسوح. كل منها يتحقق منه خادمكم، وكل منها يكتب سطراً في السجل بالحالة قبل وبعد كما ينص دليل سجل التدقيق.
شيئان لا يفعلان شيئاً. عودة المتصفح إلى عنوان النجاح عندكم، المشطوبة في الرسم: تعرض الحالة من القاعدة ولا تغيّرها، وهذا ما يجعل ترتيب الوصول بين العودة والـ webhook غير مهم. والنسخة الثانية من webhook: يُتحقَّق من توقيعها، ويُعرف معرّف حدثها، ويجيب خادمكم 200 ولا يكتب شيئاً. والقاعدة في جملة واحدة تُكتب في دفتر الشروط: لا تتغير الحالة إلا بحدث يتحقق منه خادمكم، لا بما يرويه متصفح الزبون أبداً. وكل ما عدا ذلك، الوصل والمخزون والمحاسبة، ينبع من الحالة لا من الشاشة أبداً.
«لا تتغير الحالة إلا بحدث يتحقق منه خادمكم، لا بما يرويه متصفح الزبون أبداً.»
ست حالات حقيقية، وما تفعله الهندسة
ست حالات نراها كل أسبوع في متاجر تعمل، والآلية التي تحسم كلاً منها.
الزبون يدفع ثم يغلق التبويب: العودة لا تصل أبداً؛ الـ webhook، أو الفحص المجدوَل للطلبيات المعلَّقة كل خمس دقائق، ينقل الطلبية إلى مدفوعة، ويُرسل الوصل دون أن يعود الزبون. نقرتان على ادفع: مفتاح عدم تكرار لكل سلة، والنقرة الثانية تعيد الطلبية نفسها والصفحة نفسها بدل إنشاء ثانية؛ وهي الآلية الموصوفة في دليل العمل دون اتصال. الـ webhook يصل قبل العودة: صفحة النجاح تقرأ الحالة من القاعدة وتعرضها؛ والترتيب لا يهم.
الـ webhook نفسه يصل مرتين: المعرّف محفوظ، والتسليم الثاني يُقرّ به دون كتابة؛ وبدون ذلك وصلان وسطران محاسبيان ومخزون خُصم مرتين. مدفوعة لكن المخزون اختفى: آخر قطعة خرجت من المحل أثناء الدفع؛ استرداد عبر واجهة البوابة، حالة مستردَّة، رسالة للزبون، ولا تحويل يدوي أبداً لن تجده أي مطابقة. البوابة لا تستجيب: الدفع عند التسليم أو التحويل يبقى مقترَحاً، والطلبيات المعلَّقة تنتهي بنظافة وتحرر المخزون، والإشراف يشير إلى ذلك؛ ومتجر لا يملك إلا البطاقة لا يبيع شيئاً تلك الليلة.
رأيناه في مكان آخر: صفحات الدفع المستضافة، webhooks الموقَّعة، وما ينتقل
ثلاثة مصادر تقول الجوهر. بوابة GIE Monétique تقول إن المدخل طلب واختبارات تقنية وترخيص؛ وما ينتقل هو أن الملف يُودَع في الأسبوع الأول بالتوازي مع الكود في بيئة الاختبار. ووثائق طرف ثالث لبوابة SATIM تصف طلبية مسجَّلة في الخادم وصفحة مستضافة وتأكيداً من المصدر؛ وما ينتقل هو أن خادمكم لا يرى البطاقة أبداً ولا يصدّق المتصفح أبداً. ووثائق مجمّع تصف webhook موقَّعاً يُقرّ به برد 200 ولا يمكن استلامه محلياً؛ وما ينتقل هو التحقق من التوقيع على النص الخام، وحفظ الأحداث المستلَمة، ونفق أثناء التطوير.
وما لا تقوله هذه المصادر: الرسوم، أجل التحويل، سياسة إعادة إرسال webhooks، والسلوك الدقيق لصفحة الدفع على هواتف زبائنكم؛ الأولان يُطلبان كتابةً، والآخران يُقاسان في التجريب.
قواعد دمج دفع يمكن وضعه في الإنتاج
ست قواعد تُكتب في الأسبوع الأول. المبلغ يُحسب في الخادم، ولا يُقرأ من الشاشة ولا من عنوان العودة أبداً. عودة المتصفح ليست إلا إشارة؛ والحالة المقروءة من المصدر أو webhook موقَّع وحدهما يغيّران الحالة. مفتاح عدم تكرار لكل طلبية، ومعرّف محفوظ لكل webhook: لا شيء يُخصم أو يُعدّ مرتين. الطلبية المعلَّقة تنتهي وتحرر المخزون. الكشف يُطابَق مع الطلبيات كل أسبوع، وكل فارق سؤال يُطرح. الاسترداد يمر عبر الواجهة ويترك حالة وسبباً وتاريخاً.
قاعدة سابعة تخص عرض السعر: «دمج الدفع CIB/الذهبية» ليس متطلباً بل جملة؛ المتطلب يُكتب «آلة حالات الطلبية بسبع حالات والأحداث المسموح بها؛ المبالغ في الخادم؛ تسجيل الطلبية عند البوابة وصفحة مستضافة؛ تأكيد الحالة من المصدر؛ webhook بتوقيع مُتحقَّق منه على النص الخام ومعرّفات محفوظة؛ مفتاح عدم تكرار لكل سلة؛ انتهاء الطلبيات المعلَّقة؛ مطابقة الكشف ↔ الطلبيات بقائمة الفوارق؛ استرداد عبر الواجهة؛ بيئة اختبار، الاختبارات التقنية للمنصة، تجريب بمبالغ صغيرة»، ويُتحقَّق منه كما يوصي دليل دفتر الشروط. وعرض السعر الذي يسعّر «زر الدفع» سعّر الشاشة، أي الطبقة التي لا تقرر شيئاً.
ست شركات، وما يميّز دفعها
ست شركات نجهّزها كثيراً، ولكل منها الخصوصية التي يجب أن تحملها آلة الحالات.
- بيع التذاكر، الموصوف في الدليل المخصص. التذكرة لا توجد إلا في حالة مدفوعة؛ والانتهاء يحرر المقاعد في دقائق لا ساعات.
- قاعة الرياضة واشتراكها، الموصوفان في الدليل المخصص. كل استحقاق طلبية؛ والدخول يتبع الحالة، والتجديد يقترح صفحة الدفع عبر WhatsApp.
- المرقّي الذي يبيع على المخطط للجالية، الموصوف في الدليل المخصص. أقساط مؤرَّخة كل منها طلبية، ووصل يحمل رقم الحصة؛ وسقوف البطاقة تُتحقَّق مع البنك قبل الإعلان عن الدفع الإلكتروني.
- وكالة العمرة، الموصوفة في الدليل المخصص. الدفع بالأقساط، وحالة الملف التي تتبع حالات الدفعات، واسترداد جزئي يحتفظ بالسبب.
- منصة الدروس، الموصوفة في الدليل المخصص. الوليّ في فرنسا يدفع بالدينار للتلميذ في الجزائر؛ الطلبية تحمل الهويتين، والوصل يُرسل إلى الاثنين.
- المتجر المُدار من فرنسا، الموصوف في الدليل المخصص. المؤسس يرى كل صباح الطلبيات المدفوعة والمعلَّقة طويلاً والمستردَّة، ومطابقة الكشف يوم الجمعة.
تقويم 2027
التقويم تقويم دفع إلكتروني يوضع في الإنتاج في عشرة أسابيع، الأسبوعان الأولان من الانتظار الإداري يتداخلان مع الكود.
الأسبوع 0 إلى 1 يودع الملف ويحسم الاختيار: حساب CIBWEB، السجل والمورّد الإلكتروني مُتحقَّق منهما، SATIM مباشرة عبر البنك أو مجمّع، يُقرَّر كتابةً مع الرسوم وأجل التحويل. الأسبوعان 1 إلى 3 يكتبان آلة الحالات في بيئة الاختبار: الطلبية، المبالغ في الخادم، مفتاح عدم التكرار، صفحتا النجاح والفشل، بـ webhooks محاكاة؛ لا شيء موصول بالبوابة الحقيقية بعد، وهذا مقصود. الأسبوعان 3 إلى 5 يوصلان التأكيد والـ webhook: الحالة تُقرأ من المصدر، التوقيع مُتحقَّق منه، المعرّفات محفوظة، فحص مجدوَل للطلبيات المعلَّقة.
الأسبوعان 5 إلى 7 يجتازان الاختبارات التقنية للمنصة ويحصلان على الترخيص؛ ومدتهما تتوقف على المنصة وتُطلب كتابةً. الأسبوع 7 إلى 8 يبني المطابقة والاسترداد. الأسبوعان 8 إلى 10 هما التجريب بمبالغ صغيرة: دفعات حقيقية من الفريق ثم من عشرة زبائن، كل فارق يُقرأ يومياً، ثم قرار الفتح للجميع. وكل دفعة تُعرض كما يصف دليل التسليم، والخوادم توضع وفق دليل الاستضافة: صفحة الدفع عند البوابة، لكن آلة حالاتكم يجب أن تجيب الـ webhook بسرعة أينما كانت.
ما يُفشل دمج الدفع
عمليات الدمج التي نستلمها فشلت دائماً تقريباً لأحد هذه الأسباب.
- تصديق عودة المتصفح. الطلبية تصير مدفوعة لأن الرابط يحتوي «نجاح»؛ طلبيات مدفوعة بلا خصم، وخصوم بلا طلبية.
- المبلغ المقروء من الشاشة. معامل غُيّر في المتصفح، وسلعة بـ 8 500 دينار دُفعت 85.
- لا مفتاح عدم تكرار. نقرة مزدوجة، طلبيتان؛ انقطاع، خصمان.
- لا تحقق من التوقيع. أي أحد يستطيع إرسال webhook «مدفوع» مزيف إلى خادمكم.
- لا انتهاء. طلبيات معلَّقة منذ أيام، مخزون محجوز، ومستودع لا يفهم.
- لا مطابقة. الفارق بين الكشف والمبيعات يُكتشف عند الإقفال، بعد ثلاثة أشهر.
- الاسترداد بتحويل يدوي. لا يُعثر عليه في المطابقة، يُنسى في المحاسبة، والزبون يعاود الاتصال.
أسئلة شائعة
الأسئلة التي نتلقاها من تجار ومؤسسين ومسؤولي إعلام آلي.
- هل تمر بطاقة الزبون عبر تطبيقنا؟
- لا. يسجّل خادمكم الطلبية ومبلغها عند البوابة، ثم يرسل الزبون إلى صفحة الدفع التي تستضيفها البوابة. البطاقة ورمز التأكيد يُدخلان هناك، لا في تطبيقكم أبداً، وهذا ما يعفيكم من حماية بيانات البطاقات.
- لماذا لا تكفي صفحة النجاح لوسم الطلبية مدفوعة؟
- لأن عودة المتصفح إشارة لا دليل: قد تصل قبل الخصم أو بعده أو لا تصل أبداً إن أغلق الزبون التبويب، ويمكن تزوير رابطها. لا تصير الطلبية مدفوعة إلا حين يقرأ خادمكم الحالة من المصدر، بطلب إلى البوابة أو بـ webhook تُحقِّق من توقيعه.
- ماذا يحدث إن أُشعرنا بالدفعة نفسها مرتين؟
- كل webhook يحمل معرّف حدث يحفظه خادمكم؛ التسليم الثاني يُقرّ به برد 200 ولا يكتب شيئاً. ومن جهة الزبون، مفتاح عدم تكرار لكل سلة يجعل النقرة المزدوجة تعيد الطلبية نفسها بدل إنشاء ثانية.
- كم يكلّف الدفع بالبطاقة ومتى نُدفع؟
- لا تُنشر شبكة رسمية، والأدلة الخارجية التي تذكر نسباً تتناقض؛ الرسوم وأجل التحويل والسقوف تُطلب كتابةً من البنك المستحوذ أو المجمّع، وتُتحقَّق في التجريب بمقارنة الكشف بالطلبيات. ونكتب الأرقام المحصَّلة في دفتر الشروط لا في المقال.
- SATIM مباشرة أم مجمّع؟
- كلاهما يعطي الهندسة نفسها: طلبية عندكم، صفحة عندهم، تأكيد من المصدر. المجمّع يحمل العقد والصفحة والوثائق ويفوتر مقابل ذلك؛ والوصل المباشر يمر عبر بنككم وGIE Monétique. نكتب آلة الحالات قبل الاختيار كي يُتخذ على الرسوم والأجل، ويمكن أن يتغير دون إعادة كتابة التطبيق.
- كم من الوقت لوضع الدفع في الإنتاج؟
- عشرة أسابيع: واحد للملف والاختيار، اثنان لآلة الحالات في بيئة الاختبار، اثنان للتأكيد والـ webhook، اثنان للاختبارات التقنية للمنصة، واحد للمطابقة والاسترداد، اثنان للتجريب بمبالغ صغيرة. ومدة الاختبارات التقنية تتوقف على المنصة وتُطلب كتابةً.