סליקה אוטומטית: Cardcom, Tranzila ו-iCount - איזה API מתאים לאיזה תהליך
שלושת השמות האלה מוזכרים באותה נשימה, והם לא באמת מתחרים באותה קטגוריה. שניים מהם הם ספקי סליקה ואחד הוא מערכת חשבוניות שיודעת גם לגבות. ההבחנה הזאת קובעת איזה תהליך תוכלו לבנות, ולכן כדאי להתחיל ממנה.
שלושה שמות, שתי קטגוריות
כשעסק אומר ״אנחנו מתלבטים בין Cardcom, Tranzila ו-iCount״, כדאי לעצור רגע. Cardcom ו-Tranzila הם ספקי סליקה - התפקיד שלהם הוא להעביר חיוב מכרטיס האשראי של הלקוח אליכם. iCount היא בראש ובראשונה מערכת לניהול חשבונות והפקת חשבוניות, שמציעה גם אפשרות לגבות תשלומים.
זה לא הבדל סמנטי. הוא קובע את מבנה התהליך שתבנו, מה תצטרכו לחבר למה, ואיפה יישבו הנתונים. לכן נתחיל ממנו ולא מטבלת השוואה.
| Cardcom | Tranzila | iCount | |
|---|---|---|---|
| קטגוריה | ספק סליקה | ספק סליקה | מערכת חשבוניות עם שכבת גבייה |
| עמוד סליקה מתארח | כן | כן | כן |
| חיוב חוזר בטוקן | כן | כן | כן, במסגרת המערכת |
| הפקת חשבונית | מודול נלווה | לא בליבה | זה הליבה |
| סגנון הממשק | מודרני יחסית, מתועד | משלב ותיק וחדש | מודרני |
| מתאים במיוחד ל | מסחר ומנויים עם שליטה מלאה | עסקים שכבר נמצאים שם | עסקי שירות שרוצים הכל במקום אחד |
שורה אחת חשובה חסרה בטבלה, כי אי אפשר למלא אותה: עמלות. הן נקבעות פרטנית מול כל עסק, והן הגורם המשמעותי ביותר בבחירה. ההפרש בין הצעות על פני שנה מגמד בדרך כלל את ההפרש בעלות הפיתוח. אנחנו נכנסים לתמונה אחרי שההחלטה המסחרית נסגרה, ולא לפניה.
ההחלטה הטכנית הראשונה: איפה מוקלד הכרטיס
לפני שבוחרים ספק, יש החלטה שמשפיעה יותר על העלות ועל הסיכון מכל בחירת ספק - האם פרטי כרטיס האשראי עוברים דרך המערכות שלכם.
עמוד סליקה מתארח
הלקוח מועבר לעמוד של ספק הסליקה, או שהעמוד מוטמע אצלכם בחלון מבודד. פרטי הכרטיס מוקלדים שם ולא נוגעים בשרת שלכם אף פעם. אחרי החיוב הלקוח חוזר אליכם, ובמקביל ספק הסליקה שולח לשרת שלכם הודעה עם התוצאה.
כל שלושת הספקים תומכים במודל הזה, וזו ההמלצה שלנו לרוב המכריע של העסקים. הוא מוציא אתכם מתחולת הדרישות המחמירות לאבטחת נתוני כרטיסים, הוא מפחית משמעותית את הסיכון, והוא מקצר את הפיתוח.
חיוב ישיר מהשרת
המערכת שלכם מקבלת את פרטי הכרטיס ושולחת אותם לספק. זה נותן שליטה מלאה בחוויית התשלום, וזה גם מכניס אתכם לעולם של דרישות אבטחה, ביקורות ואחריות משפטית. זה מוצדק לעסקים גדולים עם צוות ייעודי, וכמעט אף פעם לא לעסק בינוני.
כלל שאנחנו לא חורגים ממנו: מספר כרטיס אשראי לא נשמר אצל הלקוח שלנו, לא בבסיס נתונים, לא ביומן ולא בגיליון. עובדים עם טוקנים בלבד.
טוקנים וחיוב חוזר
אם המודל העסקי שלכם כולל חיוב חודשי - מנוי, ריטיינר, תשלומים - זה החלק הכי חשוב במאמר. הרעיון פשוט: בפעם הראשונה הלקוח מזין את פרטיו בעמוד מאובטח. בתמורה אתם מקבלים מזהה מוצפן שמייצג את הכרטיס אצל ספק הסליקה. בכל חיוב הבא, שולחים את המזהה הזה.
המזהה חסר ערך למי שיגנוב אותו: הוא עובד רק מול המסוף שלכם ואצל אותו ספק. וכאן נקודה שהרבה עסקים לא חושבים עליה - הוא גם קשור לספק. מעבר מספק סליקה אחד לאחר לא מעביר את הטוקנים, ולכן החלפת ספק אצל עסק עם מאות מנויים היא פרויקט בפני עצמו שדורש מהלקוחות להזין מחדש.
מה שתהליך חיוב חוזר חייב לכלול, מעבר לחיוב עצמו:
- טיפול בכרטיס שפג תוקפו או נדחה. זה קורה לאחוז מסוים מהלקוחות בכל חודש, וזה לא תקלה אלא שגרה.
- מדיניות ניסיונות חוזרים - כמה פעמים, בהפרש כמה ימים, ומתי מפסיקים ופונים ללקוח.
- הודעה ללקוח לפני החיוב ולא רק אחריו. זה מפחית ביטולים ומחלוקות.
- הפקת חשבונית אוטומטית על כל חיוב שהצליח, ורק על כאלה.
- התראה פנימית כשמצטברים כשלים חריגים, כי זה לרוב סימן לתקלה בהגדרות ולא לבעיה אצל הלקוחות.
- מסלול ברור לביטול מנוי, כולל עצירת החיובים העתידיים באותו רגע.
המלכודת הנפוצה ביותר: לסמוך על החזרה בדפדפן
אחרי תשלום מוצלח קורים שני דברים במקביל. הלקוח מוחזר לעמוד תודה, וספק הסליקה שולח לשרת שלכם הודעה נפרדת עם תוצאת העסקה. הרבה מאוד מימושים מסתמכים על הראשון, וזו טעות שמייצרת פערים אמיתיים בכסף.
הסיבה פשוטה: הלקוח יכול לשלם ואז לסגור את החלון, להתנתק מהרשת, או שהדפדפן שלו ייתקע. החיוב עבר, ההחזרה לא הגיעה, ומבחינת המערכת שלכם לא קרה כלום. אין חשבונית, אין הזמנה, ויש לקוח מחויב שלא קיבל שירות.
המבנה הנכון: ההודעה שמגיעה ישירות מהספק אל השרת היא מקור האמת, וכל תהליך עסקי נתלה בה. ההחזרה בדפדפן משמשת רק לחוויית משתמש - הצגת ״תודה, התשלום התקבל״. בנוסף, מאמתים מול הספק שהעסקה אכן קיימת ובסכום הצפוי, במקום להאמין להודעה כמות שהיא.
ועוד שני פרטים שנובעים מאותו עיקרון: ההודעה יכולה להגיע פעמיים, ולכן צריך לזהות עסקה שכבר טופלה. והיא יכולה לא להגיע כלל, ולכן שווה בדיקה מחזורית יומית שמשווה בין העסקאות אצל הספק לבין מה שנרשם אצלכם.
מונחים שתפגשו
| מונח | מה זה אומר בפועל |
|---|---|
| מסוף | ההגדרה שדרכה נסלקות העסקאות שלכם אצל הספק. לעסק יכולים להיות כמה |
| טוקן | מזהה מוצפן שמחליף את מספר הכרטיס בחיובים עתידיים |
| הרשאה מול חיוב | שריון סכום מבלי לגבות, לעומת גבייה בפועל. שימושי כשהאספקה אינה מיידית |
| בדיקת תקינות כרטיס | אימות שהכרטיס פעיל בלי לחייב, למשל לפני פתיחת מנוי |
| אימות מחזיק הכרטיס | שכבת אימות נוספת מול חברת האשראי שמפחיתה הכחשות עסקה |
| הודעת שרת לשרת | ההודעה שהספק שולח למערכת שלכם. מקור האמת לתשלום |
מתי כל אחד מתאים
Cardcom
בחירה טובה כשהתשלום הוא חלק ממערכת רחבה יותר שאתם בונים - חנות, מנויים, מערכת הזמנות - ואתם רוצים שליטה בזרימה. הממשק מודרני יחסית והתיעוד סביר, ויש גם מודול להפקת מסמכים שחוסך אינטגרציה נוספת לעסקים פשוטים. שווה לבדוק אם הוא מספיק לכם לפני שמחברים מערכת חשבוניות נפרדת.
Tranzila
ותיקה ומבוססת, ונמצאת בשימוש אצל מספר גדול של עסקים ישראליים. חלק מהממשקים שלה שמרו על סגנון ותיק לצד ממשקים חדשים יותר, ולכן שווה לוודא מול הספק באיזה מסלול אתם ומה זמין בו לפני שמתכננים. אם אתם כבר עובדים איתה ומרוצים מהתנאים, אין סיבה טובה להחליף רק בגלל הצד הטכני.
iCount
מתאימה במיוחד לעסקי שירות ולפרילנסרים שרוצים שהחשבונית והתשלום יהיו באותו מקום. היתרון האמיתי הוא שאין אינטגרציה לתחזק בין הגבייה להפקת המסמך - הכל קורה במערכת אחת. החיסרון הוא פחות שליטה מדויקת בזרימת התשלום, ותלות במערכת אחת גם לחשבונות וגם לגבייה.
מה שכדאי לסגור לפני שמתחילים
- 1האם התנאים המסחריים נסגרו. אל תתכננו אינטגרציה לפני שהעמלות סגורות.
- 2האם יש סביבת בדיקות עם כרטיסים מדומים, ואיך מקבלים אליה גישה.
- 3מי מקבל את ההודעה על תשלום, ומה בדיוק קורה כתוצאה ממנה.
- 4האם צריך חיוב חוזר. אם כן, זה משנה את התכנון מהיום הראשון ולא בהמשך.
- 5מי מפיק את החשבונית - ספק הסליקה, מערכת חשבוניות נפרדת, או מערכת ההנהלת חשבונות.
- 6מה קורה בהחזר, בביטול ובהכחשת עסקה, ומי מטפל בכל אחד מהם.
השורה התחתונה
בחירת ספק סליקה היא בעיקר החלטה מסחרית, ורק אחר כך טכנית. כל שלושת השמות שדיברנו עליהם מאפשרים לבנות תהליך גבייה אוטומטי תקין, וההבדלים ביניהם משמעותיים פחות מההבדל בין מימוש נכון למימוש רשלני.
המימוש הנכון מסתכם בשלושה עקרונות: פרטי הכרטיס לא עוברים דרככם, מקור האמת הוא ההודעה שמגיעה מהספק לשרת ולא מה שקרה בדפדפן, וכל עסקה נבדקת מול הספק לפני שמפיקים עליה מסמך. עסק שמקפיד על שלושת אלה יוכל להחליף ספק בעתיד בלי לשכתב את התהליך.
שאלות שחוזרות
- איזה ספק סליקה הכי טוב לאוטומציה?
- אין תשובה אחת, ובפועל הבחירה כמעט אף פעם לא נקבעת לפי הממשק אלא לפי עמלות הסליקה ולפי מה שהבנק או המסלקה הציעו לכם. ההפרש בעמלות על פני שנה גדול בדרך כלל מהפרש עלות הפיתוח בין הספקים. בדקו קודם את התנאים המסחריים, ואחר כך את הצד הטכני.
- מה ההבדל בין עמוד סליקה לחיוב ישיר מהשרת?
- בעמוד סליקה, פרטי הכרטיס מוקלדים בעמוד של ספק הסליקה ולא נוגעים במערכות שלכם. בחיוב ישיר, המערכת שלכם מקבלת את פרטי הכרטיס ושולחת אותם הלאה - וזה מכניס אתכם לתחולת דרישות אבטחה מחמירות. לרוב המכריע של העסקים, עמוד סליקה הוא הבחירה הנכונה והזולה.
- איך עושים חיוב חודשי קבוע בכרטיס אשראי?
- בפעם הראשונה הלקוח מזין את פרטיו בעמוד מאובטח, ואתם מקבלים בחזרה מזהה מוצפן שמייצג את הכרטיס - מה שנקרא טוקן. בכל חיוב עתידי שולחים את המזהה הזה במקום את פרטי הכרטיס. הטוקן חסר ערך למי שיגנוב אותו כי הוא עובד רק מול המסוף שלכם.
- האם אפשר לסמוך על ההודעה שהתשלום עבר?
- לא על החזרה של הדפדפן. מה שקורה במסך של הלקוח לא מהווה הוכחה - הוא יכול לסגור את החלון או להתנתק אחרי החיוב. ההוכחה היחידה היא ההודעה שספק הסליקה שולח לשרת שלכם ישירות, ואימות מולו. תהליך שמפיק חשבונית על סמך החזרה בדפדפן בלבד יחטיא תשלומים ולפעמים יפיק מסמכים על עסקאות שלא נסגרו.
- iCount זה ספק סליקה או מערכת חשבוניות?
- בעיקרו מערכת לניהול חשבונות וחשבוניות, שמציעה גם שכבת גבייה. זה יתרון אמיתי כשרוצים שהתשלום והחשבונית יהיו באותו מקום ובלי אינטגרציה ביניהם. זה פחות מתאים כשצריכים שליטה מדויקת בזרימת התשלום או תנאי סליקה שנסגרו מול גורם אחר.
- מה קורה כשלקוח מבקש ביטול והחזר?
- צריך להחליט מראש אם ההחזר נעשה ידנית בממשק של ספק הסליקה או אוטומטית מתוך התהליך. אנחנו ממליצים ברוב המקרים להשאיר את זה ידני בשלב הראשון, כי זה אירוע נדיר יחסית ובעל השלכות. מה שכן חייב להיות אוטומטי הוא רישום ההחזר וההשלכה שלו על החשבונית, כדי שהספרים יישארו נכונים.