התאמה בין תשלומים של iGaming: מרישומי השחקנים ועד חשבון הבנק

אילו רשומות צריך לחבר?

הפקדת שחקן, תשלום שחיובו הושלם (capture) והסדר בנקאי הם אירועים קשורים אך שונים. דיווח ההסדר של Adyen ממחיש רשומות ועלויות ברמת העסקה שיכולים לתמוך בהתאמה.

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

מהן שלוש רמות ההתאמה?

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

כיצד יש לסווג הבדלים?

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

• תשלומים שאושרו אך חיובם טרם הושלם (capture).
• עסקאות שחיובן הושלם אך טרם סולקו.
• עמלות והפרשי המרת מטבעות.
• ניכויים לרזרבה ושחרור כספי רזרבה.
• החזרים, היפוכים ותנועות חיוב חוזר.
• אירועים משוכפלים, חסרים או ממופים שגויים.

מה מראה דוגמה מעובדת?

נניח שאצווה מכילה 10,000 יחידות של הפקדות שסולקו, 300 יחידות עמלות, 1,000 שנמשכו כרזרבה ו-500 החזרים. תשלום נטו להמחשה הוא 8,200 יחידות. ההפרש של 1,800 מההפקדות ברוטו הוא לא הכל הוצאה: למרכיביה יש השלכות חשבונאיות ונזילות שונות.

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

איך הופכים את הבקרה לאמינה?

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

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