פיתוח תוכנית הפניות לבורסת קריפטו מקצה לקצה

פיתוח תוכנית הפניות לבורסת קריפטו: צווארי בקבוק

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

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

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

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

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

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

מה נותנת האוטומציה: מהירות זיכויים, אנטי-פראוד, דיווח

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

זיכויים והתאמות

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

אנטי-פראוד ודיווח לשותפים

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

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

השוואה בין אפשרויות רישום הפניות לבורסת קריפטו

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

איך לבחור אפשרות בהתאם לעומס הנוכחי

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

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

שלבי העבודה: ביקורת, סכימת זיכויים, הגדרה, בדיקה, מסירה

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

ביקורת וסכימת זיכויים

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

בדיקה ומסירה

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

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

מה כלול בחבילה: סכימות רישום, מדיניות גישה, נהלים

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

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

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

מקרה בוחן: איך חישוב מחדש ידני הוחלף ברישום אוטומטי

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

מה היה קודם

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

מה נהיה אחרי

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

איך העבירו את היסטוריית הזיכויים

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

במה שונה תוכנית הפניות מתוכנית שותפים

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

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

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

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

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

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

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

ספקות טכניים: מגבלות, אנטי-פראוד, מיגרציית נתונים

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

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

מה קורה אם עוברים את המגבלה?

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

אפשר להעביר היסטוריה בלי לעצור את המסחר?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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