بوابات الدفع Payment Gateways في السعودية والبدائل المفتوحة

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

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

وسوف نناقش في هذا المقال ما يلي:

• ما بوابة الدفع ومزود خدمة الدفع، وأين يقفان بين تطبيقك والبنوك.
• الترخيص في المملكة: من يحق له تقديم خدمات الدفع، وكيف تتحقق.
• المزودون المحليون Moyasar وHyperPay وTap وPayTabs بما تنشره صفحاتهم الرسمية، والأسعار التي لا تنشر.
• Stripe والمزودون العالميون، وما تقوله صفحاتهم عن المملكة.
• البرمجيات مفتوحة المصدر: Hyperswitch للتنسيق وKill Bill للفوترة، وحدود ما تفعله.
• معايير الاختيار، والتنسيق بين أكثر من مزود، ومختبر التحويل عند العطل.
• الخروج من مزود، والأخطاء الشائعة، وقائمة تحقق.

ما بوابة الدفع، وأين تقف؟

المصطلحات في هذا المجال متداخلة، فلنفصلها أولاً. بوابة الدفع Payment Gateway في معناها الضيق هي البرنامج الذي يستقبل بيانات الدفع من صفحة التاجر وينقلها بأمان إلى المستحوذ ويعيد الرد، ومزود خدمة الدفع Payment Service Provider واختصاراً PSP جهة تقدم للتاجر حزمة كاملة: البوابة، وعلاقة مع مستحوذ أو أكثر، ولوحة تحكم، والتسوية للتاجر، والتقارير، وأحياناً الفوترة والروابط ونقاط البيع. والمستحوذ Acquirer هو البنك أو الجهة التي تقبل العمليات من الشبكات نيابة عن التاجر. وأغلب ما يسمى «بوابة دفع» في السوق اليوم هو في الحقيقة مزود خدمة دفع. والصورة التالية تبين أين يقف:

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

ماذا يحدث داخل المزود؟

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

• الخزنة Vault: المكان الذي تحفظ فيه بيانات البطاقات فعلاً، معزولاً عن بقية الأنظمة، ويصدر منه التوكن الذي يصلك. وهذا الجزء من المزود هو ما يحمل أثقل متطلبات PCI DSS، وهو ما توفره على نفسك بعدم حفظ البطاقات عندك.
• محرك المخاطر Risk Engine: قواعد ونماذج تفحص كل عملية قبل إرسالها: سرعة تكرار البطاقة، والبلد، والمبلغ غير المعتاد، ونتيجة 3D Secure، وقد يرفض المزود عملية قبل أن تصل للبنك المصدر أصلاً.
• التوجيه Routing: اختيار المستحوذ أو الشبكة المناسبة للعملية بحسب نوع البطاقة والعملة، فبطاقة مدى تمر في طريق غير طريق بطاقة دولية في كثير من الحالات.
• دفتر المزود: كل عملية واسترداد ورسوم واعتراض قيد في دفتر المزود، ومنه يحسب صافي ما يستحقه كل تاجر.
• التسوية والتحويل Payouts: يجمع المزود ما استلمه من المستحوذين، ويخصم الرسوم والاحتياطي، ويحول للتاجر في دفعات بحسب جدول العقد، ومنه يخرج ملف التسوية.

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

الترخيص: من يحق له أن يقبل المال عنك؟

قبل المقارنة بين المزودين هناك سؤال واحد يسبق كل شيء: هل المزود مرخص من البنك المركزي السعودي لتقديم خدمات الدفع؟ والسبب أن المزود يحتفظ بأموالك بين التحصيل والتسوية، فإذا لم يكن مرخصاً فلا توجد جهة رقابية تحمي هذه الأموال، ونظام المدفوعات وخدماتها يجعل تقديم خدمات الدفع نشاطاً يحتاج ترخيصاً. وفي إعلان البنك المركزي في 29 مارس 2026 عن ترخيص شركة دفع جديدة كمؤسسة دفع رئيسية Major Payment Institution أصبح عدد الشركات المرخصة لتقديم خدمات الدفع في المملكة 31 شركة، وأكد الإعلان أهمية التعامل مع المؤسسات المالية المصرح لها فقط، وأن قائمتها على موقع البنك المركزي في صفحة الجهات المرخصة.

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

