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

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

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

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

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

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

Worker או תור משימות יכול לנסות שוב סנכרון שנכשל בלי לחייב את המשתמש לשלם פעם נוספת.

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

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

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

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