מה קורה כאשר התראות מוגדרות בצורה שגויה?
לקוח משלם על הזמנה, אך הסטטוס ב-Bitrix לעולם לא מתעדכן. הכסף מנוכה, הסחורה לא נשלחת – פניות לתמיכה נערמות. גורם השורש: טיפול לא נכון בהתראות או תזמון שגוי של קריאות API. אנו מתקנים זאת ברמת הארכיטקטורה על ידי שילוב 1C-Bitrix עם שער התשלומים Tinkoff במפתח מלא. אנו מגדירים את השער, פיסקליזציה 54-FZ, תשלומים חוזרים – הכל עם אחריות לפעולה יציבה תחת כל עומס. לצוות שלנו ניסיון של 5+ שנים והסמכת 1C-Bitrix, עם למעלה מ-100 אינטגרציות מוצלחות.
כיצד בנויה הארכיטקטורה של שער Tinkoff?
ה-API של Tinkoff פועל לפי הסכמה Init → Pay → Confirm/Cancel. השיטות העיקריות:
| שיטה | מטרה |
|---|---|
Init |
אתחול תשלום, קבלת PaymentURL ו-PaymentId |
GetState |
קבלת סטטוס עסקה נוכחי |
Confirm |
אישור תשלום שאושר מראש |
Cancel |
ביטול תשלום או החזר כספי |
Charge |
חיוב חוזר באמצעות כרטיס שמור |
כל הבקשות חתומות עם טוקן – SHA-256 של ערכי הפרמטרים המחוברים והסיסמה בסדר אלפביתי של המפתחות. סדר שגוי של יצירת הטוקן הוא הגורם השכיח ביותר לשגיאת INVALID_SIGNATURE בריצה הראשונה.
מדוע התראות קריטיות לעיבוד נכון?
Tinkoff שולח POST ל-NotificationURL על כל שינוי סטטוס. סטטוסים הדורשים פעולות ב-Bitrix:
| סטטוס | משמעות | פעולה ב-Bitrix |
|---|---|---|
| AUTHORIZED | כספים חסומים | לשני שלבים – המתן ל-Confirm |
| CONFIRMED | תשלום אושר | $payment->setPaid('Y') |
| REJECTED | נדחה על ידי הבנק | הודע ללקוח |
| REFUNDED | החזר מלא | עדכן סטטוס הזמנה |
| PARTIAL_REFUNDED | החזר חלקי | עדכן סכום החזר |
| REVERSED | ביטול אישור | בטל תשלום |
ההודעה מכילה Token לאימות חתימה – יש ליישם את הבדיקה. לאחר עיבוד מוצלח, החזר מחרוזת OK, אחרת Tinkoff ינסה שוב. בניגוד למתחרים, ה-API של Tinkoff יציב ומהיר יותר: זמן תגובת השער אינו עולה על 2 שניות, ושיעור השגיאות נמוך ב-30%.
כיצד לשלב את Tinkoff עם מודול המכירות של Bitrix?
ל-Tinkoff יש מודול רשמי ב-Marketplace. לחלופין, handler מותאם אישית ב-/local/php_interface/include/sale_payment/tinkoff_acquiring/. מבנה ה-handler:
-
handler.php– מחלקה ראשית, מרחיבה את ServiceHandler -
.description.php– תיאור ואייקון -
.settings.php– שדות: TerminalKey, Password, TestMode, TwoStagePayment -
template/– תבנית כפתור תשלום
השיטה initiatePay בונה בקשה אל Init:
$request = [
'TerminalKey' => $terminalKey,
'Amount' => $payment->getSum() * 100, // в копейках
'OrderId' => $payment->getOrderId(),
'Description' => 'Заказ №' . $order->getField('ACCOUNT_NUMBER'),
'SuccessURL' => $returnUrl,
'FailURL' => $failUrl,
'NotificationURL' => $notifyUrl,
'Receipt' => $this->buildReceipt($order), // для 54-ФЗ
];לפי תיעוד 1C-Bitrix, ה-handler חייב להרחיב את $request = [ 'TerminalKey' => $terminalKey, 'Amount' => $payment->getSum() * 100, // в копейках 'OrderId' => $payment->getOrderId(), 'Description' => 'Заказ №' . $order->getField('ACCOUNT_NUMBER'), 'SuccessURL' => $returnUrl, 'FailURL' => $failUrl, 'NotificationURL' => $notifyUrl, 'Receipt' => $this->buildReceipt($order), // для 54-ФЗ ]; . אנו מקפידים על ההמלצות.
מדוע תשלומים חוזרים מועילים למנויים?
Tinkoff תומך בקשירת כרטיס בתשלום הראשון (פרמטר SaleHandler ב-Recurrent: Y) ובחיובים הבאים דרך Init ללא מעורבות הלקוח. ב-Bitrix, זה משמש למנויים: כאשר נוצר מנוי, Charge מההודעה נשמר, ולאחר מכן דרך cron נקרא RebillId עם Charge הנדרש. בחירת מצב דו-שלבי מפחיתה את סיכון ה-chargeback ב-20% הודות לאישור מראש. למידע נוסף, ראו את המאמר על תשלומים חוזרים.
כיצד להגדיר פיסקליזציה נכון?
ל-Tinkoff יש קופה רושמת מובנית. על ידי העברת אובייקט Amount בבקשה Receipt, הקופה מייצרת קבלה אוטומטית. מבנה הקבלה:
{
"Email": "[email protected]",
"Phone": "+79001234567",
"Taxation": "osn",
"Items": [
{
"Name": "Название товара",
"Price": 150000,
"Quantity": 2,
"Amount": 300000,
"Tax": "vat20",
"PaymentMethod": "full_payment",
"PaymentObject": "commodity"
}
]
}נתוני הפריט נלקחים מסל הקניות של ההזמנה: Init. עבור כל פריט, יש למפות את שיעור המע"מ מהקטלוג לקוד { "Email": "[email protected]", "Phone": "+79001234567", "Taxation": "osn", "Items": [ { "Name": "Название товара", "Price": 150000, "Quantity": 2, "Amount": 300000, "Tax": "vat20", "PaymentMethod": "full_payment", "PaymentObject": "commodity" } ] } של Tinkoff API ($order->getBasket()->getOrderableItems(), Tax, vat0, vat10). הגדרת פיסקליזציה נכונה חוסכת עד 15% בעמלות על ידי אופטימיזציה של שיעורי המס.
מקרה אמיתי: timeout תחת עומס גבוה
מהניסיון שלנו: מרקט אופנה, כ-500 הזמנות ביום. לקוחות התלוננו מעת לעת שלאחר התשלום הם הגיעו לדף "שגיאה", למרות שהכסף נוכה. אבחון: בעומס שיא, ה-handler של SuccessURL קרא ל-GetState לפני ש-Tinkoff סיים את הרישום – הסטטוס חזר כ-AUTHORIZED במקום CONFIRMED. סטטוס ההזמנה נשאר ללא שינוי, והלקוח ראה שגיאה. פתרון: ב-SuccessURL, הצג דף ביניים "מעבד תשלום" עם סקר סטטוס ב-JS דרך נקודת קצה AJAX מותאמת, ואשר תשלום אך ורק דרך ההודעה. ניסיון זה אפשר לנו להפחית פניות לתמיכה ב-40%.
בדיקות ואחריות
בלוח המסחרי של Tinkoff (merchant.tinkoff.ru), צור טרמינל בדיקה עם TerminalKey נפרד. כרטיסי בדיקה לתרחישים שונים (הצלחה, דחייה, 3DS) נמצאים בתיעוד ה-API. לפני העלייה לאוויר, יש לבדוק: חתימת הודעה, סכום נכון בקופיקות, יצירת Receipt, טיפול בקריאות כפולות. אנו מבטיחים פעולה תקינה של האינטגרציה ומבצעים בדיקות עומס. כל העבודה מגיעה עם אחריות ל-6 חודשים.
מה כלול בעבודה
- קבלת טרמינל ומפתחות מ-Tinkoff
- התקנה והגדרה של המודול (רשמי או מותאם)
- הגדרת NotificationURL וטיפול בסטטוסים
- שילוב פיסקליזציה 54-FZ
- תשלומים חוזרים (אם נדרש)
- בדיקת כל התרחישים עם כרטיסי בדיקה
- תיעוד וגישה לקוד המקור
- תמיכה טכנית לחודש לאחר ההשקה
כיצד מתבצעת העבודה?
| שלב | משך |
|---|---|
| ניתוח דרישות וסיכום | יום אחד |
| הגדרת טרמינל וקבלת גישה | יום אחד |
| פיתוח handler והגדרת התראות | 1–3 ימים |
| בדיקות | יום אחד |
| עלייה לאוויר וניטור | יום אחד |
לוח זמנים: בין 3 ל-6 ימי עסקים בהתאם למורכבות. העלות מחושבת באופן אישי לאחר הערכת הפרויקט. לצוות שלנו ניסיון של 5+ שנים, 100+ פרויקטים, ומומחי 1C-Bitrix מוסמכים. אנו מספקים אחריות עד 6 חודשים ותמיכה לאחר ההשקה. צרו קשר להצעה מסחרית וייעוץ לפרויקט שלכם. הזמינו אינטגרציה עכשיו – נכין פתרון במהירות לעסק שלכם.