المزودون المحليون بما تنشره صفحاتهم

في المملكة عدد من المزودين المرخصين، ونأخذ هنا أربعة يذكرهم المطورون كثيراً، بما وجدناه في صفحاتهم الرسمية وصفحات البنك المركزي في 27 أكتوبر 2026، دون تقييم لجودة خدماتهم، لأننا لم نتعاقد مع أي منهم لهذا المقال. والقائمة ليست حصرية، ووجود مزود فيها ليس توصية.

Moyasar

أعلن البنك المركزي في 1 مارس 2022 ترخيص شركة ميسر المالية Moyasar Financial Company لتقديم خدمات المدفوعات للتجارة الإلكترونية. وفي صفحة الأسئلة الشائعة لدى Moyasar معلومات تفيد المطور والمؤسس مباشرة:

• وسائل الدفع: مدى والبطاقات الائتمانية Visa وMastercard وAmerican Express، وSTC Pay، وApple Pay، وSamsung Pay، وغيرها.
• الأسعار: تقول الصفحة إن فريق المبيعات يقدم الأسعار والرسوم بحسب متطلبات العمل وحجمه، فلا توجد أسعار منشورة.
• التسوية: بطاقات مدى من 24 ساعة إلى 3 أيام عمل، والبطاقات الائتمانية من 7 إلى 14 يوم عمل، دون احتساب عطلة نهاية الأسبوع.
• المتطلبات: سجل تجاري سعودي ساري أو وثيقة عمل حر، وحساب بنكي في بنك تجاري سعودي مرتبط به.
• البيئة التجريبية: بيئة تفاعلية تجرب فيها الخدمات من لوحة التحكم قبل التفعيل، دون حاجة للتواصل مع المبيعات.
• التكامل: واجهة API ومكتبات وإضافات لمنصات محلية وعالمية مثل WooCommerce وMagento، وتوثيق في docs.moyasar.com.

HyperPay

في صفحة الأسئلة الشائعة لدى HyperPay أن تكلفة أن تصبح تاجراً تعتمد على بلد تسجيل الشركة، وأنها تخدم الأردن ومصر والمملكة ولبنان والإمارات بهيكل أسعار مختلف لكل بلد، وأن التفاصيل من فريق تطوير الأعمال، وأن أسعار خدمة HyperTap، التي تحول الجوال المزود بتقنية NFC إلى جهاز قبول للمدفوعات اللاتلامسية بحضور البطاقة، تؤخذ من مدير الحساب. وفي مدونة HyperPay بتاريخ 26 فبراير 2025 أن البنك المركزي رخص كيانها في المملكة «HyperPay Inc AL-SAOUDIA For IT Systems» لتقديم خدمات المحافظ الإلكترونية، وأن عدد مقدمي خدمات الدفع المرخصين أصبح وقتها 27. ولاحظ هنا مثال الاسم القانوني الذي يختلف عن الاسم التجاري، وهو ما تبحث عنه في صفحة الجهات المرخصة.

Tap Payments

في صفحة التراخيص لدى Tap أن Tap Payments مرخصة كمؤسسة دفع رئيسية Major Payment Institution من البنك المركزي السعودي، وأن الشركة تعمل في المملكة بسجل تجاري من وزارة التجارة، وتذكر الصفحة تراخيصها في دول أخرى في المنطقة. ولم نجد في موقعها صفحة أسعار منشورة للمملكة في تاريخ اطلاعنا.

PayTabs

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

لماذا لا تنشر الأسعار؟ وكيف تقارن؟

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

مزود خدمة دفع أم مستحوذ مباشر؟

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

أين تحفظ بيانات عملائك وتعالج؟

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

وماذا عن Stripe والمزودين العالميين؟

