פיתוח בוט טלגרם להחלפת מטבעות קריפטוגרפיים ב-P2P

בוט Telegram לחילופי P2P: היכן העסקה נשברת

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

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

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

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

להלן נפרק איך הצמתים האלה נסגרים בקוד, ולא בהוראה למפעילים.

מה משתנה אחרי ההשקה: מהירות העסקה ובירור מחלוקות

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

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

אי-התאמה בסכום, פרטי תשלום של מישהו אחר או תשלום כפול עוברים למפעיל עם תמצית מוכנה — שיעור המחלוקות בלי מעורבותו נשמר ברמה של 70-80%.

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

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

סכמות לביצוע העסקה: נעילה אוטומטית, ערב, היברידי

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

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

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

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

הטמעה שלב אחר שלב: מביקורת הזרמים ועד למסירה

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

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

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

מסירה: סכמת העסקה, נהלים, הרשאות ותיעוד

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

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

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

מקרה בוחן: צ'יינג' עם מודרציה ידנית הועבר לאוטומציה

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

מה הראו המטריקות לפני

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

מה שינו

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

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

מה נהיה

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

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

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

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

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

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

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

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

התלבטויות של מהנדס: לימיטים, מפתחות, עסקאות תקועות

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

היכן נשמרים מפתחות הארנק ואיך מופרדות הרשאות הגישה?

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

מה קורה כשתשלום נתקע?

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

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

איך נבדק הצד שכנגד לפני העסקה?

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

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

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

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

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

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