ארכיטקטורה של מערכת בונוסים בקזינו קריפטו: פרי-בטים ופרי-ספינים

מעגל הבונוסים של הקזינו מאבד זיכויים וקורס כשהעומס גדל — ואיתו נעלם גם אמון השחקנים. אנו מתכננים מערכת פרי-בטים ופרי-ספינים במפתח מלא: משיטות זיכוי ועד רישום התחייבויות. הפתרון מסיר פעולות ידניות והופך את חישובי הבונוסים לשקופים.

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע מערכת הפריבטים נשברת עם גידול בעומס

פריבט אינו מספר ביתרה, אלא ישות עם מחזור חיים: הונפק, הוקצה להימור, מומש, פג תוקף. כל עוד מערכת הפריבטים משרתת מאות הימורים ביום, אפשר לבצע מעברים בין מצבים ברישום אחד ולבדוק ידנית. בזרם של אלפי הימורים בו-זמניים גישה כזו מפסיקה להחזיק מצב.

הכשל הראשון — הימורים מקבילים על אותו בונוס. שתי פעולות קוראות בו-זמנית את המצב "הפריבט פעיל" ושתיהן מנכות אותו: נוצרת זיכוי כפול של הבונוס, ובדוחות צצות אי-התאמות בזיכויי בונוסים. התאמת חשבון המשחק עם יומן הבונוסים מפסיקה להתאים, ומכאן כל אי-התאמה יש לפרק לפי הימור ספציפי.

הכשל השני — בונוסים תקועים. ביטול הימור, חישוב מחדש של אירוע או ביטול עקב החלטת שירות הסיכונים מחזירים את ההימור, אך אינם מחזירים את הבונוס למצבו המקורי: פעולת הביטול עוברת שלא דרך יומן הבונוסים. השחקן רואה יתרה שהתמיכה אינה יכולה להסביר, והפריבט עצמו נשאר במצב ביניים וחוסם הנפקה של הבונוס הבא.

הכשל השלישי — גידול בתיקונים ידניים של בונוסים. כל תיקון מוחק עקבות של פעולה, הביקורת הופכת לבלתי ניתנת לשחזור, והעומס על מעגל הבונוסים גדל באופן לא ליניארי: תיקונים מולידים אי-התאמות חדשות, ואי-התאמות — תיקונים חדשים.

בהמשך נפרק כיצד זה נסגר ארכיטקטונית: מפתחות אידמפוטנטיים, יומן פעולות אחיד ובנייה מחדש של המצב מתוך אירועים.

מה נותן מעגל בונוסים מנוהל: אפקטים ומדדים

מעגל בונוסים מנוהל מתחיל מכך שכל זיכוי הוא אירוע עם מפתח אידמפוטנטי ורישום ביומן בלתי משתנה. רק אז זמן זיכוי הבונוס נמדד מהפעלת התנאי ועד להופעת הכספים ביתרה, ולא "בממוצע ליום". את אותו מדד אנחנו לוקחים גם בביטול: כמה זמן עובר מההחלטה ועד לרישום המקזז.

מדדי עבודה לאחר מעבר למעגל כזה: שיעור הזיכויים האוטומטיים 95–98%, והשאר — מקרים שנויים במחלוקת, שעדיין מחייבים אדם. פעולות ידניות יורדות לעשרות פעולות בשבוע במקום מאות: העובד מטפל בחריגים, ולא מעניק פריספינים ידנית. ביטול בונוס שגוי אורך דקות, ולא שעות.

סוגים שלמים של שגיאות נעלמים לחלוטין: זיכוי כפול בעת מסירה חוזרת של אירוע ממערכת התשלומים, בונוס על הפקדה שבוטלה, אי-התאמה בין היתרה בבלוקצ'יין לבין החשבונאות הפנימית, פריספין שפג תוקפו ולא נסגרה בגינו התחייבות. כל זה נתפס על ידי כלל, ולא על ידי התאמה בסוף החודש.

