ממשק API סליקה: איך בוחרים ספק סליקה ישראלי

למה העמלה היא לא השאלה הראשונה

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

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

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

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

שלוש דרכים לקלוט כרטיס, ומה כל אחת עושה ל-PCI

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

סוג חיבור	איך זה עובד	היקף PCI לסוחר	מתי לבחור
דף תשלום מתארח (Redirect)	הלקוח עובר לעמוד של הספק, משלם וחוזר	מצומצם. יכול להתאים ל-SAQ A	MVP, תרומות, חנות פשוטה, כשמהירות עלייה לאוויר חשובה
iframe או שדות מתארחים	טופס של הספק מוטמע בתוך העמוד שלכם	מצומצם, בתנאי שכל רכיבי הטופס מגיעים מהספק. יכול להתאים ל-SAQ A עם דרישות להגנה מפני סקריפטים	רוב מוצרי ה-SaaS והאפליקציות, כשחשוב שהלקוח לא יעזוב את המסך
API ישיר (שרת לשרת)	פרטי הכרטיס עוברים דרך הקוד או השרת שלכם	רחב בהרבה (SAQ A-EP ומעלה)	כמעט אף פעם במוצר חדש. רק כשיש צורך עסקי אמיתי וצוות שיודע לתחזק את זה

ה-PCI Security Standards Council מסביר שההבחנה היא מאיפה מגיעים רכיבי עמוד התשלום: ב-SAQ A כולם מגיעים מספק מאושר בלבד, וב-SAQ A-EP חלקם יכולים להגיע מהאתר של הסוחר. בשורה התחתונה: אם מספר כרטיס עובר אי פעם בשרת שלכם, אתם במשחק אחר. לא חשוב שאתם "מוחקים אותו מיד".

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

הצ'קליסט: מה לבדוק בכל ספק

1. טוקן אשראי

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

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

2. הוראת קבע ומנויים

יש שתי גישות, ולכל אחת השלכה על הקוד שלכם:

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

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

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

3. Webhooks ו-IPN

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

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

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

4. זיכויים וביטולים

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

5. 3D Secure

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

6. ביט, Apple Pay ו-Google Pay

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

אותו דבר לגבי Apple Pay ו-Google Pay: בדקו אם הם זמינים בדף התשלום או ב-iframe של הספק, ולא רק בתוסף לחנות.

7. סביבת בדיקות ותיעוד

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

8. חשבונית אוטומטית עם מספר הקצאה

ספקים רבים מפיקים חשבונית מס קבלה אוטומטית בסיום עסקה מוצלחת, ישירות או דרך חיבור לספק חשבוניות. אם אתם מוכרים לעסקים, החשבונית מעל 5,000 ש"ח לפני מע"מ צריכה מספר הקצאה מרשות המסים, אחרת הלקוח לא יכול לנכות מס תשומות. שאלו במפורש איך הספק מטפל בהקצאה, ומה קורה כשרשות המסים מעכבת חשבונית. פירטנו את הצד הזה במדריך ל-API חשבוניות ישראל.

טבלת השוואה: מה לשאול כל ספק

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

קריטריון	מה לבקש לראות	דגל אדום
סוגי חיבור	דף תשלום, iframe, API, ו-SDK למובייל אם יש	רק API ישיר, או iframe שדורש סקריפטים שלכם על הטופס
טוקנים	יצירת טוקן בלי חיוב, חיוב טוקן ב-API, מדיניות העברה	"אי אפשר להוציא טוקנים"
הוראת קבע	ניהול אצל הספק, ניסיונות חוזרים, התראות	אין webhook על חיוב חוזר
Webhooks	חתימה, ניסיונות חוזרים, API לשאילתת סטטוס	אין דרך לאמת שההודעה מהספק
זיכויים	מלא וחלקי ב-API, כולל עסקאות בתשלומים	זיכוי רק דרך ממשק הניהול
3DS	הפעלה לפי כללים, התנהגות במובייל	אין תמיכה או אין שליטה
ביט ו-Wallets	זמינות בזרימה שלכם, לא רק בתוסף	זמין רק בקישור תשלום ידני
Sandbox	גישה מיידית, כרטיסי בדיקה, webhooks בבדיקות	"נפתח לכם סביבה אחרי החתימה"
חשבוניות	הפקה אוטומטית, מספר הקצאה, מסמך זיכוי	חשבונית ידנית או קובץ לייצוא
מחיר	הצעה כתובה לפי פרופיל העסקאות שלכם	מחיר בעל פה בלבד

מתי לא להתחבר בעצמכם

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

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

שורה תחתונה

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

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

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

מקורות

המאמר נערך על ידי אביתר אדלר, CTO ב-FlowDev.

שאלות נפוצות

מה ההבדל בין דף תשלום, iframe ו-API ישיר?

בדף תשלום מתארח הלקוח עובר לעמוד של ספק הסליקה ומקליד שם את הכרטיס. ב-iframe העמוד של הספק מוטמע בתוך האתר או האפליקציה שלכם. ב-API ישיר פרטי הכרטיס עוברים דרך הקוד או השרת שלכם. לפי ה-PCI Security Standards Council, כשכל רכיבי עמוד התשלום מגיעים מספק מאושר, הסוחר יכול להיות זכאי לשאלון SAQ A המצומצם. API ישיר מכניס אתכם להיקף רחב בהרבה.

מה זה טוקן אשראי ולמה הוא חשוב?

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

איך מחברים ביט לאפליקציה?

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

מה עדיף למנויים: הוראת קבע באשראי או מס"ב?

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

למה ספקי סליקה לא מפרסמים מחיר אחיד?

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

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