החלפת טוקנים בארנק נייד: היכן נשבר המסלול
החלפת טוקנים בארנק נייד — זה לא עסקה אחת, אלא שרשרת: בקשת ציטוט מאגרגטור, חתימה, שליחה לרשת והמתנה לאישור. הציטוט חי בחלון קצר — במהלכו מצב הבריכות משתנה, והמספר שהמשתמש ראה על המסך מפסיק להיות מעודכן. כשהאפליקציה בחזית, השרשרת בדרך כלל עוברת במלואה.
הכשל מתחיל באישור. המשתמש עובר לאפליקציית הבנק, למסנג'ר לקבלת קוד או לדפדפן, ומערכת המובייל מפנה את הארנק מהזיכרון. הבקשה החתומה כבר נשלחה, אך מסך המצב אבד: האפליקציה לא יודעת אם הפעולה אושרה או שהרשת דחתה אותה. כך נוצרת החלפה שלא הושלמה — הטוקנים נגרעו, הנכס המיועד לא נזקף, ובהיסטוריית הפעולות אין רשומה.
הענף השני — אי-התאמת שער. המשתמש חוזר, רואה סכום מחושב מחדש שאינו תואם את זה שאושר, ומפרש זאת כאובדן כספים. בהמשך — נטישת המשתמש: הוא לא יגיש פנייה, פשוט ימחק את הארנק, והתמיכה תקבל תלונה בלי מזהה פעולה, האש וזמן חתימה, שלפיהם אי אפשר לשחזר את מהלך האירועים.
אנחנו מתכננים החלפה כפעולה מבוזרת עם יומן מצבים מקומי: את הציטוט ניקח מאגרגטורי נזילות, כולל 1inch, ואת התוצאה נתעד ללא תלות בשאלה אם המסך היה פעיל. להלן נפרט כיצד המסלול הזה נסגר — משחזור סשן ההחלפה לאחר החזרה לאפליקציה ועד לניתוח אירועים לפי לוגים.
מה נותנת החלפה מובנית: שיעור הפעולות שהושלמו ומהירות
ההחלפה בתוך הארנק אינה עוד כפתור על המסך, אלא מסלול ביצוע עצמאי לעסקה. המשתמש חותם על העסקה באותו מפתח כמו שאר הפעולות, בלי לעזוב את האפליקציה ובלי להעביר את משפט השחזור לאתר צד שלישי. עבור המוצר הדבר מסיר את מקור האובדן העיקרי — קטיעת התרחיש במעבר לשירות זר.
שיעור ההחלפות שהושלמו הוא המדד המרכזי של ההטמעה. בתרחיש של יציאה לפלטפורמה חיצונית, עד לאישור מגיעים 55–70% מהפעולות שהתחילו: חלק מהקהל נזהר מדומיין לא מוכר, וחלק מאבד את הסכום שהוזן בעת חיבור מחדש. לאחר העברת ההחלפה לתוך האפליקציה המדד נשמר ברמה של 92–97%, וההבדל נראה כבר בשבועות הראשונים.
את מסלול ההחלפה מרכיב אגרגטור: הסכום מתפצל בין כמה בריכות ופלטפורמות, ולכן החלקה של המחיר בהיקפים גדולים נמוכה יותר מאשר בעסקה ישירה עם בורסה אחת. בשילוב עם 1inch אנחנו חוזים את המחיר הסופי לפני החתימה ומציגים סטייה מותרת — המשתמש רואה כמה יקבל, ולא מגלה זאת לאחר הביצוע.
כשלים של ספק מפסיקים להיות בעיה של המשתמש. אם מקור הציטוטים או צומת הרשת אינו זמין, הארנק בונה מחדש את המסלול או מחזיר שגיאה מובנת לפני חיוב הכספים, ולא משאיר את העסקה במצב תלוי. הזמן עד לאישור מתקצר בערך פי שניים: נעלמים חיבור נפרד לשירות חיצוני ואישורים מיותרים.
דרכים להטמיע החלפה: אגרגטור משלכם או שירות חיצוני
הבחירה בדרך ההחלפה קובעת מי אחראי למסלול העסקה ומאין מגיע המחיר.
אגרגטור עצמאי פונה בעצמו למקורות נזילות ומרכיב מסלול לזוג מסוים; שירות החלפה חיצוני מחזיר ציטוט מוכן בערוץ שלו; החלפה בחוזה חכם בתוך הארנק מבוצעת בלי מתווך; תוכנית היברידית משאירה את המסלול הראשי אצלה, ואת המסלול הגיבוי מפנה למקור חיצוני בעת ירידה.
כדאי להשוות אפשרויות לא לפי העיקרון של «טוב יותר או גרוע יותר», אלא לפי מה שהצוות מוכן להחזיק בצד שלו: רשימת מקורות הנזילות המחוברים, מדיניות העדיפות, האחריות לכשל במסלול והיקף העבודה בהוספת רשת חדשה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אגרגטור עצמאי | כמה רשתות ורשימת זוגות רחבה, יש צורך במדיניות עדיפות ועמלה משל עצמכם | צריך לתחזק אינדקס של בריכות ולעקוב אחר עדכוני הפלטפורמות — אחרת המסלול מתיישן בשקט |
| שירות החלפה חיצוני | הפעלה מהירה, מערך זוגות מצומצם, נכונות למסור את המסלול לספק | המחיר והזמינות תלויים בערוץ אחד; המגבלות ורשימת הרשתות נקבעות בידי השותף |
| החלפה בחוזה חכם | זוג מפתח אחד או שניים עם עמלה צפויה ומינימום אמון | הנזילות רק מבריכות מחוברות; הרחבת רשימת הזוגות נעשית ידנית |
| תוכנית היברידית | נדרשים שליטה עצמית ומסלול גיבוי למקרה של ירידת נזילות | שני מעגלי כשל: ניטור וניתוח פערים בין ציטוטים מורכבים יותר |
נפרט כיצד זה נסגר באפליקציה מסוימת: נדון במקורות הנזילות שלכם ונחזור עם הערכה ותוכנית.
כיצד מתבצעת ההטמעה: מביקורת ועד מסירה
הטמעת החלפת טוקנים בתוך הארנק היא עבודה עם כספי המשתמש במכשיר שבו אי אפשר לבטל עסקה. לכן אנחנו מתחילים בביקורת של הארנק, ולא בחיבור מסך ההחלפה.
- ביקורת הארנק. אנחנו בוחנים את מאגר המפתחות, מודול החתימה, הרשתות הנתמכות ומוכנות הממשק למסך הציטוט. מתעדים מה מפתחים ומה עושים בו שימוש חוזר כפי שהוא.
- סכימת מסלולים. מחליטים מאין נלקחים הציטוטים, כמה מקורות נבדקים במקביל ובמה מגבים את המסלול אם המחיר השתנה בין התצוגה לאישור.
- הגדרת מגבלות. קובעים מינימום ומקסימום להחלפה, החלקה מותרת, תקרות יומיות ומספר ניסיונות חוזרים — מסלול תקול לא יעביר יותר מהמתוכנן.
- הרכבת ההחלפה. מסך ציטוט עם ספירה לאחור, חתימה רק במכשיר, הסכום הסופי גלוי למשתמש לפני אישור ולא אחריו.
- בדיקת ההחלפה. מריצים תרחישי כשל: ציטוטים לא זמינים, מחיר שהשתנה, חתימה שנדחתה, ניתוק רשת בזמן שליחה — עם התנהגות צפויה של הארנק והודעה מובנת.
- קבלה. משווים עסקאות שבוצעו מול מחושבות: חיוב, זיכוי, עמלת רשת. אי-התאמה היא סיבה לחזור לסכימת המסלולים, ולא להוציא את הגרסה.
- מסירה לתפעול. מוסרים תצורות של מגבלות ומסלולים, סכימת ניטור, הנחיות לתמיכה ונוהל לעדכון מקורות ציטוטים בלי מהדורה חדשה של האפליקציה.
לאחר המסירה אנחנו בוחנים את שיעור ההחלפות המוצלחות, את הזמן מהלחיצה עד לאישור ברשת ואת הסירובים בכל מסלול — צוואר הבקבוק נראה לפני שהמשתמשים מבחינים בו.
מה נשאר בפרויקט: סכימות, מגבלות, נהלים
הפרויקט נסגר לא בהדגמה, אלא במערך תוצרים שלפיהם הצוות שלכם מנהל בעצמו החלפת טוקנים בארנק. כל מה שהוגדר בסביבות בדיקה וסביבות עבודה מועבר במסמכים ובתצורות עם ניהול גרסאות — אפשר לעקוב אחר שינוי ולבטל אותו.
- סכימת אינטגרציה — המסלול מממשק ההחלפה עד לעסקה חתומה: ליבת הארנק, מקור הציטוטים, צמתי הרשת, נקודות כשל והתנהגות האפליקציה בכל אחת מהן.
- הגדרות ניתוב ומדיניות מגבלות — סדר בחירת מסלול ההחלפה, החלקה מותרת, סכום מינימלי ומקסימלי, מגבלה יומית לארנק וסף פער מחירים שבו ההחלפה נעצרת.
- מדיניות גישה — תפקידים לעדכון רשימת הטוקנים, לעריכת מגבלות ולהוצאת גרסאות, הפרדה בין סביבות, סבב מפתחות חתימה.
- נוהל עדכון רשימת הטוקנים — מקור הרשימה, בדיקת החוזה והמטא-נתונים, מי מאשר הוספה ובכמה זמן טוקן מוסתר בעת אירוע.
- הנחיות לתמיכה — טיפול בפניות אופייניות: ההחלפה נתקעה בהמתנה, הציטוט פג, העסקה לא אושרה, היתרה לא התעדכנה; מה לבדוק ומתי להסלים.
- יומן פעולות — בקשות החלפה, מסלולים שנבחרו, סירובים ושגיאות עם מזהה סשן: אירוע מנותח לפי נתונים, בלי שיחות איתנו.
לפני המסירה אנחנו עוברים על הרשימה הזאת יחד עם הצוות שלכם ומתעדים בעלים לכל סעיף — התמיכה אינה תלויה במי שהוביל את הפיתוח.
מקרה בוחן: עלייה בשיעור ההחלפות שהושלמו בארנק
ההחלפה המובנית בארנק קמעונאי נראתה עובדת כל עוד הסתכלו על המסכים ולא על המשפך. לפי הלוגים, שיעור ההחלפות הנטושות עמד על כמחצית: אדם בחר זוג, ראה מחיר וסגר את המסך בלי להגיע לחתימה.
הסיבות התבררו כטכניות — הציטוט התיישן בזמן המעבר לאישור, ומקור הנזילות היחיד בעת ירידה החזיר שגיאה, והתרחיש קרס כולו.
מה שינו
את הצגת המחיר פיצלו לשני שלבים: שער משוער מוצג מיד בבחירת הזוג, וציטוט מדויק מתבקש לפני החתימה, עם ספירה לאחור והארכה אוטומטית. את הניתוב העבירו לכמה מקורות נזילות עם מעבר אוטומטי: אם ספק לא ענה בזמן שהוקצב או החזיר שגיאה, הבקשה עוברת לבא בתור. 1inch נשמר כאחד המנתבים, ולא כנקודת כשל יחידה.
בנפרד כתבנו מחדש את הטיפול בכשלים: במקום שגיאה כללית רואים באיזה שלב ההחלפה נפסקה, אפשר לחזור על הפעולה באותו מסלול, והיסטוריית הניסיונות נשמרת בארנק. הדבר הסיר פניות עיוורות לתמיכה.
מה יצא
שיעור הפעולות שהושלמו עלה, וההחלפות הנטושות הצטמצמו בערך פי שלושה. הזמן מהאישור של הכוונה ועד החתימה ירד מ-40-50 ל-10-15 שניות — כמעט את כל הפער יצרה ההמתנה לציטוט. סירוב של ספק בודד כבר לא מפיל את התרחיש כולו, ופניות לתמיכה בנושא החלפה ירדו בחצי.
במה שונה החלפה בתוך האפליקציה משירות חיצוני?
החלפה מובנית היא עסקה שהמשתמש חותם עליה באותו מקום שבו הוא מאחסן את המפתחות. האפליקציה לא מוסרת שליטה החוצה: את הציטוט מחזיר אגרגטור נזילות (למשל 1inch) או בריכה ישירות, המסלול נבנה בצד הלקוח, והחתימה נשלחת לרשת מאותו תהליך. מחליף חיצוני פועל אחרת — המשתמש מחבר את הארנק לדומיין זר, מאבד את הקשר הסשן וחוזר לאפליקציה ידנית.
ההבדל נראה במשפך. כל יציאה מהאפליקציה היא נקודת אובדן: חלק מהמשתמשים לא חוזרים, חלק חותמים על מסלול לא נכון, וחלק נוטשים באמצע. ההמרה להחלפה יורדת לא בגלל השער, אלא בגלל מספר הצעדים. כשההחלפה מובנית, המסלול מצטמצם לזוג, סכום ואישור, ומצב העסקה מתעדכן בזמן אמת.
מבחינה הנדסית זה תת-מערכת, לא כפתור: ניתוב בין מקורות נזילות, חישוב כמות מינימלית מקובלת ביציאה, בדיקה שהציטוט לא פג לפני החתימה, וטיפול בעסקה שנדחתה או נתקעה. האחריות לעסקה שלא צלחה נשארת עלינו, ולא מתפזרת בין שני מוצרים.
עבור הצוות משתנה גם התפעול: מופיעים מדדים לשיעור העסקאות המוצלחות, לזמן עד לאישור ולסיבות סירוב — חוסר באמצעים לעמלה, מסלול מיושן, כשל בצומת. כל זה נסגר בתוך האפליקציה, ונתוני התנהגות המשתמש נשארים בפנים, בלי אזור עיוור לאחר המעבר.
שאלות נפוצות: נזילות, מגבלות, כשלי רשת
ההחלפה בארנק היא פעולה שבה נפגשים שלושה מעגלים בלתי תלויים: מכשיר המשתמש, מנתב הנזילות והרשת. כשל באחד מהם הלקוח רואה כ״ההחלפה נתקעה״, אף שלכל אחד יש סיבה ומחיר טעות משלו. להלן תשובות להתלבטויות שצפות לרוב בשלב הערכת האינטגרציה.
כל סעיף עוסק במכניקה, לא בכוונה: היכן בדיוק נתפס הסירוב ומה המשתמש רואה באותו רגע.
מה קורה אם הרשת אינה זמינה ברגע ההחלפה?
ההחלפה לא מתחילה: לפני החתימה האפליקציה בודקת את מצב הצומת ואת אומדן העמלה, ובמקרה של ניתוק מציגה מצב ״המתנה לרשת״ עם אפשרות לבטל. בקשה חוזרת קשורה למזהה הציטוט — עסקה שנייה לא תיווצר.
של מי מקור הנזילות שבו משתמשים?
אנחנו לא מחזיקים נזילות משלנו. המנתב אוסף הצעות מכמה מקורות חיצוניים, משווה את הסכום הסופי בהתחשב בעמלת הרשת ובהחלקה ובוחר את המסלול הטוב ביותר; בעת שגיאה במקור, המסלול נבנה מחדש.
כיצד מוגנים המפתחות של המשתמש?
המפתח נוצר ונשאר באזור המאובטח של המכשיר, החוצה יוצאת רק החתימה. לא הקוד שלנו ולא החלק השרתי רואים את המפתח או יכולים לבקש אותו; אישור הפעולה מוגן בביומטריה.
איך מוסיפים טוקנים חדשים?
טוקן נכנס לקטלוג לאחר בדיקת החוזה: כתובת, דיוק, קיום זוג מסחר, התנהגות בהעברה ומגבלות על מכירה. הקטלוג מתעדכן בשרת, ולכן הרשימה משתנה בלי להוציא גרסה חדשה של האפליקציה.
היכן מתבצעת בדיקת הלקוח?
הבדיקה נמצאת מחוץ להחלפה ומופעלת לפני פעולות עם חשבון בנק: האפליקציה מקבלת רק את ההחלטה, ומסמכים אינם נשמרים בארנק. בפרופיל שכבר נבדק, ההחלפה אינה דורשת מעבר חוזר.
נדון במשימה: ממה נתחיל ומה יידרש
כדי שנחזור עם הערכת זמנים ותוכנית עבודה, ולא עם שאלות הבהרה כעבור שבוע, דרוש מערך מינימלי של נתוני קלט. החלפה מובנית אינה מסך נפרד, אלא צירוף של חישוב מסלול, חתימת עסקה וטיפול בסירובים, ולכן חשובים גם התרחישים וגם האופן שבו הארנק בנוי כעת.
מה עוזר להתחיל מיד:
- תיאור התרחישים: אילו זוגות טוקנים דרושים, מאין מגיע השער, מה מציגים למשתמש בתנועת מחיר חדה וכיצד מסבירים את מגבלת ההחלקה.
- הרשאות גישה למאגר הקוד ולמהדורה: כיצד בנויים אחסון המפתחות, שכבת החתימה ומעקב היתרות, אילו רשתות כבר נתמכות, והיכן עובר הגבול בין קוד נייטיב למודולים משותפים.
- סכימת ניתוב: האם אנחנו מחשבים את המסלול בעצמנו או נשענים על מקורות נזילות חיצוניים, מי ובאיזה שלב קובע את הסכום המינימלי שיתקבל.
- רשימת הרשתות והטוקנים, כולל גרסאות עטופות וטוקנים עם התנהגות לא תקנית בהעברה.
- חומרי אבטחה: האם נדרש אישור פעולה בביומטריה, האם קיימת הגנת חומרה למפתחות, ואילו בדיקות של כתובות נמען הן חובה.
- מדדים נוכחיים של הארנק: שיעור הפעולות המוצלחות, זמן חציוני עד לאישור, התפלגות סיבות הסירוב.
- מגבלות לפי כללי חנויות האפליקציות ולפי תחומי השיפוט שבהם המוצר פועל.
תארו את המשימה בצורה חופשית — נחזור עם הערכת זמנים, חלוקה לשלבים ורשימת סיכונים שכדאי לסגור לפני תחילת הפיתוח.