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

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

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

ما تملكه الطبقة وما يبقى لدى المزوّد

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

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

المحفظة السلسة أم محفظة التحويل

يتصل المزوّدون بأموال المشغّل بإحدى طريقتين. في المحفظة السلسة (seamless wallet) يبقى الرصيد لدى المشغّل، ويستدعي المزوّد محفظة المشغّل عند كل رهان ومكسب. وفي محفظة التحويل (transfer wallet) ينقل المشغّل المال قبل اللعب إلى رصيد محفوظ في جانب المزوّد، ولا يعيده إلا حين يطلبه.

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

تفترض بقية هذه المقالة محفظة سلسة، لأن كل رهان ومكسب فيها استدعاءٌ للمحفظة.

الجلسات: المشغّل يُصدر الرمز

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

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

الوثائق المنشورة للمشغّلين تقول ذلك صراحةً. تقول واجهة API للمحفظة لدى Hub88 إنه يجب عدم التحقق من صلاحية الرمز في المكاسب وعمليات التراجع، لأنها قد تصل بعد أن يكون الرهان قد لُعب. وتقول VeliGames إنه لا يجوز للمشغّل رفض المكسب في جولة حتى لو انتهت صلاحية الجلسة.

ردود استدعاء الرصيد: كل استدعاء قد يصل مرتين

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

تُظهر وثائق التكامل المنشورة مدى إلحاح التكرارات. فواجهة API لمحفظة المشغّل لدى Hub88 تعدّ الرهان فاشلًا حين لا تتلقى HTTP 200، فتُنشئ تراجعًا وتعيد محاولة ذلك التراجع حتى 500 مرة مع تباعد أُسّي بين المحاولات (exponential back-off). وتعيد Gamomat محاولة الطلب الفاشل مرتين بفاصل 500 ms، ثم تبدأ تراجعًا وتعيد محاولته على فترات تتزايد من ثانية واحدة إلى 30 دقيقة. ومهلة المحفظة لدى Tom Horn Gaming هي 10 ثوانٍ، يُرسَل بعدها تراجع تلقائيًا. والمحفظة التي تتوقف بضع دقائق تعود إلى طابور من التكرارات وعمليات التراجع، لا إلى الصمت.

• مفتاح idempotency هو ID المعاملة لدى المزوّد ضمن نطاق المزوّد ونوع الاستدعاء، لأن مزوّدَين اثنين قد يُصدران الـ ID نفسه، وبعضهم يرسل التراجع تحت ID الرهان؛ وقيد التفرّد على هذا المفتاح يحوّل الاستدعاء المكرر إلى عملية بحث
• الخصم المكرر لا يحرّك المال مرة ثانية أبدًا، والـ ID نفسه حين يصل بمبلغ مختلف أو جولة مختلفة خطأٌ، لا رهان جديد
• الخصم يقفل صف الحساب، ويتحقق من الأموال والحدود، ويكتب قيده في دفتر الأستاذ في معاملة واحدة قصيرة، فلا يمكن لدورتين متزامنتين على حساب واحد أن تنفق كلتاهما المال نفسه
• التراجع يسمّي المعاملة التي يلغيها: فالخصم المطبَّق يُعكس مرة واحدة، والتراجع الذي سبقت معالجته يعيد نتيجته المخزَّنة
• التراجع عن معاملة لم تتلقها المحفظة قط يُسجَّل ويُجاب عنه بالكود الذي يوثّقه المزوّد، فتُرفض المعاملة الأصلية المتأخرة التي تصل بعده بدل أن تُحمِّل اللاعب ثمن رهان ألغاه المزوّد بالفعل
• تُربط الأخطاء بأكواد كل مزوّد الخاصة به، لأن المزوّدين يتصرفون بشكل مختلف إزاء عدم كفاية الأموال، والجلسة المنتهية الصلاحية، والفشل العام: فبعضهم يوقف اللعبة، وبعضهم يعيد المحاولة، وبعضهم يلغي

الرد المتوقع على التكرار ليس موحّدًا هو الآخر. تشترط Hub88 ألا تُعالَج الطلبات التي تحمل ID المعاملة نفسه مرتين، وأن يكون الرد هو نفسه لكل الطلبات المكررة؛ وتطلب VeliGames خطأً مع HTTP status 409 وDUPLICATE_TRANSACTION؛ ولدى Tom Horn Gaming كود نتيجة منفصل للمرجع المكرر. ويجيب المحوّل كل مزوّد بصيغته الخاصة، ويبقى دفتر الأستاذ تحته كما هو.

