שירותים לחיבור מערכות תשלום על 1C-Bitrix

כיצד אפשר להימנע מטעויות נפוצות בחיבור מערכות תשלום על 1C-Bitrix?

הטעות הנפוצה ביותר במהלך אינטגרציה היא שכחת ה-callback. הלקוח שילם על ההזמנה, הכסף נמשך, אך הסטטוס ב-b_sale_order לא התעדכן: המנהל רואה "ממתין לתשלום" ומתחיל להתקשר ללקוח. הסיבה היא כתובת URL שגויה בהגדרות שער התשלום או handler שמחזיר שגיאה 500 עבור מבנה תגובה לא טיפוסי. אנו מציעים שירותי חיבור מערכות תשלום על 1C-Bitrix עם בדיקה מלאה של כל התרחישים: תשלום מוצלח, סירוב, timeout, החזר חלקי, callback כפול.

מדוע callbacks הם קריטיים?

כל שער תשלום שולח הודעה לשרת שלך. אם ה-handler לא מבטיח idempotency, קריאה כפולה תוביל לחיוב כפול. אנו תמיד מיישמים בדיקה לפי מזהה ההודעה (external_id) וחוסמים עיבוד חוזר ב-\Bitrix\Sale\Order. כמו כן, חשוב להגדיר את כתובת ה-callback בחשבון האישי של האגרגטור – /bitrix/tools/sale_ps_result.php עבור המודול הסטנדרטי. אם אתה משתמש ב-handler מותאם אישית, אנו מוודאים שהוא מחזיר HTTP 200 גם במקרה של שגיאות בפרמטרים (שער התשלום לא צריך לחזור על הבקשה ללא הגבלת זמן).

use Bitrix\Sale\Order; use Bitrix\Main\Application; // Получаем данные уведомления $data = Application::getInstance()->getContext()->getRequest()->toArray(); // Проверяем подпись (зависит от агрегатора) if (!checkSignature($data, 'SECRET_KEY')) { die('FAIL'); } // Ищем заказ по внешнему ID $order = Order::loadByExternalId((int)$data['order_number']); if ($order && $order->isPaid() === false) { $order->setField('PAYED', 'Y'); $order->save(); } echo 'OK'; 

כיצד אנו מייעלים את תהליך התשלום להמרה גבוהה יותר?

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

