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

כיצד להגדיר סליקת אינטרנט ב-1C-Bitrix?

המשימה של "חיבור תשלום בכרטיס" נראית טריוויאלית עד התקרית הראשונה בייצור: סטטוסי הזמנות לא מתעדכנים, הכסף הגיע אבל ההזמנה תקועה ב"ממתין לתשלום". הסיבה היא שה-webhook של הבנק לא מגיע לשרת בגלל WAF או שגיאת PHP. פרויקט אחד — חנות מקוונת לחלקי רכב עם קטלוג של 50,000 פריטים. בעת מעבר לשרת ייעודי, Cloudflare חסם בקשת POST מהבנק. האבחון ארך שעתיים, הפתרון — הגדרת חריגים בחומת האש. לאחר מכן, פיתחנו רשימת בדיקה אוניברסלית לבדיקת מסירת התראות. אנחנו, מהנדסים עם עשר שנות ניסיון בפיתוח Bitrix, נסקור את כל המחזור: מבחירת סכמה ועד אבחון. הגישה שלנו — אמינות ושקיפות, אנחנו מבטיחים שהאינטגרציה עובדת.

מידע נוסף על טכנולוגיית webhook ניתן לקרוא בוויקיפדיה Webhook.

שלוש גישות לאינטגרציה

מודול מוכן מ-Marketplace — ל-Sberbank, Tinkoff, YooKassa, Alfa-Bank יש מודולים רשמיים. מותקן דרך /bitrix/admin/update_system.php. מהיר, נתמך על ידי הספק, אבל גמישות מוגבלת.

Handler מותאם אישית ב-/local/ — כאשר המודול הסטנדרטי לא מכסה את הצרכים: מיפוי סטטוסים לא סטנדרטי, פיסקליזציה מותאמת אישית, מספר סולקים.

סליקה באמצעות JS Widget — CloudPayments, Robokassa מוטמעים דרך סקריפט. חלק מהעבודה על הלקוח, השרת רק מאמת את התוצאה.

התקנה והגדרה (דוגמה: Tinkoff)

לאחר התקנת המודול מה-Marketplace: חנות → הגדרות → מערכות תשלום → הוסף → Tinkoff.

Handler מותאם אישית: שלד מינימלי

<?php // local/php_interface/include/sale_payment/mybank/handler.php use Bitrix\Sale\PaySystem\BaseServiceHandler; use Bitrix\Sale\PaySystem\ServiceResult; use Bitrix\Sale\Payment; use Bitrix\Main\Request; class MyBankHandler extends BaseServiceHandler { public function initiatePay(Payment $payment, Request $request): ServiceResult { $result = new ServiceResult(); $order = $payment->getCollection()->getOrder(); $session = $this->createGatewaySession( $order->getId(), $payment->getSum() ); if (empty($session['payUrl'])) { $result->addError(new \Bitrix\Main\Error('Gateway error: ' . ($session['error'] ?? ''))); return $result; } $result->setPaymentUrl($session['payUrl']); return $result; } public function processRequest(Payment $payment, Request $request): ServiceResult { $result = new ServiceResult(); $data = json_decode(file_get_contents('php://input'), true); // ВСЕГДА верифицируем подпись — не доверяем данным из запроса if (!$this->verifySignature($data)) { $result->addError(new \Bitrix\Main\Error('Invalid signature')); return $result; } if (($data['status'] ?? '') === 'PAID') { $result->setOperationType(ServiceResult::MONEY_COMING); } return $result; } } 

אבחון: Webhook לא מגיע

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

# 1. Проверяем доступность endpoint извне curl -v -X POST https://shop.ru/bitrix/tools/sale_ps_result.php -d 'test=1' # Должен вернуть 200, не 403 # 2. Смотрим access.log на запросы от IP банка grep "sale_ps_result" /var/log/nginx/access.log | tail -50 # 3. Временное логирование (только при отладке!) file_put_contents('/tmp/ps_debug.log', date('Y-m-d H:i:s') . ' ' . $_SERVER['REMOTE_ADDR'] . ' ' . file_get_contents('php://input') . PHP_EOL, FILE_APPEND ); 

אשמים טיפוסיים: Cloudflare Bot Fight Mode חוסם בקשת POST ללא User-Agent; fail2ban חוסם את כתובת ה-IP של הבנק לפי מספר בקשות; שגיאת PHP קטלנית ללא רישום בלוג; הפניית HTTP→HTTPS מאבדת את גוף ה-POST.

למה Handler מותאם אישית עדיף על מודול מוכן?

מודול מוכן לא מאפשר מיפוי גמיש של סטטוסי הזמנות: לדוגמה, הסטטוס "SUCCESS" של Tinkoff יכול להתכוון ל"שולם" או "ממתין לאישור". Handler מותאם אישית נותן שליטה של 100% על הלוגיקה, ובנוסף יכולת לשלב מספר סולקים בממשק אחד. בעת אינטגרציה עם 1C ופיסקליזציה (54-FZ), גישה מותאמת אישית היא חובה — מודולים מוכנים לרוב לא תומכים ב-ATOL בתרחישים לא סטנדרטיים. דרישות 54-FZ מוסדרות על ידי החוק הפדרלי.

מתי נדרשת פיסקליזציה?

פיסקליזציה היא חובה לכל התשלומים המקוונים בפדרציה הרוסית. בעת תשלום בכרטיס, יש לשלוח קבלה פיסקלית לקונה באופן אלקטרוני. הגדרת פיסקליזציה כוללת אינטגרציה עם OFD ו-ATOL. בסט שלנו — ATOL Online, התומך ב-54-FZ. חיבור פיסקליזציה מוסיף 1–2 ימים ללוח הזמנים של הפיתוח.

איך אנחנו מבטיחים אמינות אינטגרציה?

לאחר ההגדרה, אנחנו מבצעים בדיקות עומס: מדמים עד 50 בקשות בו-זמנית מהבנק, בודקים טיפול נכון בכפילויות ובכשלים. עבור חנויות קריטיות, אנו מגדירים ניטור webhook דרך cron — כל 5 דקות בודקים שה-endpoint מחזיר 200. בחוזה, אנו קובעים ערבות מסירה: אם ההזמנה שולמה, הסטטוס ישתנה תוך מקסימום 30 שניות.

סליקה דו-שלבית

לחנויות ששולחות לאחר הזמנת סחורה:

// При оформлении заказа — холдируем (PayType=T у Тинькофф) // При смене статуса на "Отгружен" — подтверждаем списание AddEventHandler('sale', 'OnSaleStatusOrder', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); if ($order->getField('STATUS_ID') !== 'OD') return; foreach ($order->getPaymentCollection() as $payment) { if ($payment->getField('PS_STATUS') === 'hold') { capturePayment($payment->getField('PS_INVOICE_ID')); } } }); 

מה כלול?

החבילה המלאה בהזמנת הגדרת סליקה: ביקורת של מערכת התשלום הנוכחית, בחירת הסכמה האופטימלית, פיתוח או התאמה של ה-handler (כולל פיסקליזציה), הגדרת webhook ובדיקת מסירת התראות, אינטגרציה עם 1C (החלפת סטטוסים, סנכרון), תיעוד הגדרות ורישום, אחריות תמיכה לחודש לאחר ההשקה.

לוחות זמנים והמספרים שלנו

אנחנו עובדים עם 1C-Bitrix מעל 10 שנים והשלמנו 200+ פרויקטים עבור חנויות מקוונות ופורטלי B2B. מעל 50 מהם עם סליקה מותאמת אישית. במקרה של בעיות, אנו מגיבים תוך שעתיים, מספקים תעודות התאמה.

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