Stripe مثال مشهور على المزود العالمي الذي يحبه المطورون، وتوثيقه من أفضل ما في المجال، واستشهدنا به في مقال عملية البطاقة لهذا السبب. ولكن السؤال للشركة السعودية مختلف: هل تستطيع أن تفتح حساباً وتقبل المدفوعات كشركة مسجلة في المملكة؟ وصفحة البلدان المدعومة لدى Stripe لا تذكر المملكة العربية السعودية في تاريخ اطلاعنا (27 أكتوبر 2026)، والدولة الوحيدة من الشرق الأوسط فيها الإمارات. وهذا يعني أن الشركة المسجلة في المملكة لا تستطيع أن تبني على Stripe مباشرة بحسب الصفحة، وأن حلولاً مثل تسجيل شركة في بلد آخر لاستخدامه لها تبعات قانونية وضريبية ومالية تحتاج مستشاراً، ولا تحل مسألة قبول مدى التي يحتاجها أغلب عملائك المحليين.

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

ثلاثة طرق، والفرق بينها

جمع الفريق ما تعلمه في الصورة التالية:

الدفع داخل تطبيقات الجوال: قواعد المتاجر أولاً

قبل أن يدمج الفريق مزود الدفع في تطبيق iOS، هناك سؤال لا يجيب عنه المزود: هل تسمح Apple أصلاً بالدفع ببطاقة لهذا النوع من المشتريات؟ ففي إرشادات مراجعة متجر App Store تقول القاعدة 3.1.1 إن فتح الميزات أو الوظائف داخل التطبيق، مثل الاشتراكات والعملات داخل الألعاب والمحتوى المميز، يجب أن يكون عبر الشراء داخل التطبيق In-App Purchase، بينما تقول القاعدة 3.1.3(e) إن التطبيق الذي يتيح شراء سلع مادية أو خدمات تستهلك خارج التطبيق يجب أن يستخدم وسائل دفع غير الشراء داخل التطبيق، مثل Apple Pay أو إدخال البطاقة التقليدي. واشتراك النادي الرياضي خدمة تستهلك خارج التطبيق، فيمر عبر مزود الدفع، أما لو أضافت الشركة حصصاً تدريبية مرئية تشاهد داخل التطبيق فقد تصبح محتوى رقمياً تنطبق عليه القاعدة الأولى. والقواعد تتغير وتختلف تفاصيلها بين البلدان وبين المتاجر، فاقرأ نسختها الحالية من Apple وGoogle قبل أن تصمم الدفع في التطبيق، لأن رفض التطبيق في المراجعة يأتي متأخراً ومكلفاً.

البرمجيات مفتوحة المصدر: ماذا تفعل وما لا تفعل؟

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

• Hyperswitch: منصة مدفوعات مفتوحة المصدر برخصة Apache-2.0 مكتوبة بلغة Rust، يصفها مستودعها بأنها تتصل بمزودي الدفع والتحويل ومكافحة الاحتيال والخزائن والترميز، وتوجه العمليات بين المزودين، وتعيد المحاولة باستراتيجيات بحسب البطاقة والمنطقة ووسيلة الدفع، وفيها خزنة لحفظ البطاقات والتوكنات، ويذكر المستودع أكثر من 100 مزود جاهز للربط. أي أنها تساعدك على استخدام أكثر من مزود بواجهة واحدة، ولكنها تحتاج المزودين أنفسهم، وتشغيلها يضيف إلى مسؤولياتك الأمنية بقدر ما تحفظه. ولها مقال عملي مستقل في هذا القسم.
• Kill Bill: منصة مفتوحة المصدر برخصة Apache 2.0 للفوترة والاشتراكات، يصفها مستودعها بأنها تدير كتالوج الأسعار والاشتراكات والقياس بالاستخدام والفواتير والمدفوعات عبر البوابات والأرصدة والضرائب وتحصيل المتأخرات Dunning، وتتصل بالبوابات عبر إضافات. أي أنها تحل مشكلة «من يدفع ماذا ومتى» في نموذج الاشتراكات، وتترك قبول المال للمزود.

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

