בדיקת אינטגרציות 1C-Bitrix עם מערכות תשלום

בדיקת אינטגרציות 1C-Bitrix עם מערכות תשלום

שער התשלום אישר את העסקה, ה-webhook הגיע, אבל ההזמנה נשארה בסטטוס "ממתין לתשלום". או גרוע מכך—אותו webhook עובד פעמיים, ונוצרו שתי הזמנות בתשלום. בדיקות סטנדרטיות לרוב מפספסות תרחישים אלה. במהלך שנים של עבודה עם 1C-Bitrix ואינטגרציות מערכות תשלום (YooKassa, Sber, Tinkoff, Robokassa), למדנו לתפוס בעיות כאלה לפני העלייה לאוויר. המתודולוגיה שלנו מכסה את כל האירועים האסינכרוניים: הפנייה לשער התשלום, הודעות webhook (כולל מעוכבות וכפולות), טיפול בסטטוסים ופיסקליזציה לפי 54-FZ. לפי סטטיסטיקות, 80% מתקלות התשלום מתרחשות עקב עיבוד שגוי של webhook—אנחנו מבטלים סיכונים אלה במהלך הבדיקות.

אילו סיכונים הבדיקה מכסה?

התרחישים העיקריים שאנחנו תמיד בודקים:

1. תשלום מוצלח – זרימה רגילה: עגלה → קופה → הפנייה → תשלום → חזרה לאתר → שינוי סטטוס הזמנה.
2. תשלום שנדחה – כרטיס נדחה, סטטוס ההזמנה צריך להישאר "ממתין לתשלום", לא "בוטל".
3. תרחיש סגירת דפדפן – הלקוח עזב אחרי ההפניה מבלי להשלים תשלום; webhook לא התקבל; יש לטפל בהזמנה כראוי בביקור חוזר.
4. Webhook מעוכב – webhook מגיע 10–20 דקות אחרי התשלום (נפוץ עם Robokassa, Sber); סטטוס ההזמנה חייב להתעדכן כראוי.
5. Webhook כפול – אותה הודעה מגיעה פעמיים; עיבוד חוזר לא אמור להכפיל את סטטוס "שולם".
6. החזר חלקי – 1–2 ימים אחרי התשלום, אנחנו בודקים POST /refunds ואת קבלת ההחזר.
7. החזר מלא – עם אימות קבלה פיסקלית (אם קופה רושמת מחוברת לפי 54-FZ).

איך אנחנו בודקים: גישת מומחים

אנחנו משתמשים בשילוב של בדיקות אוטומטיות ומנואליות. לדוגמה, בפרויקט מסחר אלקטרוני גדול, גילינו ש-webhook כפול גרם ליצירת הזמנה כפולה. אחרי יישום caching עם מזהה תשלום ייחודי, לא התרחשו כפילויות. זה צמצם את זמן התגובה לאירועים ב-40% וחסך ללקוח אובדן הכנסות (מוערך ב-$5,000 לכל אירוע שנמנע). הערימה הטכנולוגית שלנו כוללת:

• Playwright לתרחישי end-to-end עם כרטיסי בדיקה אמיתיים.
• ngrok או localtunnel כדי לחשוף סביבה מקומית למשלוח webhook.
• שאילתות SQL מותאמות אישית לאימות מצבי מסד הנתונים.

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

איך להתגונן מפני webhooks כפולים?

לפי התיעוד הרשמי, המטפל חייב להיות עמיד בפני הודעות כפולות. ה-URL הסטנדרטי ב-Bitrix: /bitrix/tools/sale_ps_result.php. במהלך הבדיקות, אנחנו תמיד בודקים idempotence—הגנה מפני עיבוד חוזר של כפילויות. אנחנו משתמשים ב-caching:

$cache = Cache::createInstance();
$cacheId = 'payment_processed_' . $paymentId;
if ($cache->initCache(86400, $cacheId, '/sale/payment')) {
    return;
}
$cache->startDataCache();
$cache->endDataCache(['processed' => true]);

ללא caching כזה, webhooks כפולים יכולים להוביל לתשלום כפול. אנחנו גם בודקים הודעות מעוכבות—בעיה נפוצה.

למה חשוב לבדוק webhooks מעוכבים?

עיכובים במשלוח webhook הם התנהגות סטנדרטית עבור מערכות תשלום רבות. אם המטפל לא מתוכנן לקבל הודעה 15–30 דקות אחרי התשלום, ההזמנה עלולה להישאר בסטטוס "ממתין לתשלום". הלקוח עוזב, אבל הכסף כבר נוכה. אנחנו מדמים עיכובים כאלה באמצעות כלים כמו $cache = Cache::createInstance(); $cacheId = 'payment_processed_' . $paymentId; if ($cache->initCache(86400, $cacheId, '/sale/payment')) { return; } $cache->startDataCache(); $cache->endDataCache(['processed' => true]); ומוודאים שהסטטוס מתעדכן כראוי גם עם השהיה.

נקודות אימות טכניות

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

SELECT o.account_number, p.paid, p.date_paid, p.ps_status, p.ps_status_message
FROM b_sale_order_payment p
JOIN b_sale_order o ON o.id = p.order_id
WHERE o.account_number = '12345'
ORDER BY p.date_paid DESC;

אנחנו בודקים ש-b_sale_order_payment מכיל את הסטטוס המקורי ממערכת התשלום, לא רק כן/לא. זה קריטי לאבחון post-mortem.

ערכת כלים

לבדיקת הודעות webhook בסביבה מקומית, אנחנו משתמשים ב-SELECT o.account_number, p.paid, p.date_paid, p.ps_status, p.ps_status_message FROM b_sale_order_payment p JOIN b_sale_order o ON o.id = p.order_id WHERE o.account_number = '12345' ORDER BY p.date_paid DESC; או ps_status—הם מעבירים URL חיצוני לשרת המקומי. ללא זה, בדיקת הודעות אסינכרוניות ממערכות תשלום היא בלתי אפשרית.

לאוטומציה, אנחנו משתמשים ב-Playwright או Cypress עם כרטיסי בדיקה אמיתיים. Playwright מהיר פי 3 מ-Selenium ויציב יותר לתרחישים אסינכרוניים. כרטיסי בדיקה למערכות שונות:

מה כלול בעבודה

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

לוח זמנים ועלות

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

הניסיון שלנו

הצוות שלנו הוא שותף Bitrix מוסמך עם מומחיות מוכחת. בדקנו מעל 100 פרויקטים, כולל אינטגרציות עם YooKassa, Sber, Tinkoff, Robokassa, PayPal ואחרות. הלקוחות שלנו חוסכים עד 30% מתקציבי התמיכה בזכות זיהוי מוקדם של בעיות. אנחנו מבטיחים אינטגרציות תשלום ללא תקלות ומספקים אחריות להחזר כספי על שירותי הבדיקה שלנו.

קבלו ייעוץ

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