השוואת סולקים ישראליים: מנקודת מבט של מי שמחבר אותם

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

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

מודל האינטגרציה

ההבדל שהכי משנה: איך נמנע שינוי סכום

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

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

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

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

סביבת בדיקות - חוסך הזמן הגדול ביותר

ל-PayPlus יש סביבת Staging מתועדת, וכל פונקציה בתיעוד מציגה גם כתובת Staging וגם Production. זה יתרון ממשי.

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

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

מתי כל אחד מתאים

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

חמישה דברים שזהים בכולם

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

1. Webhook ולא הפניה

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

2. אידמפוטנטיות

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

3. הצלבת סכום

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

4. מי מפיק את החשבונית

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

5. לא לגעת בפרטי כרטיס

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

איך לבחור בפועל

1. עם מי העסק כבר עובד? אם יש תשובה, זו התשובה.
2. מה מודל הגבייה? checkout, קישור, או מוטמע - זה מכוון למודל הנכון.
3. האם יש סביבת בדיקות? לשאול בכתב.
4. איך ננעל הסכום? ואם התשובה דורשת מודול בתשלום - לברר את זה לפני התמחור.
5. עמלות. אחרונות ברשימה הזו, ראשונות מבחינת העסק - אבל הן שיחה עם הסולק, לא שיקול טכני.

מדריכים מפורטים: קארדקום v11 · טרנזילה · PayPlus.