الفوترة المتكررة: عند المزود أم في نظامك؟

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

روابط الدفع والفواتير: البيع خارج التطبيق

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

كيف تختار؟ ستة أسئلة

بعد أن عرف الفريق الطرق الثلاث، كتب ستة أسئلة لكل مزود مرشح، والصورة التالية تجمعها:

1. الترخيص: الاسم القانوني للمزود في صفحة الجهات المرخصة لدى البنك المركزي، ونوع ترخيصه.
2. وسائل الدفع: مدى في التطبيق والويب مع 3D Secure، والمحافظ التي يستخدمها عملاؤك، ووسائل أخرى إن احتجتها مثل STC Pay أو سداد، والعملات إذا كان لديك عملاء من الخارج.
3. التسوية: مدة التسوية لكل وسيلة، كما تنشرها Moyasar مثلاً في الصورة التالية، والاحتياطي المحجوز، وتكرار التحويل، وشكل ملف التسوية وكيف تحصل عليه آلياً.
4. الرسوم: العرض المكتوب بالنموذج الموحد الذي ذكرناه، محسوباً على توزيع عملياتك.
5. تجربة المطور: جودة التوثيق، والبيئة التجريبية وبطاقات الاختبار، والأحداث وتوقيعها وإعادة إرسالها، ومفاتيح منع التكرار، وحالة الخدمة المنشورة، والدعم التقني وأوقاته.
6. الخروج: هل يسمح العقد بنقل توكنات البطاقات المحفوظة إلى مزود آخر عند الانتقال، وكم مدة الوصول إلى التقارير القديمة بعد الإلغاء.

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

قراءة ملف التسوية من المزود

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

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

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

أكثر من مزود: التنسيق Orchestration

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

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

المختبر: التحويل الأعمى مقابل السؤال قبل التحويل

المختبر يحاكي مزودين وهميين في Python، بلا أي اتصال بمزود حقيقي ولا بيانات بطاقات: المزود أ يدعم مدى وVisa وApple Pay، وتنتهي المهلة في 5% من طلباته بعد أن يكون قد خصم المبلغ فعلاً، أي أن الرد يضيع في الطريق، والمزود ب يدعم الوسائل نفسها مع STC Pay ولا تنتهي مهلته. والموجه يرسل كل طلب إلى المزود أ إذا دعم الوسيلة، وعند انتهاء المهلة يحول إلى الآخر، مرة دون أي فحص، ومرة بعد أن يسأل المزود أ عن حالة الطلب بمفتاحه. ونسبة 5% افتراض للتجربة، لا قياس لأي مزود:

# router.py: two simulated gateways, a router with failover, and the double-charge trap
import random, sys

class Gateway:
    """a fake gateway: some calls time out after the charge was actually made"""
    def __init__(self, name, methods, timeout_rate, seed):
        self.name, self.methods, self.timeout_rate = name, methods, timeout_rate
        self.rnd = random.Random(seed)
        self.charges = {}                       # idempotency key -> amount (what the gateway really did)
    def charge(self, key, method, amount):
        if method not in self.methods:
            return "unsupported"
        if key in self.charges:                 # same key again: no second charge
            return "ok"
        self.charges[key] = amount              # the money is taken here...
        if self.rnd.random() < self.timeout_rate:
            return "timeout"                    # ...but the answer never reaches us
        return "ok"
    def status(self, key):
        return "charged" if key in self.charges else "not_found"

def run(check_before_failover):
    a = Gateway("A", {"mada", "visa", "applepay"}, timeout_rate=0.05, seed=1)
    b = Gateway("B", {"mada", "visa", "applepay", "stcpay"}, timeout_rate=0.0, seed=2)
    orders = [(f"order-{i:04}", ["mada", "visa", "applepay", "stcpay"][i % 4], 9_900) for i in range(1, 1001)]
    for key, method, amount in orders:
        primary = a if method in a.methods else b
        result = primary.charge(key, method, amount)
        if result == "timeout":
            if check_before_failover and primary.status(key) == "charged":
                continue                        # it worked; do not try elsewhere
            other = b if primary is a else a
            other.charge(key, method, amount)   # failover to the other gateway
    customers_charged = sum(len(g.charges) for g in (a, b))
    doubles = len(set(a.charges) & set(b.charges))
    return len(orders), customers_charged, doubles, a, b

