top of page

בניה מחדש של שירות הסליקה - חלק 1

Updated: 1 day ago

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

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


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


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

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


כמו שניתן לראות באתר KSP נעשה שימוש בשירותי HYP ולפעמים PELECARD שעד לא מזמן הייתה השירות סליקת כרטיס אשראי הראשית.


בנוסף ישראקארד (החברה היחידה בארץ שמאפשרת שימוש באמריקן אקספרס) מספקת את שירות מימון הנקודות.


וישנם את התו הדיגיטלי שמנוהל על ידי שירותי KSP וההלוואת שנקראות שם ״אשראי ללא תפיסת מסגרת״ (שם גרוע 🙃) שמסופקת דרך שירותי חברת blender.


לא פיתחתי את השימוש ב blender, giogle pay ושימוש בשירותי HYP בעקבות המעבר לפרוייקט אחר (החיפוש באתר) אך עזרתי בתהליך ההבנה והלוגיקה מאחורי הקלעים.


חשיבה עתידית

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

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


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


תהליך תשלום בכרטיס אשראי

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

בעקבות כך נולדו חברות ה-״gateway", בעולם הסליקה החברות האלו מגשרות בין החברות שרוצות לסלוק לבין חברת שבא שהיא החברה הראשית לסליקת אשראי והיא פונה למנפיקות השונות (max, isracard וכולי) על מנת לבצע את התשלום בפועל.

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

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

ב-KSP בשימוש הוא בעיקר כיום בחברת HYP ובעבר הוא היה עם חברת PELECARD.

בעולם כרטיסי האשראי ישנם שתי סוגים עיקריים שנעשה בהם שימוש (לא אפשרת על השאר), הראשון נקרה J4 והשני נקרה J5.

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

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

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

באופן די כבוע חברות ה-gateway משדרות את העסקאות בשעה שסופרה להם באמצעות בין העסק.

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


מי ששילם ב-KSP בטח שם לב שהוא מקבל הודעה שהוא ״חוייב״ או שנתפסה לו מסגרת על סך של 2 שקלים.

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

לגבי עולם התשלום ישנם כאלו שמגלגלות את החיוב על ערוץ התשלום (טרמינל) של הסניף ויש כאלו שמנהלים את זה ברמת הנהלת חשבונות.

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

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


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

בתהליך הזה פרטי האשראי שמועברים נגישים רק לשירותי חברת ה-gateway ולא לשירותי בין העסק.


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


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

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

ולמרות כל זה עדיין לקוח יכול להכחיש את העסקה גם כאשר יש CVV.

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

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

תכירו מנגנון אימות שנקרה 3DS.

התפקיד שלו הוא לאמת את בעל הכרטיס ובכך להעביר את האחריות לחברת האשראי.

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

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

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

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


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

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


בפרק הבא

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

43 views0 comments
bottom of page