פיתוח אפליקציית מובייל לארנק אלקטרוני

אפליקציית מובייל לארנק: היכן נשברת לוגיקת התשלומים

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

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

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

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

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

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

ארכיטקטורת ארנק: יומן פעולות, שריון, התאמה

יומן פעולות כמקור אמת יחיד

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

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

שריון כספים והתאמת עסקאות

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

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

מה בוחרים תחת עומס

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה שינינו

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

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

מדדים לפני ואחרי

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

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

תאימות, מיגרציה וחזרה לאחור: מה יש לדון לפני ההתחלה

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

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

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

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

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

לידי המזמין מתקבל:

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

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