למה קליטת תשלומי TON נשברת בפרודקשן
קליטת תשלומי TON נראית טריוויאלית: יצרנו כתובת, הצגנו QR, המתנו לטרנזקציה. בפרודקשן מתברר שהרשת מאשרת תשלום באופן אסינכרוני — מצב הארנק משתנה לא ברגע לחיצת הכפתור, אלא כשההעברה נכנסת לבלוק.
קלאסיקה — התשלום נשלח, אבל האישור לא הגיע: האינדקסר פיגר, ה-Webhook אבד בזמן פריסה, המטפל קרס על תגובה לא צפויה. הזיכוי לא עבר, היתרה לא השתנתה, ופנייה לתמיכה מגיעה לפני הטרנזקציה.
תרחיש נפרד — העברה תקועה: העמלה הוגדרה נמוכה מהעומס הנוכחי, וההודעה תלויה בתור — בלי אישור ובלי דחייה.
כתובת גם "צפה": בעת יצירת כתובת חדשה לכל חשבונית, ההתאמה "כתובת — הזמנה" אובדת בהפעלה מחדש של השירות, ברוטציית ארנק או במטמון. ב-TON Connect המשלם מעביר מהארנק שלו, וניתן לקשר את התקבול לחשבונית רק לפי ההערה וגוף ההודעה.
אצל Jetton מתווסף שכבה: מגיע לא מטבע, אלא העברה עם payload, ובלי לפרסר את השדה הזה אי אפשר להתאים את התשלום להזמנה.
מכאן שני סוגי כשל יקרים: התאמה ידנית של תשלומים וזיכוי כפול. מסירה חוזרת של Webhook או retry של המטפל מזכים את הסכום פעמיים, ואי-התאמות מחפשים בדוח החשבון רק אחרי תלונת הלקוח.
נבחן כיצד זה נסגר: אידמפוטנטיות ברמת האירוע, cursor על העברות נכנסות והתראות על עיכוב באישורים.
מה משתנה לאחר ההטמעה: מהירות, התאמה, כשלים
האפקט של ההטמעה נמדד לא לפי עצם חיבור הארנק, אלא לפי כמה תשלומים המערכת סוגרת בעצמה. לפני האוטומציה כל תשלום נכנס הותאם ידנית: סכום והערה להעברה הושוו להזמנה, והעברה תקועה התגלתה רק כשהלקוח כתב לתמיכה.
TON Connect עם אישור העברות בצד השרת ומטפל Jetton מעביר את העבודה הזו לקוד — מהנדסים מגדירים זיכוי לפי אירוע מהרשת, ולא לפי דוח חשבון.
צ'קליסט שלפיו אנחנו מקבלים את התוצאה:
- שיעור התשלומים שנזקפים אוטומטית — 95%+ מכלל התשלומים. לבדיקה ידנית מגיעים רק מקרים לא סטנדרטיים: העברה בלי הערה, תשלום חסר, תשלום לכתובת לא נכונה.
- זמן אישור התשלום — את הזיכוי מגדירים לפי מספר האישורים הנדרש ברשת; יתרת ההזמנה מתעדכנת בתוך עשרות שניות במקום התאמה פעם בשעה.
- תגובה להעברה תקועה — צופה רקע בודק מחדש את הסטטוס ומעלה התראה בתוך דקות, ולא אחרי פניית הלקוח.
- שיעור הפעולות הידניות — יורד משליש מהטרנזקציות לאחוזים בודדים; הנהלת החשבונות מקבלת יומן מוכן עם התאמת "טרנזקציה — הזמנה — סכום".
- סוג הכשל שנעלם — זיכוי לחשבון של מישהו אחר, כפילות בשליחה חוזרת, תשלום שאבד בלי הערה נסגרים באמצעות כתובת-לחשבונית והגנה מזיכוי חוזר לפי hash.
- Jetton על אותם מסלולים — תשלומי טוקנים עוברים דרך אותו קו זיכוי, עם התחשבות נכונה בספרות עשרוניות.
אפשרויות אינטגרציה: TON Connect, Jetton, שליחה ישירה
מצב הקליטה קובע כמה לוגיקה נשארת בצד השירות. חיבור ארנק מוסר ללקוח את חתימת הטרנזקציה, העברת טוקן דורשת התאמת יתרה נפרדת, ושליחה ישירה לכתובת היא התרחיש הפשוט ביותר, אבל גם העיוור ביותר. להלן השוואה בשלושה צירים: מה שירות התשלומים רואה, מה צריך לאשר ידנית ואיך נראה החזר.
| אפשרות | מתי מתאימה | מגבלות אינטגרציה |
|---|---|---|
| TON Connect (חיבור ארנק) | מנויים, אזור אישי, תשלום בתוך הממשק עם אישור בארנק | להחזיק רשימה מעודכנת של אפליקציות תואמות, לטפל נכון בסירוב של המשתמש, לעקוב אחרי החלפת רשת בארנק |
| העברה בטוקן (Jetton) | סליקה בנכס משלכם, כשהנקוב לא תואם למטבע הבסיסי | לבדוק שהגיע הטוקן שלכם ולא העתק עם שם דומה; בנפרד להתחשב בספרות עשרוניות ובכתובת השולח |
| שליחה ישירה לכתובת | תרומות, טעינת יתרה, קליטה בלי ממשק משתמש | להתאים תשלום להזמנה לפי סכום והערה, לטפל ידנית בהעברות שנויות במחלוקת, אין אישור מהמשלם |
בפועל משלבים בין המצבים: חיבור ארנק סוגר את הזרימה העיקרית, שליחה ישירה משמשת כערוץ גיבוי, והעברות טוקן מפעילים רק במקום שבו סליקה במטבע הבסיסי לא נוחה. המשותף לכולם נשאר אחד — יומן משלכם של טרנזקציות נכנסות עם עיבוד עמיד למסירה חוזרת, אחרת העברה אחת הופכת לשני זיכויים.
איך מתקדמת ההטמעה: מביקורת ועד מסירת נהלים
את העבודה מובילים בשלבים: תחילה מתעדים איך מגיעים תשלומים ואיפה מאושרת עובדת התשלום, אחר כך מגדירים קליטה, לאחר מכן בודקים על העברות אמיתיות ומוסרים נהלים. את הסדר לא משנים — אודיט שהוחמץ בדרך כלל צף כבר בבדיקה, כשהעלות של שינוי הסכימה גבוהה יותר.
אודיט וסכימה
- אודיט של זרימות תשלום. מפרקים סוגי תשלום — חד-פעמיים, מנויים, טעינת יתרה, החזרים — ובודקים איך עובדת התשלום מקושרת להזמנה במערכת החשבונאית.
- סכימת אישורים. מסכמים מה נחשב תשלום: רישום ההעברה בבלוק, מספר אישורים או אירוע מהארנק. מזה תלויים רגע שינוי סטטוס ההזמנה והלוגיקה של ביטולים עם שליחות חוזרות.
- התאמת תשלום להזמנה. בוחרים שיטת קליטה — העברה ישירה לכתובת, חיבור ארנק דרך TON Connect או קליטת טוקנים — וקובעים מזהה שלא יאבד בהזמנות מקבילות.
הגדרה ובדיקה
- הגדרת קליטה ואוטומציה. השירות מאזין לרשת, מתאים העברות להזמנות ומשנה את הסטטוס שלהן; בנפרד מגדירים בדיקות חוזרות לטרנזקציות שמאושרות לא באופן מיידי.
- העברות בדיקה. תחילה ריצה ברשת בדיקה, אחר כך העברות אמיתיות בסכומים מינימליים: הצלחה, תשלום חסר, העברה בלי מזהה, שליחה חוזרת. כל תרחיש — שורה בדוח עם סטטוס.
קבלה ומסירה
- קבלה. מתאימים סטטוסים של הזמנות לתנועת הכספים, בודקים יומנים, התראות והתנהגות בזמן אי-זמינות של צומת.
- מסירת נהלים. מוסרים הוראות לניטור, סדר פעולות בתקלה, כללי התאמה והוספה של טוקנים חדשים — הצוות מתחזק את קליטת התשלומים בעצמו.
מה נשאר אצלכם: קונפיגורציה, מפתחות, תיעוד
אנחנו מוסרים לא גישה לשרת, אלא סט ארטיפקטים שניתן לשחזר: איתו הצוות שלכם קולט תשלומים, משנה פרמטרים ומטפל בתקריות בלי ההשתתפות שלנו. כל מה שקשור לתנועת כספים מתועד בכתב — בתשלומים הסכמות בעל פה לא עובדות.
- קונפיגורציית קליטה: קובצי סביבה עם כתובת הנמען, רשימת Jetton נקלטים, מגבלות על סכום ומספר אישורי רשת, עם הערות מה ומתי לשנות.
- סכימת כתובות: איזה ארנק חם, איפה שמירה קרה, איך מוגדר משיכת כספים ולאן הולכת העמלה.
- ניהול מפתחות: איפה נמצאים מפתחות פרטיים ומנמוניות, מי מורשה אליהם, איך מתבצעת רוטציה ומה לעשות במקרה של חשיפה. המפתחות נשארים אצלכם — אנחנו עובדים על קו בדיקה.
- מדיניות גישה: תפקידים והרשאות מינימליות, אישור שני חובה למשיכה, יומן פעולות עם ציון היוזם והשעה.
- כללי התאמה: איך טרנזקציה נכנסת מותאמת להזמנה, מרגע מה התשלום נחשב מאושר ואילו אי-התאמות עוברות לבדיקה ידנית.
- תיעוד: סכימת זרימות תשלום, תיאור אינטגרציית TON Connect בצד הממשק, רשימת חוזים עם כתובות, סדר עבודה עם רשת בדיקה.
- הוראות לתמיכה: תרחישים מוכנים לפניות נפוצות — תשלום לא הגיע, הסכום קטן מהצפוי, המשתמש סגר את הארנק לפני אישור, משיכה תקועה.
- נוהל שינויים: איך נפרסת קונפיגורציה חדשה, איפה נשמרת הגרסה הקודמת ואיך מבצעים rollback בצעד אחד.
מקרה בוחן: ההתאמה הידנית הצטמצמה, התשלומים התקועים נעלמו
איך זה היה
לפני האוטומציה קליטת תשלומי TON נראתה כך: מפעיל פתח סייר רשת, חיפש העברה נכנסת, השווה את ההערה לטרנזקציה עם מספר ההזמנה ושינה ידנית את הסטטוס במערכת החשבונאית. בזרימה של כמה אלפי הזמנות בחודש עברו דרך הידיים כ-40% מהזיכויים, ומחוץ לשעות העבודה התשלום חיכה לאישור עד הבוקר.
תשלומים תקועים — אי-התאמת סכום, טעות הקלדה בהערה, שליחה חוזרת — הגיעו ל-4-6% וטופלו בהתכתבות עם התמיכה. כל מקרה כזה דרש התאמה ידנית לפי היומן ועיכב סגירת הזמנה.
מה שינינו ומה קיבלנו
חיברנו TON Connect לחתימה בארנק, ואת הזיכוי העברנו לאינדקסר: השירות מאזין לרשת, מתאים העברות נכנסות לחשבוניות פתוחות וסוגר את החשבונית אוטומטית. עבור Jetton הוספנו התאמה לפי כתובת חוזה המאסטר של הטוקן והדיוק שלו — בלי זה סכומים זהים בטוקנים שונים היו מתמזגים.
לכל חשבונית הוקצה מזהה ייחודי בהערה להעברה, הרישום אידמפוטנטי לפי hash של הטרנזקציה, הזיכוי מתבצע אחרי מספר אישורים מוגדר, ומקרים לא מטופלים עוברים לתור עם ניסיונות חוזרים והתראה לתורן.
שיעור האישורים האוטומטיים עלה ל-97-99%: התאמה ידנית נשארה רק להעברות שנויות במחלוקת — אי-התאמת סכום, תשלום בלי הערה, החזר. זמן הזיכוי הממוצע הצטמצם מעשרות דקות ל-30-90 שניות והפסיק להיות תלוי בלוח הזמנים של המפעילים, ושיעור התשלומים התקועים ירד מתחת ל-0.3%.
במה שונה העברה נטיבית מהעברת Jetton?
ברשת TON העברה נטיבית היא תנועה של מטבע הבסיס: עצם הסליקה חופף לשינוי היתרה. כדי לזכות תשלום, מספיק להמתין שטרנזקציה תיכלל בבלוק ומספר האישורים הנדרש — אין קריאה שנייה לחוזה, התשלום או עבר במלואו או לא עבר.
Jetton — חוזה טוקן: ההעברה עוברת כהודעה לארנק הטוקן של השולח, הוא מחייב את היתרה ומודיע לארנק הנמען. גבול האישור כאן הוא לא הטרנזקציה הראשונה, אלא ההודעה עצמה: עד שיתרת הנמען לא תתעדכן, אסור לזכות את התשלום.
בפועל אלה שני קווי קליטה שונים לתשלומים. עבור נטיב השירות מאזין לטרנזקציות נכנסות לכתובת ומאשר אותן לפי מספר בלוקים. עבור Jetton הוא או ממתין להודעה עם הערה להעברה, או מתאים יתרת ארנק טוקן ומשווה את ההעברה לפי מזהה.
אם התשלום מגיע מבורסה, ההערה לרוב אובדת — לכן בקו אחד מנפיקים כתובת ייחודית לכל חשבונית, ובאחר דורשים הערה חובה.
עמלות הרשת גם מתנהגות אחרת. בהעברה נטיבית את ה-gas משלם השולח, ולנמען אין מה לשמור. ב-Jetton השולח משלם פעמיים — על ההעברה ועל מסירת ההודעה: צורפה מעט מטבע בסיסי, הטוקנים הגיעו, ההודעה לא, והתשלום צף רק בהתאמה. בארנק הטוקן שלכם צריך מלאי של מטבע בסיסי, אחרת לא תצא לא החזרה ולא משיכה.
החזרים. עבור נטיב החזר הוא טרנזקציה רגילה מהארנק החם: עמלה אחת, תוצאה צפויה. עבור Jetton החזר יוצא מארנק הטוקן, העמלות על המסירה מחויבות בצד השולח, וסכום ההחזר עשוי להיות קטן מהמקורי.
לכן בשני הקווים מכניסים התאמה אידמפוטנטית לפי מזהה טרנזקציה ותור של תשלומים "תקועים", ובוחרים לפי התרחיש: נטיב — במקום שבו חשובים פשטות ותשלומים המוניים, Jetton — במקום שבו התשלום צריך להיות בטוקן עם קישור לנכס חיצוני.
ספקות טכניים נפוצים ותשובות
ספקות בקבלה חוזרים שוב ושוב: איך לא לזכות העברה אחת פעמיים, מה יקרה כשמחליפים כתובת ארנק, מי מהצוות רואה פעולות ואיך כל זה מתיישב עם הנהלת החשבונות הנוכחית. אלה המקומות שבהם האינטגרציה או מחזיקה את הזרימה, או מתחילה לדרוש התאמות ידניות — נפרק כל אחד.
התשלום אושר פעמיים — תזכו פעמיים?
לא. כל תשלום נכנס מקבל מזהה ייחודי, והמטפל מתאים אותו ליומן לפני הזיכוי. אישור חוזר של אותה העברה מטופל באופן אידמפוטנטי: ההזמנה מתעדכנת פעם אחת, ושאר הקריאות מחזירות את התוצאה השמורה.
החלפנו כתובת קליטה — תשלומים ישנים לא יאבדו?
לא, אם הכתובות נשמרות כספר עזר ולא כתובות בתוך הלוגיקה. מנהלים מרשם התאמות "כתובת — ארנק — ייעוד", ההיסטוריה נשארת זמינה, והכתובת החדשה מתחברת בלי שינויי קוד. בתקופת מעבר סורקים את שתי הכתובות במקביל.
איך זה מתיישב עם הנהלת החשבונות הנוכחית?
הייצוא מתבצע בפורמט שהמערכת החשבונאית שלכם מקבלת: מזהה, סכום, ייעוד, סטטוס. ההתאמה מתבצעת אוטומטית, אי-התאמות נכנסות לרשימה נפרדת עם סיבה, ולא לבדיקה ידנית. אם הנהלת החשבונות בסביבה סגורה — מוסרים קובץ או מעבירים נתונים לפי לוח זמנים.
אילו עובדים יקבלו גישה לפעולות?
תפקידים מוגדרים לפי הרשאות מינימליות: הנהלת החשבונות רואה ייצוא וסטטוסים, התמיכה — רק תשלום מסוים לפי מספר הזמנה, ומפתחות המשיכה נשארים אצל אחראי אחד. כל פעולה נרשמת ביומן, כך שנראים גם המבצע וגם הזמן.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
כדי לחזור עם הערכת עבודה מדויקת, ולא עם טווח "בערך", אנחנו צריכים סט קטן של נתוני מקור על סכימת הקליטה שלכם. מפתחות פרודקשן והרשאות בשלב הזה לא נדרשים — מספיק תיאור של איך התשלומים בנויים כיום ומה צריך להתקבל בסוף.
- סכימת קליטה: חיבור ארנק דרך TON Connect באפליקציה או באתר, תשלום לפי כתובת או בהעברת טוקנים;
- איך נוצרת כתובת לתשלום: סטטית, אחת לפעולה, עם מזהה בהערה;
- מאיפה מגיע אישור הזיכוי: צומת משלכם, סייר בלוקים ציבורי או התראות של ספק;
- מה קורה במקרה של תשלום חסר, תשלום יתר, העברה בלי הערה ושליחה חוזרת;
- נפחים: מספר תשלומים ביום ועומס שיא, כמה טוקנים וכתובות מתוחזקים;
- הנהלת חשבונות והתאמה: ייצוא פעולות, התאמה לבסיס נתונים פנימי, תפקידים והרשאות עובדים;
- מגבלות: איפה נשמרים מפתחות, האם יש דרישות להפרדת סביבות ואודיט פעולות.
עם הסט הזה אנחנו חוזרים עם הערכת עבודה ותוכנית הטמעה: סדר שלבים, מה סוגרים ראשון, איפה נקודות בדיקה ומה יידרש מהצד שלכם. תארו את המשימה בצורה נוחה — ננתח את סכימת קליטת התשלומים ונציע פתרון.