RapidStoreסליקה היא הרגע שבו חנות אינטרנטית עוברת מאתר שמציג מוצרים למערכת שמסוגלת לקבל כסף ולהפיק הזמנות אמיתיות. בגלל זה, בחירת ספק התשלום והחיבור שלו לחנות אינם עוד הגדרה טכנית קטנה. הם משפיעים ישירות על שיעור השלמת הרכישה, על התפעול של העסק ועל היכולת להבין אם הזמנה אכן שולמה.
הרבה עסקים מסתכלים קודם על עמלת הסליקה, אבל זו רק חלק מהתמונה. צריך לבדוק גם אילו אמצעי תשלום נתמכים, איך מתבצעים ביטולים והחזרים, מה קורה כשעסקה נכשלת, מתי הכסף מועבר לעסק, איך נראית הקופה במובייל ואיך מערכת החנות מקבלת בחזרה את תוצאת התשלום.
חיבור סליקה טוב צריך להיות כמעט בלתי מורגש ללקוח. הוא בוחר מוצרים, עובר לקופה, משלם ומקבל אישור ברור. מאחורי הקלעים, לעומת זאת, צריכים לעבוד כמה תהליכים מדויקים כדי שהעסק לא יקבל הזמנה כפולה, לא יסמן עסקה כמשולמת בטעות ולא יאבד הזמנה שכבר שולמה.
מערכת החנות וספק הסליקה הם שני חלקים שונים
חשוב להבין את ההפרדה בין פלטפורמת המסחר לבין ספק התשלום. מערכת החנות מנהלת מוצרים, עגלה, משלוחים, לקוח והזמנה. ספק הסליקה מטפל בפעולה הכספית עצמה ומחזיר תוצאה לגבי העסקה.
החיבור ביניהם צריך לוודא שהזמנה שנוצרה בחנות מקבלת את סטטוס התשלום הנכון. אם העסקה הצליחה, ההזמנה צריכה להתעדכן בהתאם. אם היא נדחתה, בוטלה או לא הושלמה, אסור שהמערכת תציג אותה כאילו שולמה.
לא בוחרים ספק רק לפי אחוז העמלה
עמלת עסקה היא נתון חשוב, אבל לעיתים ספק עם עמלה מעט נמוכה יותר יכול להיות יקר או מסורבל יותר כאשר מוסיפים עלויות קבועות, דמי הקמה, תשלום חודשי או עלויות נוספות עבור שירותים מסוימים.
כדאי לחשב את העלות לפי העסק האמיתי ולא לפי דוגמה כללית. עסק עם מעט עסקאות בסכומים גבוהים עשוי לקבל תוצאה שונה מעסק עם מאות עסקאות קטנות בכל חודש.
- עמלה באחוזים מכל עסקה
- עמלה קבועה לעסקה אם קיימת
- דמי שימוש חודשיים
- דמי הקמה
- עלויות החזר או ביטול
- עלות אפשרית לתשלומים
- עלויות עבור אמצעי תשלום נוספים
- תנאי זיכוי והעברת הכספים לעסק
בודקים אילו אמצעי תשלום הלקוחות מצפים למצוא
הלקוחות לא בוחרים ספק סליקה לפי המותג שלו. הם רוצים להשתמש באמצעי תשלום שהם מכירים ונוח להם איתו. לכן הבחירה צריכה להתחיל מהקהל של העסק.
כרטיסי אשראי הם בדרך כלל בסיס, אבל בהתאם לשוק וללקוחות ייתכן שיהיה צורך גם בארנקים דיגיטליים או אמצעי תשלום נוספים. אין סיבה להוסיף עשר אפשרויות אם הלקוחות לא משתמשים בהן, אבל גם לא כדאי לאבד רכישות בגלל אמצעי תשלום מרכזי שחסר.
תשלומים הם החלטה עסקית ולא רק יכולת טכנית
אם העסק מאפשר פריסה לתשלומים, צריך להבין מי נושא בעלות, כיצד מתקבל הכסף ומה קורה במקרה של ביטול חלקי או מלא.
תשלומים יכולים להגדיל את הנגישות למוצרים יקרים יותר, אבל הם גם משפיעים על התזרים ועל עמלות הסליקה. כדאי להחליט על מספר תשלומים בהתאם לסכום העסקה ולא להפעיל את האפשרות באופן אוטומטי על כל מוצר.
זמן הזיכוי משפיע על תזרים המזומנים
לא תמיד הכסף מגיע לחשבון העסק מיד לאחר שהלקוח שילם. לספקים שונים יש מועדי זיכוי ותנאים שונים, והפער יכול להיות משמעותי לעסק שקונה מלאי, משלם לספקים או מממן משלוחים לפני קבלת הכסף.
לפני החיבור כדאי להבין מתי העסק צפוי לראות את הכספים, האם ניתן לשנות מסלול זיכוי ומה העלות של מסלולים מהירים יותר אם הם קיימים.
חוויית התשלום חשובה להמרה
לקוח שהגיע לשלב התשלום כבר ביצע חלק גדול מהדרך. אם דווקא שם הוא מקבל מסך מבלבל, מעבר שנראה חשוד או טופס שקשה להשתמש בו מהטלפון, ניתן לאבד את העסקה ברגע האחרון.
כדאי לבדוק את הקופה במובייל, בדפדפנים שונים ובתהליך אמיתי. מספר השדות, בהירות הכפתורים, הודעות השגיאה והמעבר בין החנות לספק התשלום צריכים להרגיש רציפים.
Redirect לעומת תשלום בתוך החנות
יש ספקים שבהם התשלום מתבצע בעמוד או חלון שמנוהל על ידי הספק, ויש אינטגרציות שבהן חוויית התשלום מרגישה כחלק ישיר יותר מהחנות. לכל מודל יש יתרונות וחסרונות.
הדבר החשוב הוא שהלקוח יבין שהוא נמצא בתהליך בטוח ושלא יאבד בדרך. אם מתבצע מעבר לדומיין אחר, הוא צריך להיות ברור ומקצועי. אם התשלום מוטמע, יש לוודא שהאינטגרציה מטפלת באבטחה ובדרישות הספק בצורה נכונה.
אבטחת פרטי תשלום אינה מקום לקיצורי דרך
פרטי כרטיס ותשלום הם מידע רגיש. בעל חנות לא צריך לבנות בעצמו מערכת שאוספת ושומרת מספרי כרטיסים אם אין לכך צורך ברור ותשתית מתאימה.
הגישה הנכונה ברוב המקרים היא להשתמש באינטגרציה הרשמית של ספק תשלום שמטפלת בפרטי הכרטיס בהתאם לדרישות האבטחה שלו, כך שמערכת החנות אינה שומרת מידע רגיש שאינה צריכה להחזיק.
HTTPS הוא דרישת בסיס
החנות כולה, ובמיוחד הקופה, צריכה לפעול בחיבור מאובטח. לקוח שמקבל אזהרת אבטחה מהדפדפן כמעט בוודאות לא ימשיך להזין פרטי תשלום.
בחנות מקצועית SSL צריך להיות חלק מהתשתית ולא פעולה ידנית שהעסק נדרש לבצע בכל פעם.
Webhook חשוב לא פחות מהמסך שהלקוח רואה
אחת הנקודות הקריטיות באינטגרציית תשלום היא הדרך שבה ספק הסליקה מעדכן את החנות על תוצאת העסקה. לא נכון להסתמך רק על כך שהלקוח חזר לדף תודה לאחר התשלום.
לקוח יכול לסגור את הדפדפן, לאבד חיבור או לא לחזור מהספק למרות שהעסקה הצליחה. webhook מאומת מאפשר לספק לעדכן את השרת ישירות, וכך ניתן לקבוע את סטטוס התשלום לפי מידע אמין מהספק.
צריך לאמת הודעות שמגיעות מספק התשלום
Endpoint ציבורי שמקבל webhook אינו יכול לסמוך על כל בקשה שנשלחת אליו. צריך להשתמש במנגנון האימות שהספק מגדיר ולוודא שהאירוע אכן הגיע ממנו.
בלי אימות נכון, גורם חיצוני עלול לנסות לשלוח בקשה שמתחזה לאישור תשלום. לכן אימות webhook הוא חלק מהותי מאבטחת מערכת התשלום.
אותו אירוע יכול להגיע יותר מפעם אחת
ספקי תשלום עשויים לשלוח webhook שוב כאשר לא התקבלה תשובה או כחלק ממנגנון retry. המערכת צריכה להיות מסוגלת לקבל את אותו אירוע יותר מפעם אחת בלי ליצור הזמנה חדשה או לחייב את אותו שינוי שוב.
זה המקום שבו idempotency ותיעוד מזהי העסקה הופכים חשובים. אירוע שכבר טופל צריך להיות מזוהה ולקבל טיפול בטוח.
סטטוס הזמנה וסטטוס תשלום אינם אותו דבר
הזמנה יכולה להיות חדשה, בטיפול, נשלחה או הושלמה. במקביל, התשלום יכול להיות ממתין, מאושר, נכשל, בוטל או הוחזר. לא כדאי לערבב בין שני המושגים.
הפרדה ברורה מאפשרת להבין למשל שהזמנה כבר שולמה אבל עדיין לא נשלחה, או שהזמנה נוצרה אך התשלום לא הושלם ולכן אסור להתחיל fulfillment.
עסקה שנכשלה צריכה לקבל טיפול ברור
עסקאות נכשלות מסיבות שונות: פרטי כרטיס, מגבלה, תקלה זמנית או ביטול של הלקוח. הודעת השגיאה צריכה לעזור ללקוח להבין מה ניתן לעשות הלאה בלי לחשוף פרטים טכניים שאינם רלוונטיים.
רצוי שהעגלה לא תיעלם בגלל ניסיון תשלום שנכשל. אם הלקוח יכול לתקן פרטים או לבחור אמצעי תשלום אחר ולהמשיך, הסיכוי להציל את העסקה גבוה יותר.
לא יוצרים הזמנה כפולה אם הלקוח מנסה שוב
לקוח שלחץ פעמיים על כפתור או חזר מהתשלום וניסה שוב לא אמור ליצור שתי הזמנות משולמות בטעות. תהליך checkout צריך להיות מתוכנן כך שניתן לזהות את אותו ניסיון ולמנוע duplication כאשר הפעולה היא למעשה אותה רכישה.
זו אחת הסיבות לכך שהחיבור בין cart, checkout, payment attempt וה-order חשוב מבחינה ארכיטקטונית ולא רק מבחינת UI.
ביטול והחזר הם חלק מהתהליך כבר מהיום הראשון
גם אם העסק מצפה למעט החזרות, צריך לדעת מה קורה כאשר נדרש refund. האם ההחזר מתבצע דרך מערכת החנות או דרך ממשק ספק הסליקה? האם סטטוס ההזמנה מתעדכן? האם ניתן לבצע החזר חלקי?
תהליך מסודר חוסך טעויות ומונע מצב שבו הכסף הוחזר אצל הספק אבל החנות עדיין מציגה את ההזמנה כאילו הכל שולם כרגיל.
החזר חלקי חשוב בחנויות עם כמה פריטים
אם לקוח רכש כמה מוצרים ורוצה להחזיר רק אחד מהם, ייתכן שהעסק יצטרך לבצע refund חלקי. כדאי לבדוק מראש האם הספק והתשתית תומכים בכך ואיך הנתון נשמר במערכת.
החזר חלקי צריך להיות מתועד כדי שהעסק יוכל לראות מה הסכום המקורי, כמה הוחזר ומה הסכום שנותר בפועל.
מטבע החנות צריך להתאים לסליקה
לפני חיבור ספק תשלום צריך לוודא שהוא תומך במטבע שבו החנות מוכרת. בחנות שפונה לכמה שווקים יש לבדוק גם כיצד הספק מטפל במטבעות שונים ובהמרות.
המחיר שהלקוח רואה בקופה והסכום שנשלח לספק צריכים להיות תואמים. אסור לבצע המרה או rounding באופן לא עקבי בין החנות למערכת התשלום.
לא סומכים על המחיר שמגיע מהדפדפן
השרת צריך לחשב מחדש את סכום ההזמנה לפי המחירים, המבצעים, המשלוח והכללים העסקיים לפני יצירת התשלום. ערך שמגיע מה-frontend אינו מקור אמין למחיר סופי.
זו הגנה בסיסית מפני שינוי ידני של בקשה וגם דרך לוודא שכללי התמחור מופעלים במקום אחד.
מבצעים וקופונים חייבים להיות חלק מהחישוב לפני התשלום
כאשר יש הנחה, הקופה, ההזמנה וספק התשלום צריכים לעבוד עם אותו סכום סופי. המבצע לא צריך להיות רק תצוגה בצד הלקוח.
כדאי לבדוק תרחישים של קופון תקין, קופון לא תקין, מבצע אוטומטי, משלוח חינם ומוצרים שאינם משתתפים במבצע.
בדקו גם את תרחיש ה-3D Secure או אימות נוסף
בחלק מהעסקאות הלקוח נדרש לבצע אימות נוסף דרך חברת האשראי או הבנק. התהליך יכול לכלול מעבר למסך נוסף וחזרה לחנות.
צריך לוודא שהחנות ממשיכה נכון לאחר האימות ושגם במצב שבו הלקוח סוגר את המסך באמצע מתקבל סטטוס שאינו מסמן את העסקה כהצלחה בטעות.
התשלום צריך לעבוד היטב במובייל
חלק גדול מהלקוחות ישלימו רכישה מהטלפון. מסך תשלום שדורש zoom, שדות שקשה למלא או מעבר שמקפיץ את המשתמש לאפליקציה לא צפויה יכולים לגרום לנטישה.
בדיקת תשלום אמיתית במכשירי מובייל חשובה לא פחות מבדיקת עמודי המוצר.
כדאי להפריד בין Sandbox ל-Live
במהלך פיתוח והקמה צריך להיות ניתן לבדוק עסקאות בלי לחייב כסף אמיתי. ספקי תשלום רבים מציעים סביבת sandbox או credentials נפרדים לבדיקות.
המעבר לפרודקשן צריך להיות ברור ומבוקר. אסור שמפתחות בדיקה יישארו בטעות בחנות חיה או שמפתחות production ישמשו בסביבת פיתוח לא מאובטחת.
סודות תשלום לא שייכים ל-frontend
API keys, webhook secrets ומפתחות פרטיים צריכים להישמר בצד השרת ובהתאם למנגנון הסודות של התשתית. אין להכניס אותם לקוד client שנשלח לדפדפן.
כאשר יש token ציבורי שמיועד במפורש ל-client, משתמשים רק בו ובדיוק לפי התיעוד של הספק. סודות שרת נשארים בשרת.
לוגים צריכים לעזור בלי לחשוף מידע רגיש
כאשר תשלום נכשל, חשוב שיהיה מידע שמאפשר להבין מה קרה. מצד שני, אין לשמור בלוג מספר כרטיס מלא, קוד אבטחה או מידע אחר שאסור למערכת להחזיק.
מזהה עסקה, מזהה הזמנה, provider, status וקוד שגיאה עסקי בדרך כלל מספקים בסיס טוב לחקירה מבלי לחשוף פרטים רגישים.
Reconciliation עוזר לזהות פערים
בעסק שגדל כדאי להיות מסוגלים להשוות בין עסקאות אצל ספק התשלום לבין ההזמנות במערכת. כך אפשר לזהות תשלום שקיים אצל הספק אך לא קושר נכון להזמנה, refund שלא עודכן או פער אחר.
לא כל עסק קטן צריך מערכת reconciliation מורכבת ביום הראשון, אבל הארכיטקטורה צריכה לשמור מזהים ונתונים שמאפשרים לבצע את הבדיקה בעת הצורך.
הלקוח צריך לקבל אישור ברור לאחר הצלחה
אחרי תשלום מוצלח, הלקוח צריך לדעת שההזמנה התקבלה. מסך תודה, מספר הזמנה ואימייל אישור יכולים למנוע מצב שבו הוא לוחץ שוב כי אינו בטוח אם העסקה עברה.
המסך לא צריך להציג מידע רגיש, אבל כן כדאי להראות סיכום שימושי ולהסביר מה השלב הבא.
לא שולחים מוצר לפני שיש אישור תשלום אמין
בחלק מהמערכות הזמנה נוצרת עוד לפני שהעסקה הושלמה. לכן צוות fulfillment צריך לדעת אילו סטטוסים מאפשרים להתחיל לטפל בהזמנה ואילו עדיין ממתינים לתשלום.
הסתמכות רק על כך שקיימת רשומת order יכולה לגרום לשליחת מוצרים עבור עסקה שנכשלה.
בודקים שהמערכת יודעת להתמודד עם timeout
שירותי תשלום הם שירותים חיצוניים, ולכן לעיתים בקשה יכולה להתעכב או להיכשל זמנית. checkout צריך לדעת להתמודד עם timeout בלי ליצור מצב לא ברור.
אם הלקוח אינו יודע האם חויב, אסור פשוט להציע לו לשלם שוב בלי לבדוק. מצב כזה מחייב לוגיקה שמאפשרת לברר את סטטוס ניסיון התשלום הקיים.
תמיכה של ספק התשלום חשובה יותר בזמן תקלה
כשהכל עובד קל להתייחס לתמיכה כפרט שולי. כאשר עסקאות מתחילות להיכשל ביום עמוס, זמן תגובה ואיכות התמיכה הופכים משמעותיים מאוד.
לפני בחירת ספק כדאי לבדוק כיצד יוצרים קשר, מה שעות הפעילות, האם יש תיעוד טכני מסודר ואיך מטופלות בעיות בפרודקשן.
בודקים כיצד מופיע החיוב אצל הלקוח
השם שמופיע בפירוט האשראי צריך להיות מזוהה ככל האפשר עם העסק. חיוב בשם שהלקוח לא מזהה יכול לגרום לפנייה לשירות או אפילו להכחשת עסקה.
אם הספק מאפשר להגדיר descriptor או שם תצוגה, כדאי לוודא שהוא ברור ובהתאם למגבלות הספק.
Chargebacks הם סיכון עסקי שצריך להכיר
לקוח יכול במקרים מסוימים לערער על עסקה דרך חברת האשראי. זהו תהליך שונה מהחזר רגיל ויכול לכלול מסמכים, זמני תגובה ועלויות.
שמירת תיעוד של הזמנה, תשלום, משלוח ותקשורת עם הלקוח יכולה להיות חשובה אם העסק צריך להציג הוכחות לגבי העסקה.
בחנות בינלאומית הדרישות יכולות להשתנות
עסק שמוכר למדינות שונות צריך לבדוק תמיכה בכרטיסים בינלאומיים, מטבעות, מגבלות גאוגרפיות, מסים והיבטים רגולטוריים שיכולים להשתנות בין שווקים.
אין להניח שספק שמתאים לפעילות מקומית יתאים אוטומטית לכל מדינה שהחנות רוצה למכור אליה.
איך להשוות ספקי סליקה בצורה מעשית
- רשמו אילו אמצעי תשלום הלקוחות צריכים
- בדקו אילו מטבעות נתמכים
- השוו עמלה לעסקה ועלויות קבועות
- בדקו זמני זיכוי
- בדקו תמיכה בתשלומים
- בדקו כיצד מבצעים ביטול והחזר
- בדקו האם יש refund חלקי
- עברו על תהליך checkout במובייל
- בדקו איכות API ותיעוד אם נדרש חיבור טכני
- ודאו שקיים webhook מאובטח
- בדקו סביבת sandbox
- בדקו איכות וזמינות התמיכה
- חשבו עלות לפי נפח העסקאות הצפוי ולא רק לפי אחוז בודד
בדיקות שחייבים לבצע לפני פתיחת החנות
לפני שמתחילים לקבל כסף אמיתי, צריך לעבור על תרחישים שונים ולא רק לבצע עסקת הצלחה אחת.
- עסקה מוצלחת
- עסקה שנדחתה
- לקוח שביטל באמצע התשלום
- תשלום עם הנחה
- תשלום עם משלוח בתשלום
- תשלום עם משלוח חינם
- מוצר עם וריאציה
- ניסיון תשלום חוזר
- קבלת webhook
- שליחת webhook כפול
- החזר מלא בסביבת בדיקה אם הספק מאפשר
- החזר חלקי אם הפיצר נתמך
- תשלום במובייל
- בדיקת אימייל אישור לאחר העסקה
מה לבדוק אחרי העסקה הראשונה בפרודקשן
גם אחרי שכל הבדיקות הצליחו, העסקה האמיתית הראשונה שווה בדיקה ידנית. פתחו את ההזמנה וודאו שסכום ההזמנה תואם לספק, שהסטטוס נכון, שהמשלוח חושב כפי שצריך ושהלקוח קיבל אישור.
בדיקה של מספר העסקאות הראשונות יכולה לזהות פערים קטנים לפני שהמערכת מתחילה לעבד עשרות או מאות הזמנות.
טעויות נפוצות בחיבור סליקה
- בחירת ספק רק לפי עמלה בלי לבדוק עלויות נוספות
- הסתמכות על redirect של הלקוח במקום webhook מאומת
- שמירת secrets בצד ה-client
- סימון הזמנה כמשולמת לפני אישור אמין
- אי טיפול ב-webhook כפול
- יצירת הזמנה חדשה בכל retry
- אי בדיקת תשלום במובייל
- אי בדיקת refunds לפני ההשקה
- חוסר הפרדה בין test ל-production
- חישוב המחיר הסופי רק ב-frontend
- חוסר תיעוד של מזהה העסקה אצל ספק התשלום
סליקה טובה צריכה להיות חלק טבעי מהחנות
מהצד של בעל העסק, המטרה היא לא לחשוב על מערכת התשלום בכל הזמנה. לאחר שהחיבור מוגדר ונבדק, הזמנה משולמת צריכה להגיע לממשק הניהול עם סטטוס ברור והמידע הדרוש להמשך טיפול.
מהצד של הלקוח, התהליך צריך להיות קצר, מובן ואמין. הוא לא צריך לדעת אילו webhooks, tokens או services עובדים מאחוריו. הוא צריך לדעת כמה הוא משלם, כיצד הוא משלם ושההזמנה התקבלה.
לסיכום
סליקה בחנות אינטרנטית היא הרבה יותר מכפתור שמקבל כרטיס אשראי. היא מחברת בין הקופה, ספק התשלום, ההזמנה, הלקוח והתפעול של העסק. לכן צריך לבחור ספק לפי התאמה כוללת ולא רק לפי אחוז עמלה.
לפני שמתחילים למכור כדאי לבדוק עלויות, אמצעי תשלום, זמני זיכוי, תשלומים, refunds, אבטחה, webhooks, מובייל ותמיכה. לאחר מכן צריך לבדוק את התהליך המלא גם בתרחישים שבהם התשלום מצליח וגם כאשר משהו משתבש.
כאשר הסליקה בנויה נכון, היא כמעט נעלמת מהחוויה. הלקוח משלם, העסק מקבל הזמנה אמינה והמערכת יודעת בדיוק מה קרה בכל שלב. זה הבסיס לתהליך checkout שאפשר לסמוך עליו גם כשהחנות מתחילה לגדול.