חשבונאות התחייבויות בגין בונוסים הופכת לרציפה: בכל רגע רואים כמה תנאי מימוש פתוחים, איזה היקף זכיות מוקצה, וכמה פריספינים עדיין יכולים להיות מופעלים. עבור ביקורת והשירות הפיננסי זהו חתך לרגע הנוכחי במקום הפקת דוח לפי דרישה.

אוספים את החתכים האלה מאותם אירועים: שכבת אינדוקס על The Graph מספקת אגרגטים, והדשבורד מציג דינמיקה של זיכויים וביטולים. אנומליות — זינוק של בונוסים מאותו סוג מכתובת אחת או ירידה בשיעור ההחלטות האוטומטיות — נראות מיד, ולא אחרי טיפול בתלונות.

מצבי זיכוי פריבטים ופריספינים: השוואת סכמות

מצבי זיכוי פריבטים ופריספינים נבדלים לא בגודל המתנה, אלא באופן שבו המערכת מחשבת התחייבויות כלפי השחקן. מבצע חד-פעמי יוצר שיא חד של אירועים בחלון קצר, ותוכנית קבועה — רקע יציב שיש להתחשב בו בכל חישוב יתרה. מבחירת המצב תלוי גם העומס על החשבונאות, וגם אילו הגבלות על סכמות בונוס יהיה צורך להציג מיד.

ההגבלות מתוכננות מראש: תקרת זיכויים לשחקן ולפרק זמן, תנאי מימוש, תקופת חיים של הבונוס, כללי ביטול בעת החזרת הימור. סכמת זיכוי פריספינים בדרך כלל קשורה למשחק מסוים ולשווי ההימור — זה משנה גם את החשבונאות וגם את היקף ההתאמות עם ספק המשחקים.

מצב מתי מתאים הגבלות
מבצעי בונוס חד-פעמיים השקה, אירוע, משיכת שחקנים חדשים עומס שיא על החשבונאות, הגדרה ידנית לכל מבצע, סיכון לזיכוי כפול בחזרה של אירוע
תוכנית בונוס קבועה בסיס פעיל, פעילות סדירה התחייבויות מצטברות: נדרשת חשבונאות של בונוסים שלא מומשו והתאמה סדירה
מכניקות מצטברות: סדרות, רמות שימור, סשנים ארוכים יש לשמור ולשחזר התקדמות לאחר תקלה, קשה יותר לבטל זיכוי
פריספינים לפי אירוע פעילות הפעלה מחדש, קישור למשחק אחד קישור נוקשה למשחק ולהימור, יותר התאמות עם הספק

בפועל משלבים מצבים: תוכנית קבועה מחזיקה רקע, ומבצעים חד-פעמיים יוצרים זינוקים לתאריך מסוים. זה עובד ביציבות רק עם יומן זיכויים אחיד, שבו כל אירוע מסומן במקור ובמצב — אחרת אי אפשר לאחד את הגבלות הסכמות ולהוכיח שהבונוס הונפק פעם אחת.

שלבי תכנון מעגל הבונוסים של קזינו

