שלוש דרכים לחבר סליקה לאתר: הפניה לדף של הספק, iframe, או טופס משלכם. ההבדל בחוויה, בנטישה, ובהיקף דרישות ה-PCI שחלות עליכם.
עיקרי הדברים
- ככל שהטופס קרוב יותר אליכם, כך אתם אחראים ליותר - גם באבטחה וגם בתחזוקה.
- לפי חברות ביקורת PCI, הפניה מלאה או iframe של הספק מציבים אתכם בשאלון הקצר; טופס משלכם מעביר אתכם לשאלון הארוך בהרבה.
- ההבדל בנטישה בין השלוש קטן ממה שנדמה. מה שמשפיע יותר הוא אמצעי התשלום ושדות מיותרים.
- ספקים ישראליים מציעים את שלוש הדרכים; PayPlus, למשל, מציגה הטמעת WooCommerce ב-iFrame או ב-Redirect.
יש שלוש דרכים לגבות כסף באתר: להפנות את הלקוח לדף של ספק הסליקה, להטמיע iframe של הספק בתוך הדף שלכם, או לבנות טופס משלכם ששולח את הנתונים לספק. ההבדל ביניהן אינו עיצובי - הוא קובע כמה מדרישות אבטחת נתוני הכרטיסים חלות עליכם, ומי אחראי כשמשהו נשבר.
שלוש הדרכים, זו לצד זו
| הפניה לדף הספק | iframe בתוך הדף שלכם | טופס משלכם ל-API | |
|---|---|---|---|
| מה הלקוח רואה | עובר לכתובת של הספק | נשאר אצלכם, השדות של הספק | נשאר אצלכם, הכול שלכם |
| מי מגיש את שדות הכרטיס | הספק | הספק | אתם |
| מי מעצב את החוויה | הספק, בדרך כלל עם מיתוג | אתם סביב, הספק בפנים | אתם לגמרי |
| מה נשבר בעדכון | כמעט כלום | הטמעה, גובה, גלילה בנייד | הכול - הטופס הוא קוד שלכם |
| מי מתחזק | הספק | שניכם | אתם |
| היקף דרישות האבטחה עליכם | הקטן ביותר | קטן, אך לא זהה להפניה | הגדול ביותר |
| מתאים ל | רוב העסקים | מי שרוצה חוויה רציפה | מי שיש לו צוות פיתוח וסיבה טובה |
למה זה משנה את דרישות ה-PCI שחלות עליכם?
חברות הביקורת שמלוות עסקים בתקן PCI DSS מתארות את ההבחנה כך: כשהאתר מפנה את הלקוח לגמרי לספק מאושר, או משתמש ב-iframe שמסופק על ידו, זרימת נתוני הכרטיס נשלטת בידי הספק - וזה מציב את העסק בשאלון ההערכה העצמית הקצר. לעומת זאת, כשטופס התשלום מיושם ומנוהל על ידי בית העסק - למשל בשיטת Direct Post - חל שאלון רחב בהרבה.
ההפרש שמצוטט בפרסומי אותן חברות הוא עשרות דרישות מול כמאתיים. זו הסיבה שההחלטה הזו אינה החלטה של מעצב:
- טופס משלכם אומר שכל סקריפט שרץ בדף שלכם הוא חלק מסביבת התשלום.
- זה כולל כלי אנליטיקה, צ'אט, פיקסלים ותוספים - כל אחד מהם הוא רכיב שצריך לנהל.
- וזה גם אומר שעדכון של תוסף שלא קשור לתשלום נוגע בכל זאת לזרימת התשלום.
ההגדרות המחייבות נמצאות אצל מועצת התקן, וההחלטה על מה חל עליכם בפועל נעשית מול הסולק וגורם הביקורת שלכם - לא מתוך כתבה. מה שכן אפשר לקחת מכאן: אם אין לכם סיבה חזקה, ההפניה או ה-iframe הם ברירת המחדל הנכונה.
מה באמת משפיע על נטישה?
ההנחה שלקוחות נוטשים בגלל מעבר לדומיין אחר נכונה הרבה פחות ממה שחושבים, במיוחד כשהדף של הספק ממותג. מה שכן מפיל עסקאות:
- אין את אמצעי התשלום שהלקוח רוצה. ביט או ארנק דיגיטלי חסרים הם נטישה מיידית.
- אין תשלומים. קהל ישראלי מחפש פריסה; דף בלי אפשרות כזו מאבד עסקאות גדולות.
- שדות מיותרים. כל שדה שאינו נדרש לחיוב הוא סיבה לעזוב.
- דף איטי בנייד או iframe שגובהו לא מתאים ומחייב גלילה בתוך גלילה.
- שגיאה בעברית שלא אומרת כלום. "העסקה נכשלה" בלי המשך פעולה.
לכן סדר הפעולות הנכון הוא קודם לבדוק אמצעי תשלום ותשלומים, ורק אחר כך לדבר על סוג ההטמעה. הפירוט המלא נמצא בלמה נוטשים את דף התשלום.
מה לבדוק לפני שבוחרים דרך
- האם ספק הסליקה מציע את שלוש הדרכים, או רק חלק מהן.
- האם ה-iframe מותאם לנייד, ומה קורה כשהמקלדת נפתחת.
- האם אפשר למתג את דף הספק, ובאיזו מידה.
- מה קורה כשהעסקה נכשלת - לאן הלקוח חוזר ומה כתוב לו.
- מי מתחזק את ההטמעה אחרי שהיא עולה, ומה קורה בעדכון גרסה של החנות.
- איך נראה החזר כספי - מתוך המערכת או בפנייה לתמיכה.
השאלה החמישית היא זו שמכריעה בפועל בעסק בלי מפתח בבית. תוסף שנשבר בעדכון פלטפורמה הוא הסיבה הנפוצה ביותר שחנות מפסיקה לגבות, והיא מתגלה בדרך כלל מהלקוח ולא מהניטור.
מי אחראי על מה, אחרי שזה עלה
זו השאלה שלא נשאלת בהטמעה ומתבררת בתקלה הראשונה. כדאי לכתוב את החלוקה הזו פעם אחת, בכתב:
- הדף שמכיל את התשלום - שלכם, תמיד. גם כשהשדות של הספק.
- שדות הכרטיס והאחסון שלהם - הספק, בשתי השיטות הראשונות.
- הודעת ההצלחה והכישלון ללקוח - שלכם. הספק מחזיר תוצאה, אתם מנסחים מה כתוב.
- עדכון ההזמנה במערכת - שלכם, ותמיד לפי הודעת השרת ולא לפי חזרת הדפדפן.
- התוסף שמחבר בין החנות לספק - תלוי מי פיתח אותו. תוסף רשמי של הספק הוא באחריותו; תוסף צד שלישי הוא באחריותכם.
- דוח ההתאמה בסוף החודש - שלכם.
השורה האחרונה היא זו שנשכחת. גם כשהכול אצל הספק, ההתאמה בין מה שנגבה למה שנכנס לבנק היא עבודה שלכם, ואף שיטת הטמעה לא משנה את זה.
מה משתבש בכל אחת מהשיטות
- בהפניה: הלקוח חוזר לדף "תודה" לפני שההודעה מהספק הגיעה, וההזמנה נראית לא משולמת. פתרון: להסתמך על העדכון מהשרת ולא על חזרת הדפדפן.
- ב-iframe: גובה קבוע שמייצר גלילה כפולה בנייד, או חסימה של צד שלישי בדפדפן שמונעת טעינה.
- בטופס עצמי: סקריפט חיצוני שמשתנה בלי הודעה ונוגע בדף התשלום; וזו בדיוק הסיבה שהיקף הדרישות עליכם גדול.
- בכולן: אין דוח שמראה כמה עסקאות נפתחו מול כמה הושלמו, ולכן אף אחד לא יודע שיש בעיה.
מתי בכל זאת בונים טופס משלכם
יש מצבים שבהם זו ההחלטה הנכונה, והם מצומצמים:
- מנוי או חידוש בתוך מוצר שבו המשתמש כבר מחובר, ומעבר לדף חיצוני שובר את הזרימה.
- תהליך מרובה שלבים שבו התשלום הוא שלב אחד מתוך כמה ואי אפשר לצאת באמצע.
- חיוב ללא נוכחות הלקוח, למשל חידוש אוטומטי עם טוקן קיים - וזה ממילא לא טופס אלא קריאה לשרת.
- מרקטפלייס שבו צריך לפצל סכום בין כמה מוכרים.
בכל אחד מהמקרים האלה ההחלטה צריכה להתקבל עם מי שיתחזק את זה שנתיים קדימה, ולא בתחילת פרויקט. ובכל מקרה, גם כשבונים - שמירת הכרטיס עצמה נשארת אצל הספק בצורת טוקן, כמוסבר במה זה טוקן בסליקה.
מקורות
שאלות נפוצות
מה הכי מומלץ לעסק קטן?
הפניה לדף של הספק או iframe שהוא מספק. שתיהן מקטינות את מה שאתם צריכים לאבטח ולתחזק, והן גם הדרכים שהספקים הישראליים תומכים בהן ישירות בתוספים לחנויות. טופס עצמי מתאים כשיש צוות פיתוח וסיבה מוצרית ברורה.
iframe נחשב "אצלי" או "אצל הספק"?
מבחינת חוויית הלקוח - אצלכם. מבחינת זרימת נתוני הכרטיס, חברות הביקורת מתארות iframe שמסופק על ידי ספק מאושר כשליטה של הספק. יחד עם זאת, הדף שמכיל את ה-iframe הוא שלכם, ולכן מה שרץ בו עדיין חשוב. את ההחלטה המחייבת קבלו מול הסולק וגורם הביקורת.
אפשר לעצב את דף התשלום של הספק?
ברוב המקרים אפשר למתג אותו - לוגו, צבעים, לפעמים כתובת משנה בדומיין שלכם. PayPlus, למשל, מציגה דף סליקה לדומיין שלכם. בררו בדיוק מה ניתן לשינוי לפני ההטמעה, כי זה ההבדל בין דף שנראה שלכם לדף שנראה זר.
מה עדיף לחנות ווקומרס או שופיפיי?
מה שהתוסף הרשמי של הספק תומך בו. ספקים ישראליים מפרסמים תוספים לפלטפורמות הנפוצות, ו-PayPlus למשל מציגה הטמעת WooCommerce ב-iFrame או ב-Redirect. בחירה בדרך שהתוסף תומך בה חוסכת תחזוקה בכל עדכון.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.