ينص المزوّدون على هذه القاعدة في وثائقهم الخاصة. تقول واجهة API الخاصة بالمشغّلين لدى St8 إنه حين يتلقى المشغّل ID معاملة لعملية إلغاء لم يعالجها من قبل، يجب حفظ هذا الـ ID لمنع معالجته لاحقًا. وتتوقع Tom Horn Gaming كود النتيجة الخاص بالمعاملة المجهولة لديها حين لا تكون المحفظة قد عالجت قط عملية السحب التي يشير إليها التراجع.

الجولات تُغلق وفق جدولها الخاص

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

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

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

الجهات التنظيمية تحدد الحد الأدنى الذي يجب أن يغطيه هذا السجل. فـ GLI-19، وهو معيار أنظمة الألعاب التفاعلية الصادر عن Gaming Laboratories International، يشترط توفير خاصية استرجاع اللعبة (game recall) للاعب، إما في صورة إعادة تمثيل وإما بالوصف. وتشترط المعايير التقنية للمقامرة عن بُعد الصادرة عن هيئة المقامرة البريطانية (UK Gambling Commission) ثلاثة أشهر على الأقل من سجل الحساب والمقامرة دون التواصل مع المرخَّص له، و12 شهرًا على الأقل عند الطلب. ويمنح توجيه حماية اللاعبين الصادر عن سلطة الألعاب في مالطا (Malta Gaming Authority) اللاعبَ إمكانية الوصول إلى سجل مقامرته عن الأشهر الستة السابقة مباشرةً.

الموزّع المباشر يحوّل المحفظة إلى اندفاع

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

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

عقد داخلي واحد ومحوّلات كثيرة

المحوّلات هي موطن الاختلافات بين المزوّدين، وينبغي أن تكون موطنها الوحيد. يتولى كل محوّل ما يلي:

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

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

المطابقة: تقرير المزوّد دفتر أستاذ ثانٍ

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

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

المدة التي يجب أن تُحفظ فيها هذه الأدلة جزء من التكامل. تطلب Hub88 تخزين ID كل معاملة لدى الطرفين مدة أربعة أشهر على الأقل لأغراض المطابقة، وتُرجع واجهة API الخاصة بالمشغّلين لدى Gamomat بيانات المطابقة لنطاق زمني أو لجولة واحدة.

ما يُقاس قبل أن يعمل أول مزوّد في الإنتاج

• زمن استجابة ردود الاستدعاء لكل مزوّد ولكل نوع استدعاء، عند p99 لا المتوسط
• الاستدعاءات المكررة، والـ IDs المكررة التي تصل بحمولة مختلفة
• عمليات التراجع، وعمليات التراجع عن معاملات لم تتلقها المحفظة قط
• الجولات المفتوحة حسب عمرها
• عمليات الخصم المرفوضة حسب السبب: الأموال أو الحدود أو الجلسة أو الخطأ
• فروق المطابقة اليومية لكل مزوّد

أي الشركات تبني طبقات تجميع مزوّدي الألعاب للمشغّلين؟

لهذا السؤال ثلاثة أنواع من الإجابات، وهي تبيع أشياء مختلفة. فالمجمّعون ومورّدو المنصات يؤجّرون طبقتهم للمشغّل: عقد واحد، ومزوّدون كثيرون، وشروطهم التجارية. ومنصات turnkey وwhite-label تضمّ الطبقة داخل منصة يملكها المورّد. أما شركات الهندسة فتبني الطبقة داخل الواجهة الخلفية للمشغّل، والمشغّل يوقّع عقوده مع المزوّدين بنفسه.

أيًّا كان النوع الذي تتحدث إليه، فهذه الأسئلة تُظهر ما إذا كان الفريق قد بنى هذا من قبل:

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

الإجابة التي تبقى عامة في السؤالين الأولين تعني أن الحالات الحدّية ستُكتشف في الإنتاج.

هل تدمج amBrain مزوّدي الألعاب لمشغّلي الكازينو؟

amBrain شركة تطوير برمجيات متخصصة في منصات التداول ومحركات المطابقة وأنظمة المزايدة الفورية وهندسة منصات الكازينو. وتبني amBrain البرمجيات منذ عام 2019.

في iGaming، الأرقام التي تنشرها amBrain بوصفها مقيسة هي أكثر من 500 تكامل مع مزوّدين خارجيين و12 مشغّلًا في الإنتاج.

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

تشرح هذه المقالة كيف تعمل طبقة التجميع؛ وهي ليست دراسة حالة، ولا تسمّي أي عملاء.

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