מעגל הבונוסים משנה את יתרת השחקן: מערכת הפריבטים, פריספינים, קאשבק והצעות הפקדה חיים במודל חשבונאי אחד. אם בונים אותו תוך כדי תנועה, הקונפליקט הראשון בתנאים יוצר זיכוי כפול או סטטוס תקוע. לכן את שלבי תכנון מערכת הבונוסים מקבעים לפני ההגדרה הראשונה.

  1. ביקורת כללי בונוס — מפרקים טריגרים, תקרות, דרישות מימוש, תקופות חיים ועדיפות בין מבצעים. בפלט מתקבלים מרשם כללים ורשימת סתירות.
  2. סכמת חשבונאות בונוסים — מפרידים בין כספים אמיתיים לכספי בונוס, מתארים סטטוסים, יומן פעולות ומפתחות אידמפוטנטיים, כך שבקשה חוזרת לא תכפיל את הזיכוי.
  3. תכנון לוגיקת ההנפקה — קושרים בונוסים לאירועים (הפקדה, הימור, סדרת הפסדים) וקובעים היכן מחשבים מימוש והיכן רק מתעדים התקדמות.
  4. הגדרה ואינטגרציה — קובעים כללים, מחברים את המעגל לספקי משחקים, לתשלומים ולאזור האישי, ומחלקים הרשאות מפעיל.
  5. בדיקת זיכוי בונוסים — מריצים תרחישים: בקשות מקבילות, ביטול הימור, החזרת הפקדה, יתרה שלילית, פקיעת תוקף, תיקון ידני.
  6. עמידות בתקלות — בודקים הנפקות שיא והתנהגות כאשר הספק אינו זמין; היומן והחתכים של המצב מאפשרים לחשב מחדש את היתרה ולבטל שגיאה.
  7. מסירת מערכת הבונוסים — תיעוד, נהלי עבודה עם בונוסים, הרשאות והדרכה: צוות הלקוח עצמו משיק מבצעים חדשים.

מערכת הפריבטים והפריספינים: מה מוסרים ללקוח

אנחנו מוסרים לא "קוד שעובד אצלנו בסביבת הבדיקות", אלא ערכה שנפרסת במעגל שלכם ונבדקת שלב אחר שלב. מערכת הפריבטים נבנית מחלקים בלתי תלויים: כללים משתנים בלי לתקן את הליבה, היומן מופק כולו, והגישה ניתנת לפי תפקידים. להלן מה בדיוק מגיע לידי הצוות שלכם.

  • תצורת כללי בונוס: סוגי פרסים, תקרות לשחקן, חלונות פעילות, עדיפות מבצעים בחפיפה של מועדים. כלל חדש מוזן על ידי עריכת תצורה, ולא על ידי מהדורה חדשה.
  • סכמת זרימות זיכוי: נתיב מהטריגר — הפקדה, סדרת הימורים, תקופת מבצע — ועד זיכוי פריספינים ופריבטים, עם נקודות הגנה מפני זיכוי כפול וטיפול בתקלות בכל שלב.
  • מדיניות גישה לבונוסים: תפקידי מפעיל, אנליטיקאי ומבקר, מטריצת הרשאות להנפקה, ביטול ותיקון ידני, הגבלות לפי סגמנטים של שחקנים ותחומי שיפוט.
  • יומן פעולות בונוס: רשומות בלתי משתנות עם יוזם, סיבה, גרסת כלל וקישור לעסקה המקורית — לפיו מפרקים כל אי-התאמה ביתרה.
  • נהלי הפעלה: סדר ביטול זיכוי, זמני תגובה לאירוע, נקודות הסלמה ואחראים בצד הלקוח.
  • תיעוד מערכת הבונוסים: תיאור ישויות ושדות, הוראות להוספת סוג פרס חדש, רשימת בדיקות לפני השקת מבצע.

הקבלה נעשית על מעגל נקי: פורסים, מריצים תרחישי בקרה, ומשווים את היומן לתוצאה הצפויה. אם זה מתאים — הערכה שלכם ונתמכת על ידי הצוות שלכם בלי מעורבות שלנו.

מקרה בוחן: כיצד מעגל הבונוסים הפסיק לאבד זיכויים

היכן אבדו הזיכויים

מקרה בוחן של מערכת בונוסים: אצל מפעיל עם פריבטים ופריספינים, הפרסים הגיעו מארבעה מקורות — מכניקות מבצע, קמפיינים שותפים, קאשבק ותיקונים ידניים של מנהלים. כל מקור כתב לטבלה משלו, והיתרה הסופית נאספה בהתאמת לילה, שלא הסתדרה אם אירוע הגיע שוב.

השורש לא היה בנוסחאות הזיכוי, אלא בהיעדר נקודת רישום אחידה. שתי בקשות מקבילות לאותו פריספין יצרו זיכוי כפול, מבצע שבוטל השאיר יתרה "תלויה", והפערים הגיעו ל-6-8% מהיקף יומי — בערך באותה מידה של מחלוקות עברו לתמיכה.

