הזמנות לא נרשמות בווקומרס: תקלות סליקה אפשריות שמשפיעות עליך

לקוח כותב בוואטסאפ ששילם וקיבל הודעת חיוב מהבנק, אבל בווקומרס אין שום הזמנה על שמו. התגובה הראשונה היא לחשוד בלקוח, אבל ברוב המקרים הוא צודק. התרחיש הזה אינו נדיר: ב-4 מתוך 13 חנויות ווקומרס ישראליות שנבדקו נמצאו הזמנות שלא נרשמו אף שהחנות מכרה בפועל, או תקלות בקופה שבעלי החנות לא ידעו עליהן (מדד ג'ימי, נתוני הדוחות היומיים, 7 עד 17.9.2026). ברוב המקרים התקלה אינה בווקומרס עצמו וגם לא אצל הלקוח, אלא בתקשורת בין שער הסליקה לחנות.

התשובה הקצרה, לפני שממשיכים: כשהזמנה "נעלמת" אחרי תשלום, בדקו קודם את סטטוס ההזמנה בממשק הסליקה עצמו (טרנזילה או PayPlus), ולא רק בווקומרס. ב-3 מתוך 4 מקרים כאלה שנבדקו, הבעיה הייתה בדיוק שם: webhook שלא הגיע או נכשל (נתוני הדוחות היומיים של ג'ימי). הטיפול במקרה כזה שונה לגמרי מהטיפול בעגלה נטושה רגילה. הלקוח כבר שילם בפועל, אבל ההזמנה לא נרשמה אצלכם כמו שצריך.

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

מה הסטטוסים בווקומרס אומרים

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

סטטוס	המשמעות הרשמית	מה לבדוק אצלכם
Pending payment	ההזמנה נוצרה, התשלום עדיין לא אושר	האם חלפה יותר משעה בלי עדכון? זה סימן לתקלת webhook
On-hold	תשלום חלקי או המתנה לאישור ידני	בישראל, לרוב מדובר בעגלה נטושה ולא בתשלום אמיתי
Processing	התשלום אושר, ההזמנה ממתינה לטיפול	תקין, כך נראה התהליך הרגיל
Failed	הסליקה נכשלה במפורש	בדקו את קוד השגיאה בממשק שער הסליקה
Completed	הטיפול הושלם	תקין

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

איך ספק סליקה "מדבר" עם ווקומרס

כשלקוח משלם, שער הסליקה (טרנזילה, PayPlus או כל שער אחר) שולח לחנות התראה אוטומטית שנקראת webhook או IPN. משמעות ההתראה היא "התשלום הצליח, עדכן את ההזמנה". התהליך מתרחש ברקע, בלי שהלקוח או בעלי החנות רואים אותו בזמן אמת, ולכן קשה לזהות כשל בלי לבדוק זאת ביוזמתכם. אם ההתראה לא מגיעה, העדכון בעקבותיה לא מתבצע כראוי או הגדרת אבטחה בשרת חוסמת אותה בדרך, ווקומרס לא יודע שהתשלום התבצע. מבחינת הלקוח, הוא שילם. מבחינת החנות, ההזמנה לא קיימת או נשארת בסטטוס pending ללא הגבלת זמן.

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

איך מבדילים בפועל בין עגלה נטושה לתקלת סליקה

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

תקלות ידועות בטרנזילה

בחנות שנבדקה נמצאו הזמנות שנתקעו בסטטוס pending בעקבות שגיאות טרנזילה מסוג 900 (3D Secure Failed) ו-901 (שגיאה לא מזוהה) (נתוני הדוחות היומיים של ג'ימי). שגיאת 3D Secure Failed לא בהכרח מעידה שהלקוח נכשל באימות. לפעמים האימות מול הבנק הצליח, אבל העברת התגובה בין הבנק לטרנזילה ולשרת החנות לא הושלמה כראוי בגלל timeout. במצב כזה ווקומרס מקבל סטטוס כשל גם כשהלקוח חויב בפועל. כשלקוח מדווח ששילם אבל ההזמנה לא מופיעה, בדקו קודם את יומן העסקאות בממשק הניהול של טרנזילה עצמו. אם העסקה מופיעה שם כמאושרת, אבל ההזמנה בווקומרס עדיין בסטטוס pending או failed, זו כמעט תמיד תקלת webhook ולא כשל בתשלום עצמו. אין טעם לבקש מהלקוח לנסות לשלם שוב לפני שבדקתם את מצב העסקה.

תקלות דומות ב-PayPlus

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

דוגמה לציר זמן: איך זה נראה בפועל

לקוח מבצע רכישה בשעה 20:14. הבנק שלו מאשר את החיוב ושולח לו הודעת SMS. באותו רגע שער הסליקה אמור לשלוח webhook לחנות. ה-webhook לא מגיע אם שרת החנות עמוס, אם כתובת ה-callback הוגדרה לא נכון אחרי עדכון תוסף או אם חומת אש חוסמת בקשות מהכתובת של שער הסליקה. ההזמנה נשארת בסטטוס pending payment בווקומרס, או לא נוצרת כלל אם התהליך נעצר לפני יצירת רשומת ההזמנה. הלקוח כבר קיבל אישור מהבנק, ולכן אינו יודע שיש בעיה. הוא פונה לחנות רק כעבור יום-יומיים, כשאינו מקבל הודעת משלוח.

למה לא לחכות שהלקוח יתלונן

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

מה לבדוק ולתעד כשזה קורה

פתחו את ההזמנה, אם היא נוצרה, ובדקו את הערות ההזמנה (Order notes) בתחתית העמוד. שם ווקומרס מתעד כל ניסיון תקשורת עם שער הסליקה, כולל שגיאות, קודי תשובה וזמני ניסיון. לרוב זו הדרך המהירה ביותר להתחיל באבחון, כי התיעוד כבר נמצא בתוך ההזמנה ולא דורש גישה נפרדת. אם ההזמנה לא נוצרה כלל, סננו בטבלת ההזמנות הראשית (Orders) את ההזמנות בסטטוס pending ו-failed מטווח התאריכים הרלוונטי, והשוו אותן ליומן העסקאות בממשק הסליקה לאותו יום. בדקו גם את השעה המדויקת, כי הפרשי שעות בין המערכות יכולים להקשות על ההתאמה. בקשו מהמפתח או מהקמפיינר לוודא שכתובת ה-callback (Webhook URL, לפי תיעוד ווקומרס) בהגדרות שער הסליקה מפנה לכתובת הנכונה, ושאין בשרת הגדרת אבטחה שחוסמת בקשות נכנסות משם. להרחבה על תקינות המעקב כולו, קראו את מדריך מעקב ההמרות בווקומרס, ועל פערי דיווח בין המערכות קראו במאמר הייעודי.

אחרי שמצאתם תשלום שלא נרשם: איך משחזרים את ההזמנה

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

איך מונעים את התקלה מראש במקום להסתפק באבחון בדיעבד

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

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

למה זה קורה יותר בעונות עומס

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

הפער הישראלי: למה הבדיקה חשובה יותר כאן

אף אחד מהמדריכים הכלליים לניהול הזמנות בווקומרס לא מזכיר את טרנזילה או PayPlus בהקשר הטכני. המדריכים מתמקדים בשערי סליקה גלובליים כמו Stripe או PayPal, שמטפלים ב-webhooks אחרת. בישראל הבדיקה שונה מזו שמתוארת בתיעוד האנגלי הסטנדרטי: החנות מחוברת לספק סליקה מקומי, אבטחת 3D Secure נפוצה יותר בכרטיסי אשראי מקומיים, וצריך לתעד מע"מ כראוי גם על הזמנה שנתקעה.

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

מה לעשות עכשיו

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

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

שאלות שכדאי לשאול את המפתח או הסוכנות

מה כתובת ה-Webhook שמוגדרת אצל שער הסליקה, והאם היא זהה לכתובת שהחנות מצפה לה בפועל? כמה הזמנות נמצאות כרגע בסטטוס pending יותר מ-24 שעות, ומה מצבן בממשק הסליקה? האם יש התראה אוטומטית כשהזמנה נתקעת, או שהגילוי תלוי כרגע בבדיקה ידנית? ומתי בדקתם לאחרונה שכתובת ה-callback עדיין תקינה אחרי עדכון תוסף או שינוי בשרת?