חיבור ארנק TON ל-dApp: אינטגרציה של Tonkeeper דרך TON Connect

אינטגרציית Tonkeeper נשברת בשלב חתימת העסקה

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

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

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

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

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

שיעור העסקאות המאושרות וכניסות חוזרות

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

זמן החיבור של משתמש חדש

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

סוגי סירובים שמפסיקים להגיע לתמיכה

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

מצבי חיבור הארנק והמגבלות הטכניות שלהם

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

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

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

סדר העבודה: מניתוח תרחישים ועד מסירה

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

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

בדיקה לפני עלייה לאוויר

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

מה מועבר לידיים לאחר אינטגרציית Tonkeeper

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

תוצרים למהנדסים

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

תזכיר לתמיכה

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

מקרה בוחן: שיעור החתימות הכושלות ירד מ-12% ל-2%

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

מה שינו

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

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

במה שונה ארנק בדפדפן מארנק בטלפון?

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

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

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

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

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

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

האם נדרש שירות נפרד לבדיקת החתימה?

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

האם אפשר להחזיק כמה ארנקים בו-זמנית?

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

מי אחראי לעדכון אם הארנק משנה משהו אצלו?

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

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

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

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

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

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