• בלוג
  • השוואה בין הטמעת 4 ספקי סליקת אשראי לאתר שלכם

השוואה בין הטמעת 4 ספקי סליקת אשראי לאתר שלכם

18/03/2018

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

1. אמ;לק

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

  2. בפייפאל אומנם אין עם מי לדבר אבל התיעוד מדויק ויש דוגמאות קוד בהמון שפות.

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

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

2. רקע טכני

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

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

המנגנון הראשון הוא יצירת דף הסליקה: 1. אפשרות אחת היא לשלוח את הגולש ישירות מהאתר שלכם לדף הסליקה ובאמצעות פרמטרים של הבקשה לקבוע את סכום העיסקה ותיאורה (בדרך כלל תישלח בקשת POST מטופס שנמצא אצלכם באתר).

  1. אפשרות שניה היא להעביר את הפרמטרים (הסכום לתשלום ותיאור העיסקה) מהשרת שלכם ישירות אל ספק הסליקה, לקבל בחזרה URL ספציפי לעיסקה זו ולהפנות את הגולש ב Redirect לאותו URL.

המנגנון השני הוא קבלת הודעה על סיום עיסקה וגם כאן יש שתי אפשרויות: 1. אפשרות אחת נקראת IPN וזה אומר שספק הסליקה שולח לשרת שלכם הודעת HTTP POST ברגע שעיסקה מסתיימת בהצלחה. אתם מוודאים שההודעה אותנטית (אצל כל ספק זה קצת שונה) ואז יכולים לעבד את העיסקה אצלכם במערכת. זהו תהליך אסינכרוני ולכן צפויה המתנה קצרה בין התשלום בפועל לבין מועד עיבוד העיסקה אצלכם בשרת.

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

3. פייפאל

פייפאל תומך בכל המנגנונים שהוצגו אבל בשביל המנגנון השני (יצירת דפי סליקה ווידוא פרטי עיסקה דרך השרת) דורש API Keys. בשביל לא לסבך את הלקוחות שלי בחרתי באפשרות הראשונה וכך כשאתם בוחרים לחבר את Schooler עם פייפאל אני רק צריך את האימייל שלכם.

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

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

פייפאל מחזיקים שרת בדיקות (Sandbox) נפרד משרת הייצור. מאחר ואי אפשר לשלוח IPN למכונת פיתוח שיושבת על localhost בדיקת עסקאות בפייפאל מחייבת שתהיה לכם סביבת בדיקות באוויר שמחוברת לשרתי ה Sandbox שלהם.

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

4. קארדקום אישורית זהב

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

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

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

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

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

5. ריווחית iCredit

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

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

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

6. iCount

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

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

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

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