מה שינינו ומה קיבלנו

העברנו את מעגל הבונוסים ליומן אירועים: זיכוי, ניכוי ופקיעה — רשומות נפרדות עם מפתח פעולה ייחודי. את היומן הצבנו ב-PostgreSQL עם אינדקס ייחודי על המפתח הזה, ולכן אירוע חוזר מהמקור אינו יוצר רשומה שנייה, והיתרה מחושבת מהיומן ולא נשמרת כשדה נפרד שנמחק בבקשות מקבילות.

ביטול כוסה באותו פתרון: היומן בלתי משתנה, וחישוב מחדש של כל תקופה משחזר את אותה תמונה שהייתה ברגע הזיכוי. יתרות ישנות הועברו עם סכומי ביקורת לכל שחקן — הפערים אופסו לפני הפעלת הכללים החדשים, ולא אחרי.

פערים לפני ואחרי: שיעור הזיכויים השנויים במחלוקת ירד מ-6-8% לשברירי אחוז. זמן התאמת הבונוסים התקצר מנוהל לילה של כמה שעות לדוח שנבנה בדקות, ופניות לתמיכה בנושאי בונוסים ירדו פי 4-5 — השחקן רואה בהיסטוריה את הסיבה לכל זיכוי, והמנהל מפרק מחלוקת לפי מפתח הפעולה, בלי להוציא הפקות.

במה פריבט נבדל מפריספין בחשבונאות התחייבויות

פריבט הוא הימור על חשבון המפעיל: השחקן מהמר בלי חיוב כספיו, וההתחייבות תלויה בתוצאת האירוע ובמקדם, ולכן ידוע מראש רק גבול התשלום העליון. פריספין הוא מספר סיבובים קבוע בסלוט עם מחיר סיבוב ידוע: עלות ההתחייבות נקבעת מיד עם ההנפקה.

מכאן ההבדל ברגע ההכרה. פריספין נכנס למרשם ההתחייבויות ברגע הזיכוי — הכמות ומחיר הסיבוב כבר ידועים. פריבט נשאר מותנה עד לחישוב ההימור: להכיר בו מראש פירושו להפריז ביתרה על כל הקופונים שלא מומשו.

בנקודת המפגש הזו מתפצלים הנתונים במערכת הפריבטים ובחשבונאות הפיננסית — הזיכוי או מוכפל או הולך לאיבוד.

תקרות על בונוסים נספרות ביחידות שונות: פריספינים — ביחידות סיבובים לשחקן, לסלוט ולפרק זמן; פריבטים — בשווי ההימור ובמספר הקופונים, שהרי עלותם משתנה יחד עם המקדם. כדי לאחד את זה ואת זה לתקציב אחד של התוכנית, שני הגדלים מובאים לעלות צפויה ורק אחר כך משווים אותם לתקרה הכללית.

גם ההתאמה שונה. אצל פריספינים נקודות הבקרה — הנפקה, שימוש בפועל ויתרת סיבובים שלא נוצלו; אי-התאמה משמעה אובדן אירוע או רישום כפול. אצל פריבטים מתאימים סכומי הימורים מחושבים, מקדמים ושיעור קופונים שלא חושבו, שתלויים כהתחייבות מותנית. אם שני הסוגים נמצאים באותה טבלה בלי סימן לאופי ההתחייבות, אי-ההתאמה אינה מאותרת, והתקרות זזות.

לכן במודל הנתונים אלה שני סוגי התחייבות שונים: רגע הכרה משלהם, מוני תקרות משלהם, סדר התאמה משלהם. אז הדוח על תוכנית הבונוסים מתאים, ופריבטים שלא חושבו אינם מעוותים את היתרה.

ספקות טכניים לגבי ארכיטקטורת הבונוסים

