סליקה וחשבוניות בחנות WooCommerce
09/11/2026

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

המחשה של הכנת הזמנה בחנות אונליין
מה המחקר מלמד על נטישת קופה
בסקירה שעודכנה באוקטובר 2026, מכון Baymard מציג שיעור נטישת סל ממוצע של 70.22%. זהו ממוצע לא משוקלל של 50 מחקרים מהשנים 2006 עד 2025, עם הבדלים בשווקים ובאופן המדידה. הוא מתאר תופעה רחבה, ואינו מדד ישראלי או תחזית לחנות מסוימת.
לצד הסקירה, Baymard מפרסם ממצאים מסקר בקרב קונים בארצות הברית. 17% דיווחו על נטישת הזמנה בגלל סיבה שהמכון מנסח כך, בתרגום מאנגלית: ״תהליך תשלום ארוך או מסובך מדי״. גם גלישה ללא כוונת קנייה היא סיבה משמעותית לנטישה. לכן אין לייחס את כל הסלים הנטושים לתקלה טכנית.
היישום בחנות פשוט: הציגו את עלות המשלוח והסכום הסופי מוקדם ככל האפשר, הסירו שדות שאין בהם צורך ונסו להשלים רכישה כאורחים, אם החנות מאפשרת זאת. תעדו היכן הקונה נדרש לעצור, לתקן מידע או לחזור לעמוד קודם. כך אפשר להפריד בין קושי בקופה לבין חוסר עניין במוצר.
מודדים מהירות במקום להסתפק בתחושה
בדוח Milliseconds Make Millions משנת 2020, שהכינה Deloitte על בסיס ניתוח של Fifty-Five ובהזמנת Google, נבדקו נתוני מובייל של 37 מותגים באירופה ובארצות הברית לאורך ארבעה שבועות. בקבוצת אתרי הקמעונאות דווח על עלייה יחסית של 8.4% בהמרות, שנקשרה לשיפור של עשירית שנייה בארבעה מדדי מהירות שנבחנו יחד. בדוח נכתב, בתרגום מאנגלית: ״שיפורים במהירות אתרי מובייל נמצאו במתאם ישיר עם התקדמות במשפך הרכישה״.
זהו מחקר תצפיתי על אתרי מותגים, המבוסס על מודל סטטיסטי ועל תנודות מהירות טבעיות. הוא אינו ניסוי שמבטיח תוספת מכירות לכל חנות, ואינו בודק שדרוג אחסון לבדו. המסקנה המעשית היא למדוד את חוויית הקנייה במובייל, לזהות מה מאט אותה ולבחון את התוצאה לאחר תיקון.
למעקב שוטף אפשר להיעזר במדדי Core Web Vitals של Google. היעדים לחוויה טובה הם LCP של עד 2.5 שניות להצגת התוכן המרכזי, INP של עד 200 אלפיות שנייה לתגובה לפעולות, ו־CLS של עד 0.1 ליציבות התצוגה. בוחנים את האחוזון ה־75 של הנתונים, בנפרד למובייל ולמחשב. בדיקת מעבדה בכלי PageSpeed Insights מועילה לאבחון, ונתוני משתמשים בפועל משקפים את החוויה באתר.
מדדו עמוד מוצר, סל וקופה, ותעדו גם את הזמן של שינוי כמות, החלת קופון ובחירת משלוח. בפנייה לחברת האחסון צרפו את כתובת העמוד, שעת הבדיקה והפעולה שהתעכבה. פרטים אלה עוזרים לה לבדוק את בקשת השרת הרלוונטית ולברר אם המקור הוא במשאבי השרת, בתוסף או בשירות חיצוני.
מגדירים מטמון שמתאים לחנות
מטמון עמודים שומר עותק מוכן כדי לחסוך עבודה בכל ביקור. בקופה מופיעים פרטים שמשתנים לפי הלקוח והסל שלו. בתיעוד הרשמי של WooCommerce מופיעה הנחיה להחריג ממטמון עמודים את סל הקניות, הקופה וחשבון הלקוח. ההסבר, בתרגום מאנגלית: ״עמודים אלה צריכים להישאר דינמיים, משום שהם מציגים מידע ייחודי ללקוח הנוכחי ולסל שלו״.
בדקו עם חברת האחסון שההחרגות חלות גם על המטמון בשרת או ברשת הפצת התוכן, אם קיימים, וגם על תוסף המטמון באתר. לאחר מכן פתחו שני חלונות גלישה נפרדים, הוסיפו מוצרים שונים וודאו שכל סל נשאר עצמאי. שנו כתובת, שיטת משלוח וקופון ובדקו שהסכום מתעדכן. בדיקה זו יכולה לחשוף מידע ישן שמוגש לקונה גם כשהעמוד נטען מהר.
מאמתים תשלום גם כשהלקוח סוגר את הדפדפן
אחרי התשלום הלקוח עשוי לסגור את הלשונית לפני החזרה לחנות. מסך התודה לבדו אינו מספיק כדי לקבוע אם הכסף התקבל. תיעוד WooCommerce מתאר גם עדכוני שרת מספקי תשלום, המכונים callbacks, שמאפשרים לשער התשלום לעדכן את מצב ההזמנה. בבחירת תוסף בקשו לדעת כיצד הוא מאמת את התשלום וכיצד מאתרים עסקה שהעדכון שלה התעכב.
במקרה של דיווח על חיוב ללא הזמנה מעודכנת, חפשו את מספר ההזמנה ואת מזהה העסקה אצל ספק התשלום. בדקו את האישור ואת הסכום לפני שינוי ידני או בקשת תשלום נוספת. אם הספק אישר תשלום אך המסמך טרם הופק, צריך לטפל בהפקה בלי ליצור חיוב נוסף. לפני הפקה ידנית חפשו גם מסמך קיים לאותה עסקה.
מחברים את ההזמנה למסמך העסקי
נניח שהלקוח קנה מוצרים ב־240 ₪, קיבל הנחה של 20 ₪ ושילם 30 ₪ עבור משלוח. בהנחה שהמחירים כוללים את המס הרלוונטי ואין רכיבים נוספים, הסכום לתשלום הוא 250 ₪. זהו הסכום שצריך להתאים בין הקופה, אישור הסליקה והמסמך. ההשוואה צריכה לכלול גם את פרטי הלקוח ואת רכיבי ההזמנה, כדי שאפשר יהיה להסביר כיצד התקבל הסכום.
לדוגמה, Daily לחנויות אונליין מציעה תוסף WooCommerce שמחבר את תשלום ההזמנה ליצירת מסמך לאחר אישור מלא ומאומת, לפי הגדרות העסק. אפשר לדמות אישור ודחייה בבדיקת קופה ללא חיוב וללא הפקת מסמך כספי. בדיקה זו מסייעת לבחון את התנהגות החנות; לאחריה נדרשת גם בדיקה מבוקרת של מסלול התשלום החי. מדריך ההתקנה והבדיקה מפרט את השלבים.
לפני ההפעלה בוחרים את סוג המסמך עם רואה החשבון או יועצת המס, בהתאם לעסק ולמסמכים שכבר הופקו. גם היקף החיבור דורש בירור: הפקת מסמך אינה מעידה כשלעצמה על סנכרון מלאי בין המערכות. את ניהול הכמויות וההחזרות צריך להגדיר ולבדוק בנפרד.
מתכננים את הטיפול בהחזר מראש
לפי תיעוד WooCommerce, שינוי סטטוס להזמנה שבוטלה או הוחזרה אינו מחזיר כסף באופן אוטומטי. החזר אוטומטי מתוך ההזמנה תלוי בתמיכת שער התשלום; החזר ידני בממשק מתעד את הפעולה, ומצריך גם החזרת כסף מחוץ לממשק הזה. לפני תחילת המכירות, הגדירו מי מבצע את ההחזר וכיצד נשמרת האסמכתה שלו.
בחיבור Daily המתואר במדריך הנוכחי, ההחזר הכספי מתבצע דרך ספק התשלום, והטיפול במסמך נעשה בנפרד. המדריך למסמכי WooCommerce מפרט את התהליך. גם בהחזר חלקי יש לקשר בין ההזמנה, הסכום שהוחזר והמסמך המתאים, כדי שמי שמטפל בלקוח יוכל לדעת מה כבר בוצע.
רשימת בדיקות לפני פתיחת הקופה
אפשר להשתמש בטבלה כבדיקת קבלה משותפת לבעל העסק ולמי שמתחזק את האתר. התחילו בסביבה נפרדת שאינה פתוחה לקונים, בהתאם להוראות התוסף וספק התשלום. הדמיה ללא חיוב בודקת רק חלק מהתהליך; מסלול חי נבדק בנפרד ובאופן מבוקר. שמרו תוצאה ומספר הזמנה לכל תרחיש.
| תרחיש | מה בודקים | תוצאה רצויה |
| רכישה במובייל | משלימים קנייה במכשיר אמיתי, כולל בחירת משלוח. | השדות והכפתורים נגישים והסכום הסופי ברור לפני האישור. |
| קופון ומשלוח | משווים את המחיר אחרי הנחה ותוספת משלוח. | אותו סכום מופיע בהזמנה, בחיוב ובמסמך של עסקה חיה. |
| סלים נפרדים | משתמשים בשני דפדפנים או חלונות מבודדים. | לכל קונה סל עצמאי, ללא מוצרים או סכומים מהבדיקה האחרת. |
| תשלום שנדחה | מדמים דחייה בדרך שספק התשלום או התוסף מאפשרים. | מוצגת הודעה ברורה; ההזמנה אינה מטופלת כתשלום מאושר. |
| סגירת דפדפן | בתרחיש בדיקה נתמך, סוגרים לפני החזרה לחנות. | אפשר לברר את התשלום מול הספק וההזמנה בלי להסתמך על עמוד תודה. |
| חזרה לעמוד תודה | מרעננים את העמוד אחרי עסקת בדיקה מתאימה. | הרענון אינו יוצר חיוב נוסף או מסמך כפול. |
| החזר חלקי | בודקים את המסלול הנתמך ואת התיעוד הנדרש. | סכום ההחזר, אסמכתת הספק והמסמך המקושר ניתנים לאיתור. |
| שינוי באתר | לאחר עדכון תוסף או אחסון חוזרים על התרחישים הקריטיים. | התוצאות נשארות תקינות וההגדרות הנדרשות נשמרו. |
בודקים אם השינוי עזר
לפני תיקון ואחריו השוו תקופות בעלות תנועה דומה. עקבו אחר שיעור המבקרים שמתחילים קופה ומסיימים רכישה, הפרידו מובייל ממחשב, וספרו גם תשלומים שנכשלו ועסקאות מאושרות שהמסמך שלהן ממתין. שמרו על אותה הגדרת מדידה: שינוי במכשירים, במקורות התנועה או במבצע יכול להסביר חלק מהפער. התחילו בבעיה מתועדת אחת, תקנו אותה וחזרו לאותה בדיקה.