for flag in (False, True):
    n, charged, doubles, a, b = run(check_before_failover=flag)
    label = "check status, then failover" if flag else "blind failover"
    print(f"{label:28} orders {n}  charges {charged}  double-charged {doubles}  A {len(a.charges)}  B {len(b.charges)}")

وعند تشغيله بالأمر python router.py على Python 3.13 سوف يكون المخرج كما يلي:

blind failover               orders 1000  charges 1047  double-charged 47  A 750  B 297
check status, then failover  orders 1000  charges 1000  double-charged 0  A 750  B 250

في المخرج أعلاه لاحظ التالي:

• في التحويل الأعمى خصم 1,047 مرة لـ 1,000 طلب، و47 عميلاً خصموا مرتين: مرة عند المزود أ الذي ضاع رده، ومرة عند المزود ب الذي حول إليه الموجه. وكل واحد من هؤلاء سيطلب استرداداً أو يفتح اعتراضاً، والاعتراض أغلى على التاجر من الاسترداد كما شرحنا في مقال عملية البطاقة.
• عندما سأل الموجه المزود أ عن حالة الطلب قبل التحويل، خصم 1,000 مرة بالضبط، وصفر خصم مزدوج، والمزود ب لم يستلم إلا طلبات STC Pay التي لا يدعمها أ (250 طلباً).
• المزود أ في الحالتين خصم 750 مرة، أي كل الطلبات التي أرسلت إليه، بما فيها التي انتهت مهلتها، وهذا هو بالضبط ما لا يعرفه الموجه الأعمى.
• والأرقام كلها ناتجة عن بذرة عشوائية ثابتة، فتحصل على نفسها إذا شغلت الكود، والنسبة الحقيقية تعتمد على مزوديك وشبكتك.

والصورة التالية تلخص النتيجة:

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

أدوات الاحتيال عند المزود: الإعدادات التي تملكها

محرك المخاطر عند المزود يعمل لصالحك ولصالحه، ولكن إعداداته الافتراضية مصممة لمتوسط تجاره، لا لنموذج عملك. والإعدادات التي يتيحها أغلب المزودين للتاجر، ويستحق أن تراجعها مع فريقك قبل الإطلاق: متى يطلب 3D Secure، ودائماً أم بحسب المخاطر، وحدود المبالغ لكل عملية ولكل بطاقة في اليوم، وقوائم البلدان المسموحة، وعدد المحاولات المرفوضة المتتالية من نفس الجهاز أو البطاقة قبل الحظر. والفريق في قصتنا اكتشف بعد شهر أن أحدهم يجرب مئات البطاقات المسروقة على أرخص اشتراك في التطبيق ليعرف أيها يعمل، وهذا نمط معروف يسمى اختبار البطاقات Card Testing، فأضاف حداً لعدد محاولات الدفع لكل حساب وجهاز، وفعل 3D Secure لكل عمليات الاشتراك الأول. وتفاصيل كشف الاحتيال لها مقال مستقل في هذا القسم.

التشغيل: حالة الخدمة والتنبيهات والدعم

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

الخروج من مزود: صممه من اليوم الأول

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

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

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

أول أسبوع مع المزود المختار

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