לפני שקובעים את הארכיטקטורה, לקוחות בודקים את עמידותה בשלושה תרחישים: זיכוי חוזר, ביטול בונוס שכבר הונפק ושינוי כללי מבצע תוך כדי תנועה. להלן תשובות ישירות לשאלות הנדסיות נפוצות לגבי ארכיטקטורת הבונוסים: כיצד המקרים האלה נסגרים במערכת הפריבטים בלי תיקונים ידניים ועצירת מבצע.

מה יקרה אם בונוס יזוכה פעמיים?

כל זיכוי קשור למפתח אירוע — ניסיון הימור, תשלום או השגת תנאי. הגעה חוזרת של אותו אירוע אינה יוצרת רשומה שנייה: המערכת משווה את המפתח ליומן הפעולות ומחזירה את התוצאה שכבר קיימת. הרצה חוזרת של עיבוד התור ושל עבודות תחזוקה בטוחה — היתרה אינה מוכפלת.

האם אפשר לבטל בונוס לאחר זיכוי?

ביטול אינו מחיקה, אלא רישום מקזז ביומן בלתי משתנה: רואים מי יזם, מאיזו סיבה ומה קרה ליתרת השחקן. אם פריספינים סובבו חלקית או שהפריבט מומש, היתרה מחושבת לפי תמונת מצב ברגע הביטול, ולא בחישוב מחדש של כל ההיסטוריה.

כיצד לשנות כללי מבצע בלי לשבור בונוסים שהונפקו?

הכללים מנוהלים בגרסאות: למבצע יש סט תנאים עם תאריך תחילה. בונוס שהונפק לפי הגרסה הקודמת מומש לפיה — שינוי תנאים אינו כותב מחדש את ההיסטוריה ואינו יוצר מצבים שנויים במחלוקת עם שחקנים. הגרסה החדשה חלה רק על זיכויים עתידיים.

נדון במשימה: ממה מתחיל מעגל הבונוסים

השיחה הראשונה עם מהנדסים אינה מצגת, אלא הסרת אי-ודאות. כדי לדון במערכת הבונוסים ובבקשה לתכנון באופן ענייני, יש צורך בנתוני קלט להערכה: כללי זיכוי, מודל חשבונאי, נקודות אינטגרציה ופרופיל עומס. ככל שנתוני המקור קונקרטיים יותר, כך יש פחות הנחות בתוכנית העבודה על בונוסים.

  • כללי זיכוי: סוגי בונוסים — פריספינים, פריבטים על ספורט, קאשבק — תנאי מימוש, תקופת חיים, התנהגות בביטול הימור או בחוסר פעילות של שחקן.
  • מודל חשבונאי: כיצד מופרדים יתרת בונוס ויתרה אמיתית, באיזה סדר מנכים כספים, כיצד מחושבת תרומת ההימור למימוש.
  • מקורות אקראיות ודיווח: מי מנפיק פריספינים וכיצד מתעדים את תוצאת הסיבוב — מחולל פנימי או צד ספק המשחק.
  • נקודות אינטגרציה: מעגל תשלומים, ספקי משחקים, אנטי-פראוד ו-CRM — לפי אילו אירועים מתבצעת החלפת נתונים, בזמן אמת או בהפקות.
  • הגבלות: תחומי שיפוט, תקרות לשחקן, דרישות לאחסון היסטוריה, למי יש זכות לשנות כלל וכיצד זה מתועד.
  • פרופיל עומס: גודל הבסיס הפעיל, תדירות שיא של הימורים וסיבובים, השהיה מותרת בזיכוי בונוס.
  • המעגל הנוכחי: מה כבר עובד, אילו צווארי בקבוק ידועים, מה אסור לשבור במעבר.

מנתוני הקלט האלה אנחנו מרכיבים תוכנית עבודה על בונוסים: סכמת חשבונאות וארנקים, שירות זיכוי, עיבוד אירועים, דיווח וסדר מעבר עם אפשרות חזרה למעגל הקודם. תארו את המשימה — נחזור עם הערכה והרכב שלבים.