מתי חנות צריכה בדיקה ממוקדת ולא עוד תוסף
כדאי להתחיל בבדיקה כאשר לא ברור מי יכול לשנות פרטי סליקה, אילו חיבורים מחזיקים גישה להזמנות, אם עדכונים נדחו או אם איש לא ניסה לשחזר את החנות. גם החלפת מפתח, הוספת מסוף או מעבר אחסון מצדיקים מיפוי מחדש. הצורך אינו נקבע רק לפי מספר המוצרים: חנות קטנה עם כמה ספקי אינטגרציה יכולה להיות מורכבת מבחינת גישות ונתונים.
אם כבר מופיעים קוד זר, שינוי בפרטי יעד תשלום או חשיפה של מידע לקוחות, מתחילים בבירור אירוע ובשמירת ראיות. הקשחה שגרתית אינה מחליפה טיפול בפריצה. אם הבעיה היא רק תשלום שנכשל, מאמתים את מצב העסקה אצל הספק לפני פעולה חוזרת; הודעת שגיאה באתר לבדה אינה סיבה לחייב שוב.
מה ממפים לפני שמציעים עבודה
מפת החנות כוללת אחסון, WordPress, WooCommerce, תבנית, הרחבות, תפקידי עובדים וחיבורים לתשלום, משלוחים, חשבוניות ומלאי. מתעדים מי מנהל כל רכיב, האם קיימת גישה לשינוי ואיזו פעולה עסקית תלויה בו. רכיב שאינו נגיש לבדיקה מסומן כמגבלה ולא כתקין.
לכל מסלול מכירה חשוב מגדירים בדיקת קבלה: סוג מוצר, אמצעי תשלום, משלוח או איסוף, עדכון הזמנה והמסירה למערכת הבאה. אין צורך להעתיק פרטי לקוחות להצעה. בשיחה ראשונית מספיק לתאר את המערכות ואת התלות שלהן; גישה מוגבלת מוסדרת רק לאחר אישור ההיקף.
| תחום | מה בוחנים | מה צריך להימסר |
|---|---|---|
| ניהול וגישה | חשבונות, תפקידים, אימות וספקים קודמים | רשימת גישות מאושרת וחריגים |
| תוספים וקוד | גרסאות, מקור עדכונים ותלויות | תוכנית שינוי ובדיקות תאימות |
| תשלום והזמנה | ממשק סליקה ואישור עסקה בצד השרת | תוצאות מסלולי הקבלה שסוכמו |
| חיבורים | מפתחות, הרשאות, יעדי webhook ויומנים | בעל תפקיד לכל חיבור ופער פתוח |
| התאוששות | קבצים, נתונים, עיתוי גיבוי וסביבה נפרדת | היקף בדיקת שחזור אם נכללה |
הקשחת גישות, רכיבים והחיבורים לחנות
לפי הממצאים והתכולה שאושרה, אפשר להסדיר חשבונות אישיים, לצמצם הרשאות עודפות, לטפל בגישות ישנות ולתכנן עדכונים לרכיבים נתמכים. חיזוק גישה כולל גם את חשבון האחסון ואת הדרך לשחזר שליטה. סגירת חשבון WordPress אינה מבטלת בהכרח מפתח API או גישה אצל ספק חיצוני.
בהגנות רשת ובכללי WAF מתחשבים בקופה, בכניסה ללקוח ובקריאות שרת. חריג גורף למסלול תשלום עלול להסיר הגנה מעבר לנדרש. אם נדרש חריג, בודקים את סיבת החסימה ואת הבקשה המסוימת, מסכמים היקף מצומצם ומתעדים כיצד תיבדק הפעילות לאחר השינוי.
איך בודקים סליקה בלי ליצור נזק עסקי
לפני הזמנת ניסיון מוודאים שסביבת הבדיקה מופרדת ושהמסוף נמצא במצב בדיקה הנתמך על ידי ספק הסליקה. בוחנים גם חיבורי דואר, חשבוניות, משלוחים, מלאי ו-CRM. הזמנה מלאכותית יכולה להפעיל פעולות אמיתיות במערכות האלה גם כאשר אין חיוב אמיתי.
בדיקת תשלום בוחנת את הקשר בין תוצאת הספק לבין מצב ההזמנה, ולא רק את עמוד התודה. כשל, ביטול ותוצאה ממתינה דורשים התנהגות מוגדרת. בדיקות כפילויות והודעות חוזרות מתבצעות רק בסביבה מורשית ובהתאם לתיעוד החיבור; לא משחזרים הודעות תשלום על ייצור כדי לראות מה יקרה.
גיבוי ושחזור בחנות שממשיכה לקבל הזמנות
בחנות פעילה נדרש להבין איזו נקודת זמן מגובה ואילו שינויים נוצרו מאז: הזמנות, חיובים, מלאי ונתוני לקוחות. החזרת מסד נתונים ישן יכולה למחוק הזמנות חדשות באתר בלי לבטל את העסקאות אצל ספק התשלום. לכן שינוי שמחייב שחזור צריך לכלול גם דרך לשמר וליישב נתונים שנוצרו בינתיים.
אם בדיקת שחזור נכללת בהצעה, מגדירים סביבה מבודדת, הרשאה לנתונים והפעולות העסקיות שייבדקו בה. הצלחת פתיחת עמוד אינה מספיקה לאישור חנות. תוצאת הבדיקה מתייחסת להיקף שנוסה; היא אינה מבטיחה אותו זמן התאוששות בכל אירוע או התאמה לכל רכיב חדש.
מה תקבלו ואיך יודעים שהעבודה הסתיימה
סיכום העבודה צריך להפריד בין ממצאים, שינויים שבוצעו, בדיקות קבלה והמלצות שנותרו. לכל פער נשאר בעל תפקיד: העסק, CyberFixCrew, חברת האחסון או ספק החיבור. אם תיקון מחייב שינוי קוד שאינו כלול, מציגים זאת לפני התחייבות לביצוע ולא מסמנים את הנושא כסגור.
אפשר לשלב בהיקף מסמך מסירה עם רכיבים שנבדקו, תוצאות מסלולי הזמנה, תיעוד הגדרות רלוונטי ומעקב אחר חריגים. תיעוד למסירה אינו מכיל סיסמאות, מפתחות או מידע מלא של לקוחות. שמירת סודות ושיתוף ראיות מוסדרים בנפרד ובגישה מצומצמת.
מחיר, מגבלות ומה אינו כלול אוטומטית
המחיר נקבע לפי מספר החיבורים, סוגי מסלולי הרכישה, היקף ההרשאות, זמינות סביבת בדיקה והצורך בתיקון לעומת סקירה בלבד. מפרידים בין עבודה חד פעמית, רישיונות צד שלישי ותחזוקה שוטפת. לאחר בירור מציגים הצעה עם תכולה, תלויות ועלויות שאינן חלק מהשירות.
העבודה אינה אישור PCI DSS, ייעוץ משפטי, ניטור SOC או הבטחה למניעת הונאות וחיובים חוזרים. דרישות ספק הסליקה וההסדר המתאים לבית העסק נבחנים עם הגורמים הרלוונטיים. שימוש בדף תשלום חיצוני אינו הופך אוטומטית את אתר החנות לחסר אחריות אבטחתית.
מה להכין לפנייה ומה קורה לאחר מכן
שלחו כתובת חנות, תיאור צורך, שם האחסון ושמות חיבורי הסליקה והמערכות העסקיות אם הם ידועים. ציינו אם יש תקלה פעילה, שינוי קרוב או ספק תחזוקה קיים. אין לשלוח סיסמאות, קודי אימות, פרטי כרטיס או דוחות לקוחות בטופס הפנייה.
לאחר הבירור מסכמים יעדים, מי מאשר שינוי ואיך מודיעים על מגבלה שמתגלית בדרך. עם סיום העבודה מגדירים מי מטפל בעדכונים ובהתראות בהמשך. תחזוקה יכולה להיות שלב נפרד; תוצאת בדיקה ישנה אינה תחליף לבחינה לאחר חיבור חדש או שינוי מהותי.