1. فتح حساب البيئة التجريبية، وقراءة التوثيق كاملاً لعمليات الدفع والاسترداد والأحداث والتسوية.
2. حفظ مفاتيح البيئة التجريبية والإنتاج في مدير الأسرار، لا في الكود ولا في ملفات الإعداد في المستودع، ومفاتيح الإنتاج لا يراها إلا من يحتاجها.
3. بناء حقل الدفع بمكتبة المزود، والتأكد أن بيانات البطاقة لا تمر على سيرفرات الشركة.
4. بناء نقطة الأحداث مع التحقق من التوقيع، والحفظ ثم المعالجة، والقيد الفريد على معرف الحدث.
5. اختبار كل الحالات ببطاقات الاختبار: الموافقة، والرفض، و3D Secure بخطوة تحقق، والاسترداد الكامل والجزئي، وانتهاء المهلة.
6. تنزيل ملف التسوية التجريبي، وبناء المطابقة اليومية عليه قبل أول ريال حقيقي.

التفاوض في السنة الثانية

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

أخطاء شائعة

قائمة تحقق قبل توقيع عقد مزود الدفع

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• مزود خدمة الدفع هو الطرف الوحيد الذي يتحدث معه كودك، ويقدم البوابة والعلاقة مع المستحوذ والتسوية والتقارير، والاختيار يعيش معك سنوات.
• الترخيص أول سؤال، ويتحقق منه من موقع البنك المركزي بالاسم القانوني، وعدد الشركات المرخصة لخدمات الدفع 31 بحسب إعلان مارس 2026.
• المزودون الأربعة الذين راجعنا صفحاتهم لا ينشرون أسعاراً، فالمقارنة بعرض مكتوب بنموذج موحد، والتسوية مثل الرسوم في الأهمية، كما في مدد Moyasar المنشورة.
• صفحة Stripe للبلدان المدعومة لا تذكر المملكة في 27 أكتوبر 2026، والسؤال لأي مزود عالمي: من الجهة المرخصة التي سأتعاقد معها فعلاً؟
• البرمجيات المفتوحة مثل Hyperswitch وKill Bill طبقة تنسيق وفوترة فوق المزودين، ولا تقبل البطاقات وحدها.
• التحويل الأعمى بين مزودين عند انتهاء المهلة خصم 47 عميلاً مرتين في المختبر، والسؤال عن الحالة أولاً جعلها صفراً.
• ملف التسوية هو مصدر المطابقة اليومية، فاطلب نموذجه قبل التعاقد، وأرسل معرفك في كل طلب حتى تربط كل سطر فيه بطلب في نظامك.
• صمم الخروج من اليوم الأول بطبقة داخلية وشرط لنقل البطاقات، لأن إمكانية الانتقال هي أقوى ورقة في التفاوض بعد سنة.

وفي مقالات قادمة بإذن الله في هذا القسم سوف نشغل Hyperswitch في مختبر عملي لنرى التنسيق بين مزودين بأعيننا، ونشرح أمن المدفوعات وPCI DSS والترميز بالتفصيل، وكشف الاحتيال، والمطابقة بين كشف البنك ونظامك، وكلها تبني على ما اخترته هنا من مزود وطريقة ربط.

وبقية مقالات قسم التقنية المالية والمدفوعات:

دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.دليلكيف تنتقل الأموال بين البنوك؟ المقاصة Clearing والتسويةماذا يحدث بين ضغطة «ادفع» ووصول المال: الدفع والمقاصة والتسوية الإجمالية والصافية، مع محاكاة يوم من التسويات بين ستة بنوك.دليلالمصرفية المفتوحة Open Banking: إطار البنك المركزي والواجهاتما تتيحه المصرفية المفتوحة في المملكة وما تفرضه لائحتها، والموافقة من الطلب إلى الحذف، مع مختبر لتطبيق يقرأ بموافقة العميل فقط.دليلالمحفظة الرقمية من الداخل: دفتر القيد المزدوج Ledgerكيف تبني محفظة رقمية لا يضيع فيها ريال ولا يخصم مرتين، بالقيد المزدوج والمعاملات والمطابقة مع مزود الدفع.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وتشغيل مختبر التحويل بين مزودين على Python 3.13.3 بمزودين وهميين، والتحقق من صفحات Moyasar وHyperPay وTap وPayTabs وStripe ومستودعي Hyperswitch وKill Bill وإعلانات البنك المركزي بتاريخ 27 أكتوبر 2026.