מה גורם לשגיאות סליקה באתר ואיך מאתרים אותן

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

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

איך עסקת סליקה עוברת בפועל

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

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

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

מה גורם לשגיאות סליקה באתר: המקורות העיקריים

הגדרות שגויות בחיבור לספק הסליקה

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

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

תוסף סליקה, וורדפרס או חנות שלא עודכנו יחד

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

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

התנגשות עם תוסף אחר או קוד מותאם אישית

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

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

בעיות תקשורת, אבטחה ואחסון

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

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

שגיאות בצד הלקוח שאינן תקלת אתר

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

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

כך מאתרים את מקור התקלה בלי לנחש

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

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

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

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

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

תקלות מסוכנות במיוחד: חיוב בלי הזמנה והזמנה בלי חיוב

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

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

מניעה היא חלק מתפעול החנות

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

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

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