שילוב 1C-Bitrix עם מערכת התשלומים Sberbank Online
לעתים קרובות אנו נתקלים בבעיה נפוצה: חנות מקוונת על Bitrix עובדת מצוין, וההזמנות זורמות. עם זאת, קונים מרבים להתקשר ולבקש "להוציא חשבונית דרך Sber" — הם לא רואים את כפתור התשלום בעמוד הקופה. חיבור Sberbank Online ל-Bitrix נותן מענה לבקשה זו וחושף מספר ניואנסים טכניים שאינם ברורים בשלב "פשוט התקן את המודול". בניסיון שלנו, כל לקוח שלישי מגיע עם הכאב הזה: היעדר אמצעי תשלום שבו משתמשים 60% מהקונים. השלמנו למעלה מ-50 אינטגרציות של מערכות תשלום, אז בואו נבחן את כל המלכודות.
למה המודול המוכן לא תמיד פותר את הבעיה?
המודול הרשמי sberbank.ecom מכסה 80% מהתרחישים הסטנדרטיים, אבל כשצריך לוגיקה לא סטנדרטית — למשל, אינטגרציה עם 1C לשינוי סטטוס אוטומטי או תשלום דו-שלבי להזמנות מוקדמות — הפתרון המוכן הופך לצוואר בקבוק. השוואה: המודול המוכן מותקן תוך 30 דקות, בעוד שפתרון מותאם אישית דורש 3–5 ימים אבל נותן שליטה מלאה על עיבוד התשלומים. היחס בין מהירות לגמישות הוא בערך 10:1, אבל פיתוח מותאם אישית גמיש פי 3.
איך שער התשלומים של Sberbank עובד
Sberbank Online פועל דרך REST API של סליקה (securepayments.sberbank.ru/payment/rest/ לסביבת ייצור, 3dsec.sberbank.ru/payment/rest/ לבדיקות). סכמת האינטראקציה:
- החנות קוראת ל-
register.do— רושמת את ההזמנה במערכת של Sberbank, מקבלתorderIdו-formUrl - הקונה מופנה ל-
formUrl— עמוד התשלום של Sberbank - לאחר התשלום, Sberbank מפנה את הקונה ל-
returnUrlושולח הודעה ל-failUrlאו מבצע callback - החנות קוראת ל-
getOrderStatus.doלבדיקת סטטוס סופית
חשוב קריטי לא להסתמך רק על returnUrl לאישור תשלום — הקונה עלול לסגור את הטאב לאחר התשלום מבלי לחכות להפניה. תמיד יש צורך ב-callback או בבדיקה תקופתית של getOrderStatus.do. מקור: תיעוד סליקה של Sberbank
מתי נדרשת אינטגרציה מותאמת אישית?
במערכת האקולוגית של Bitrix, Sberbank Online מיושם כ-handler של מערכת תשלום במודול sale. ישנן שתי דרכים.
מודול מוכן מה-Marketplace. המודול הרשמי של Sberbank (sberbank.ecom) זמין ב-marketplace.1c-bitrix.ru. לאחר ההתקנה, בסעיף חנות → הגדרות → מערכות תשלום, מופיע סוג חדש עם שדות userName, password (או token לסכמת אימות חדשה). המודול רושם את ה-handler \Sale\Handlers\PaySystem\SberbankHandler וכתובת webhook כמו /bitrix/tools/sale_ps_result.php.
Handler מותאם אישית נדרש כאשר: משתמשים בסכמת הזמנות לא סטנדרטית, נדרשת אינטגרציה עם 1C לשינוי סטטוס אוטומטי, או שהמודול המוכן מתנגש עם רכיבים אחרים. הוא ממוקם ב-/local/php_interface/include/sale_payment/sberbank_custom/, עם מבנה סטנדרטי עבור Sale PaySystem.
פרמטרים מרכזיים ברישום הזמנה
קריאת register.do דורשת פרמטרים חובה:
| פרמטר | תיאור | סוג |
|---|---|---|
orderNumber |
מספר ייחודי במערכת החנות (בדרך כלל BXORDER_{ID}) |
string |
amount |
סכום בקופיקות (טעות נפוצה — העברה בדולרים) | integer |
returnUrl |
כתובת חזרה לאחר תשלום | string |
currency |
קוד מטבע (643 לדולרים לפי ISO 4217) | integer |
לצורך פיסקליזציה (54-FZ), הבקשה כוללת אובייקט orderBundle עם פריטי מוצר, שיעורי מע"מ וסימני מושא תשלום. ללא orderBundle, הקופה של Sberbank לא תייצר קבלה — זו סיבה נפוצה לתביעות של רשויות המס נגד חנויות ש"כביכול חיברו קופה מקוונת". פרטים נוספים על הדרישות — בויקיפדיה.
טיפול בהודעות וסטטוסים
Sberbank שולח הודעת POST ל-checkUrl כאשר סטטוס העסקה משתנה. ב-Bitrix, handler ה-callback חייב:
- לקבל POST, לנתח
mdOrderו-orderNumber - לקרוא ל-
getOrderStatus.doכדי לקבל את הסטטוס בפועל (לא לסמוך על נתוני callback ללא אימות) - בסטטוס
2(שולם), לקרוא ל-$payment->setPaid('Y')ולשמור את העסקה - להחזיר תשובה
{"errorCode": 0}— אחרת Sberbank ינסה שוב
טבלת סטטוסים עבור getOrderStatus.do:
| קוד | ערך | פעולה |
|---|---|---|
| 0 | הזמנה נרשמה | המתן |
| 1 | הסכום אושר מראש | לתשלומים דו-שלביים |
| 2 | שולם | אשר ב-Bitrix |
| 3 | האישור בוטל | בטל הזמנה |
| 4 | החזר הושלם | עדכן סטטוס |
| 6 | האישור נדחה | הודע לקונה |
תשלום דו-שלבי
מהו תשלום דו-שלבי ומתי הוא נדרש?
למוצרים עם משלוח דחוי (הזמנה מוקדמת, מחסן), משתמשים בסכמה דו-שלבית: registerPreAuth.do חוסם את הסכום על הכרטיס, deposit.do מחייב בעת המשלוח. תשלום דו-שלבי מפחית את סיכון ה-chargeback בעד 50%. Sberbank מספקת את שתי השיטות, אבל תשלום דו-שלבי דורש הפעלה נפרדת בהסכם הסליקה. ב-Bitrix, זה מיושם על ידי פיצול ה-handler לשני שלבים והוספת כפתור 'אשר תשלום' נוסף בממשק הניהול של ההזמנות. פרטים נוספים על היישום — בתיעוד Bitrix.
איך להימנע מתשלומים כפולים?
מהניסיון שלנו: חנות אלקטרוניקה מקוונת בגרסת Bitrix מודרנית. לאחר המעבר מסביבת בדיקות לסביבת ייצור, כ-3% מהעסקאות שוכפלו — הקונה שילם פעם אחת, אבל שני תשלומים נרשמו בהזמנה. סיבה: ה-handler של returnUrl וה-callback הגיעו כמעט בו-זמנית, ושניהם הצליחו לקרוא ל-setPaid('Y'). פתרון — הוסף בדיקה $payment->isPaid() לפני האישור והשתמש בנעילה דרך \Bitrix\Main\Application::getConnection()->lock() במהלך עיבוד העסקה.
בדיקות
סביבת הבדיקות של Sberbank (3dsec.sberbank.ru) עובדת עם כרטיסי בדיקה מהתיעוד. הקפד לבדוק:
- תשלום מוצלח עם אישור callback
- ביטול בעמוד התשלום (הקונה לחץ 'חזור')
- פסק זמן של סשן (ברירת מחדל 1200 שניות — Sberbank מבטלת הזמנות שלא הושלמו)
- יצירת קבלה נכונה כאשר הפיסקליזציה מופעלת
מה כלול בעבודה?
- ביקורת של תצורת Bitrix הנוכחית ואמצעי התשלום
- הגדרת המודול המוכן או פיתוח handler מותאם אישית
- אינטגרציה עם פיסקליזציה (54-FZ) וקופה
- בדיקת כל התרחישים: הצלחה, כישלון, פסק זמן, שכפול
- תיעוד (מדריך התקנה, פרמטרי API, פתרון תקלות)
- גישה לסביבת בדיקות למשך 30 יום
- מפגש הדרכה (שעה) לצוות שלך
- 30 ימי תמיכה לאחר ההשקה
לוח זמנים ועלות
לוח הזמנים של האינטגרציה תלוי בתצורה: התקנת מודול מוכן ללא קופה — מיום עד יומיים. אינטגרציה מותאמת אישית עם 54-FZ, תשלום דו-שלבי והתאמה למבנה הזמנות לא סטנדרטי — מ-3 עד 7 ימי עסקים. מחירים: התקנת מודול מוכן מ-$200; אינטגרציה מותאמת אישית מ-$800; אינטגרציה מלאה עם פיסקליזציה מ-$1,200. 80% מהלקוחות שלנו בוחרים באינטגרציה מותאמת אישית בגלל הגמישות. אנו עובדים עם Bitrix למעלה מ-5 שנים וביצענו 50+ אינטגרציות של מערכות תשלום — זה מאפשר לנו להבטיח איכות. צור קשר כדי לדון בפרטי האינטגרציה שלך. נכין פתרון מותאם לעסק שלך ונתחשב בכל הפרטים.