התחילו במפת מסלול התשלום
בררו היכן הלקוח מזין פרטי תשלום: באתר הספק לאחר הפניה, בשדה משובץ של הספק או בממשק אחר. תעדו את התוסף, הגרסה, בעל החשבון, היעד שאליו יוצאים והדרך שבה החנות מקבלת אישור. אל תניחו ששני מסופים פועלים באותו אופן רק מפני שהכפתור נראה דומה.
מפת המסלול צריכה לענות גם מה נשמר בחנות ומה עובר לספקים נוספים. לא כל נתון שמופיע ביומן דרוש לאבחון. צמצמו פרטי לקוח ואל תצרפו מספרי כרטיס, קודי אבטחה או מפתחות לצילומי מסך. אם מימוש הסליקה אינו ברור, בקשו הסבר ותיעוד מהספק לפני בדיקות.
| גבול | מה מבקשים לדעת | ראיה מתאימה |
|---|---|---|
| דפדפן וסקריפטים | מי יכול לשנות את המסך ואת יעד ההפניה | רשימת רכיבים ויעדים מאושרים |
| חנות וספק סליקה | איך מזהים את בית העסק ואת ההזמנה | תיעוד חיבור וסודות מוסתרים |
| אישור לשרת | איך מאמתים הודעה ומונעים פעולה כפולה | תרחיש קבלה בסביבה נפרדת |
| הזמנה ומערכות המשך | מתי מופעלים מלאי, חשבונית ומשלוח | תיעוד מעבר מצב ותוצאת כל חיבור |
SSL, יעד תשלום וסקריפטים: מה הם מוכיחים
HTTPS מגן על התעבורה בין הצדדים שהחיבור מגיע אליהם. הוא אינו מוכיח שהיעד הוא הספק שהתכוונתם אליו או שקוד החנות לא שינה את ההפניה. בדקו שהדומיין והגדרות בית העסק תואמים לתיעוד הספק ושלא נוספו רכיבים לא מוכרים באזור הקופה.
סקריפטים וכלי תגיות עשויים לפעול בדפדפן בעמוד שבו הם נטענים, בהתאם להטמעה ולהרשאות בפועל. צריך לברר אילו מהם נחוצים בקופה ואילו נתונים הם מקבלים. כללי CSP או בידוד שדות יכולים להיות חלק מהפתרון, אך שינוי ללא בדיקת תאימות עלול לשבור תשלום תקין.
מכינים סביבת בדיקה לפני יצירת הזמנה
הכינו סביבת בדיקה עם חשבונות ונתונים מלאכותיים, גישה מוגבלת ומצב בדיקה של ספק הסליקה. העתק אתר אינו בידוד בפני עצמו: צריך לבחון מפתחות ייצור, כתובות callback וחיבורי דואר, מלאי, חשבוניות ומשלוחים. חסימת הודעות בתוסף אחד אינה מוכיחה שספק SMTP חיצוני או CRM לא יפעלו.
קבלו אישור לבדיקות ותעדו אילו תופעות לוואי מנוטרלות ואילו מבוקרות. אל תשתמשו בכרטיס אמיתי כדי לבדוק כשל ואל תיזמו עומס או הונאה מדומה. אם לספק אין מסלול בדיקה מתאים, עוצרים ומגדירים איתו דרך אימות מורשית במקום לבצע ניסוי על לקוחות אמיתיים.
טבלת הקבלה: הצלחה, כשל, ביטול ותוצאה ממתינה
לכל מסלול בדיקה רשמו את התוצאה הצפויה אצל ספק התשלום, בהזמנה ובמערכות ההמשך. השתמשו במזהה ניסיון מלאכותי ובזמן בדיקה כדי להשוות תוצאות בלי לחשוף פרטים רגישים. הסטטוס המדויק תלוי בתוסף ובשיטת התשלום; אין מצב הזמנה אחד שנכון לכל סוגי העסקאות.
אם הדפדפן נסגר או החזרה לאתר נכשלת, ייתכן שהספק כבר קיבל תוצאה. לכן עמוד התודה אינו המקור היחיד להכרעה. מי שבודק צריך לזהות מהו מקור האישור המוסמך ומה קורה כאשר הודעת השרת מתעכבת. בדיקה של חריג כזה נעשית בתיאום ובהתאם לתיעוד הספק.
| תרחיש | מה משווים | מה לא עושים |
|---|---|---|
| הצלחה מדומה | סכום, מטבע, הזמנה ואישור הספק | לא מסתפקים בעמוד תודה |
| כשל או ביטול | מצב ההזמנה והיעדר מסירה לא נכונה | לא מחייבים שוב בלי בירור |
| תוצאה ממתינה | מי עוקב ומתי מתקבלת הכרעה | לא מסמנים שולם בהשערה |
| הודעה חוזרת | פעולה עסקית אחת לפי תכנון החיבור | לא משחזרים הודעות ייצור |
| החזר מדומה אם נתמך | התאמה בין הספק להזמנה ולחשבונית | לא מבצעים החזר אמיתי כניסוי |
אישור שרת, מפתחות ו-webhooks
לפי סוג החיבור, מפתח או מנגנון חתימה יכולים לסייע לאמת הודעה בין מערכות. בדקו עם המפתח כיצד מתבצע אימות זהות השולח, איך ההודעה נקשרת להזמנה ומה מונע שינוי כפול. פרטי המימוש חייבים להישען על תיעוד החיבור בפועל; הגדרת webhook יוצא של WooCommerce אינה זהה לכל אישור נכנס מספק סליקה.
מפתחות צריכים להיות משויכים לסביבה ולבעל תפקיד ולא להופיע בקוד ציבורי או ביומן משותף. לפני החלפה של סוד בודקים אילו מערכות צורכות אותו ומה יהיה סדר המעבר. אם יומן מציג משלוח כושל, אין להסיק שהתשלום נכשל; בודקים בנפרד את מצב העסקה ואת משמעות האירוע.
מה בדיקה טכנית אינה אומרת על PCI DSS
מבנה התשלום משפיע על דרישות בית העסק ועל שאלון ההערכה שעשוי להתאים לו. PCI SSC מבחין בתנאים מסוימים בין טופס תשלום משובץ לבין הפניה לספק חיצוני. הבחנה זו אינה פטור גורף מאבטחת אתר ואינה אישור שהחנות עומדת בכל דרישה רלוונטית.
את ההתאמה להסדר ולדרישות הסליקה מבררים עם הספק והגורם המוסמך. אין לבחור שאלון רק משום שתוסף משווק כמאובטח. המדריך אינו הסמכה או חוות דעת תאימות; הוא מסייע להכין שאלות ולתעד בדיקות של היישום הקיים.
מה עושים כשמתגלה פער
כאשר מופיע חיוב ללא הזמנה תואמת או להפך, שומרים מזהים וזמנים בצורה מצומצמת ומשווים מול הספק. לא מפעילים משלוח מחדש, החזר או חיוב חוזר לפני בירור. חשד לשינוי יעד תשלום או לקוד זר דורש טיפול באירוע ולא רק בדיקת תפקוד רגילה.
בסיום רשמו מה נבדק, מה נכשל, מי מטפל ומתי יבוצע אימות חוזר. ממצא כמו חיבור שלא ניתן לבדוק נשאר פער פתוח. אם נדרש שינוי, הכינו גיבוי, תיאום ודרך חזרה ובדקו גם את ההשפעה על הזמנות שנוצרות בזמן העבודה.