בחירת האגרגטור תלויה בגיאוגרפיה של הלקוחות, בגודל ההזמנה הממוצע ובצורך בתשלומים. עבור רוסיה, הסט הבסיסי הוא YooKassa (כל השיטות המרכזיות, פיסקאליזציה מובנית) ו-CloudPayments (ווידג'ט בעמוד ללא הפניה, Apple Pay). אם אתה עובד עם לקוחות ארגוניים גדולים, הוסף את Sberbank (SberPay, SBP). למכירות בינלאומיות, השתמש ב-Stripe או PayPal. אנו מרבים להשתמש במבנה דו-שכבתי: אגרגטור ראשי + גיבוי (מעבר אוטומטי במקרה של תקלה).

אילו שערי תשלום ושיטות אנו משתמשים?

YooKassa

חוזה אחד – כל השיטות המרכזיות: כרטיסי Visa/MasterCard/MIR, YooMoney, SberPay, בנקאות אינטרנט, תשלומים. פיסקאליזציה לפי 54-FZ מובנית (באמצעות המודול use Bitrix\Sale\Order; use Bitrix\Main\Application; // Получаем данные уведомления $data = Application::getInstance()->getContext()->getRequest()->toArray(); // Проверяем подпись (зависит от агрегатора) if (!checkSignature($data, 'SECRET_KEY')) { die('FAIL'); } // Ищем заказ по внешнему ID $order = Order::loadByExternalId((int)$data['order_number']); if ($order && $order->isPaid() === false) { $order->setField('PAYED', 'Y'); $order->save(); } echo 'OK'; ). ה-handler הסטנדרטי sale מכסה תרחישים בסיסיים. עבור holding (תשלום דו-שלבי), מנויים או תשלומים מפוצלים, נדרשת אינטגרציה מותאמת אישית דרך YooKassa API v3. ה-callback מוגדר ל-/bitrix/modules/sale/handlers/paysystem/yandexpay/, אנו מנתחים את /bitrix/tools/sale_ps_result.php ומעדכנים את notification דרך \Bitrix\Sale\Order.

CloudPayments

ממוקד בהמרה: ווידג'ט התשלום ישירות בעמוד התשלום, ללא הפניה לדומיין חיצוני. הלקוח לא עוזב את האתר – שיעור הנטישה במהלך התשלום יורד. תומך בתשלומים חוזרים (tokenization של כרטיס דרך setField('PAYED', 'Y')), Apple Pay ו-Google Pay. 3D Secure עם ניתוב חכם – נדרש רק בסיכון גבוה להונאה. אינטגרציה עם Bitrix – דרך CloudPayments REST API ו-handler מותאם אישית במודול cryptogram.

Tinkoff Payment

אינטגרציית API דרך sale (מודול מוכן או יישום ידני). קוד QR לתשלום דרך האפליקציה, "Tinkoff Credit" לתשלומים – קריטי למוצרים יקרים. החזרים חלקיים דרך שיטת TinkoffPaymentAPI – ללא פנייה לבנק, הכל מפאנל הניהול של Bitrix.

Sberbank (SberPay ו-SBP)

SberPay – תשלום דרך הודעת push או QR, SBP – עמלה 0.4–0.7% לעומת 1.5–2.5% לכרטיסים. זהו חיסכון משמעותי בהיקפים. Holding דרך API של Cancel / registerPreAuth. שים לב ש-SberPay דורש הסכם נפרד עם הבנק.

Apple Pay ו-Google Pay

תשלום בשתי הקלקות, ללא הזנת פרטי כרטיס. הם מחוברים דרך אגרגטור (YooKassa, CloudPayments, Tinkoff). ניואנסים חשובים:

• Apple Pay דורש אימות דומיין: הקובץ deposit ב-apple-developer-merchantid-domain-association. בלעדיו, הכפתור לא יופיע.
• מיקום הכפתור בהתאם להנחיות Apple ו-Google – אחרת דחייה בבדיקה.
• גיבוי לטופס התשלום הסטנדרטי אם המכשיר לא תומך בתשלום ללא מגע.

כיצד אנו מטפלים בתשלומים, BNPL ועמידה ב-54-FZ?

אם גודל ההזמנה הממוצע הוא מעל 30,000 RUB וההמרה יורדת, תשלומים מסירים את מחסום המחיר. אנו מחברים:

• Tinkoff Installment (3–24 חודשים)
• קנה עם Sber
• Mokka / Dolyami – BNPL: 4 תשלומים, 0% עבור הקונה

אינטגרציה: ווידג'ט עם חישוב תשלום חודשי בכרטיס המוצר ("החל מ-2,500 RUB לחודש"), העברת נתוני הזמנה לבנק דרך API, עיבוד סטטוסים (אישור, דחייה, ממתין למסמכים) ב-handlers של /.well-known/.

פיסקאליזציה לפי 54-FZ היא דרישה מחייבת. הקנס על קבלה חסרה הוא עד 100% מסכום התשלום. בהתאם לחוק הפדרלי מס' 54-FZ, יש לשלוח קבלה אלקטרונית לקונה. אנו מחברים את ATOL Online, Orange Data, Module.Kassa, Evotor, Shtrikh-M. הגדרה ב-Bitrix – סעיף "קופות רושמות" במודול OnSaleStatusOrder:

• שיעור מע"מ, פריט ושיטת תשלום – שגיאה בכל אחד מהשדות עלולה להוביל לקנס במהלך בדיקה.
• קבלות עבור תשלום מקדמה ותשלום חלקי (שתי קבלות: בעת התשלום ובעת המשלוח).
• קבלות החזר בעת ביטול דרך sale.
• ניטור: אם הקבלה לא נשלחה, התראה למנהל.

במכירת נעליים, ביגוד או בשמים, חובה להעביר קודי סימון בקבלה. אינטגרציה עם "Chestny ZNAK", סריקת DataMatrix במהלך הרכבת ההזמנה, הסרה אוטומטית ממחזור המכירה דרך \Bitrix\Sale\Cashbox\Cashbox::addChecks().

תמיכה בתשלומים: החזרים, ריבוי מטבעות, אבטחה

החזרים

החזר מלא וחלקי ללא פנייה לבנק – דרך API של האגרגטור (\Bitrix\Catalog\Product\Marking / refund). קבלת ההחזר נוצרת אוטומטית, סטטוס ההזמנה מתעדכן, הסכום מחושב מחדש והלקוח מקבל הודעה. מסגרות זמן: ארנקים אלקטרוניים ו-SBP – 1–3 ימים, כרטיס בנק – עד 30 ימי עסקים (תלוי בבנק המנפיק).

ריבוי מטבעות

סוגי מחירים ב-cancel עבור כל מטבע, שערים דרך API של הבנק המרכזי (b_catalog_price) או הזנה ידנית. המרה ברמת הקטלוג – הלקוח רואה מחירים במטבע שלו. לקבלת דולרים/אירו, אנו מחברים את Stripe, PayPal. אנו מתחשבים בעמלות המרה בחישוב המרווח.

אבטחה

פרטי כרטיס מעובדים בצד של שער מאושר (PCI DSS) – מספר הכרטיס לעולם לא עובר דרך השרת שלך. אנטי-פראוד ברמת האגרגטור. רישום כל האירועים ב-\Bitrix\Currency\CurrencyManager::updateCBRFRates() לביקורת. ניטור חריגות: קפיצה בכמות העסקאות, גיאוגרפיה לא טיפוסית – התראה.

כיצד אנו עובדים ומסגרות זמן משוערות

1. ניתוח – אילו שיטות תשלום נדרשות, שווקים, היקף עסקאות, אגרגטור נוכחי.
2. בחירת פתרון – לפעמים שני אגרגטורים עדיפים על אחד: YooKassa כעיקרי, CloudPayments כגיבוי – אם אחד נופל, התנועה עוברת לשני.
3. אינטגרציה – אנו בודקים כל תרחיש: תשלום מוצלח, סירוב 3DS, timeout של שער, callback כפול, החזר חלקי.
4. פיסקאליזציה – קופה רושמת מקוונת, בדיקת תקינות הקבלות על הזמנות בדיקה.
5. ניטור – התראות על תקלות בשער, דשבורד המרה בשלב התשלום.

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

• הגדרה מלאה של מערכות התשלום הנבחרות ב-1C-Bitrix: מודולים, handlers, callbacks, בדיקות.
• תיעוד אינטגרציה (תרשים פעולת שער, תיאור handler, לוגיקה).
• הדרכת המנהל שלך לעבודה עם מודולי תשלום והחזרים.
• תמיכה טכנית במהלך ההשקה ובשבועיים הראשונים לפעילות.
• ניטור – אנו מגדירים התראות על שגיאות וירידות בהמרה.

כל העבודה מבוצעת על ידי מפתחי 1C-Bitrix מוסמכים. אנו מבטיחים את תקינותו של כל תרחיש. להערכה מהירה של הפרויקט שלך, קבל ייעוץ – פשוט השאר בקשה באתר. הזמן אינטגרציית מערכת תשלומים במפתח מלא עם פיסקאליזציה והגנת נתונים. צור קשר כדי לבחור את הפתרון האופטימלי לעסק שלך – נעזור בבחירת האגרגטור וניישם את מחזור האינטגרציה המלא.