אתם משיקים שירות מנויים על 1C-Bitrix — ומיד נתקלים בבעיה: איך לחייב כרטיס של לקוח ללא מעורבותו? לפי הסטטיסטיקה, עד 30% מהחיובים החוזרים נדחים מסיבות שונות: חריגה ממסגרת האשראי, תקלה טכנית בבנק, כרטיס חסום. נתקלנו במשימה הזו עשרות פעמים ופיתחנו גישה מוכחת. הנקודה הקריטית שרבים מפספסים: נתוני הכרטיס (מספר, CVV) לעולם לא נשמרים על השרת של החנות. החנות שומרת רק טוקן — מזהה אטום שהונפק על ידי סולק. אנחנו מומחי Bitrix מוסמכים עם ניסיון של שנים והטמענו חיובים חוזרים ביותר מ-40 פרויקטים. הזמינו התקנת חיובים חוזרים במפתח מלא — נשלב עם כל סולק תוך 3–5 ימים.
מדוע חיובים חוזרים ב-1C-Bitrix דורשים טוקניזציה?
טוקניזציה היא מנגנון שבו התשלום הראשון מפעיל שמירה של נתוני התשלום אצל הבנק, והחנות מקבלת מזהה ייחודי (RebillId, payment_method_id). המזהה הזה מקושר לכרטיס במערכת הבנק. החנות אף פעם לא רואה את הכרטיס עצמו — היא שומרת רק טוקן, מה שמבטל לחלוטין את דרישות PCI DSS. כפי שנאמר בויקיפדיה, טוקניזציה מחליפה נתונים רגישים במקבילים הדיגיטליים שלהם.
השוואת סולקים (לחצו להרחבה)
| סולק | דגל תשלום ראשון | שיטת חיוב חוזר |
|---|---|---|
| Tinkoff | Recurrent: 'Y' |
POST /v2/Charge + RebillId |
| YooKassa | save_payment_method: true |
POST /payments + payment_method_id |
| CloudPayments | createToken: true |
POST /payments/tokens/charge |
| Sberbank | clientId ב-Init |
paymentOrderBinding.do |
Tinkoff נוח יותר מ-Sberbank לחיובים חוזרים: הוא לא דורש שמירה של clientId, אלא משתמש ב-RebillId פשוט. זה מקצר את זמן האינטגרציה בחצי.
איך פועלת לוגיקת הניסיונות החוזרים?
לעתים קרובות כרטיס עלול להידחות מסיבות שונות. הטמענו לוגיקת ניסיונות חוזרים מדורגת עם מרווחים הולכים וגדלים כדי להפחית אובדן הכנסות. בפרויקט אחד עם 5000 מנויים, לוגיקת הניסיונות החוזרים שחזרה 20% מהחיובים שנכשלו, מה שהפחית משמעותית את העלויות השנתיות. בנוסף, הכנסת הלוגיקה הזו הגדילה את החיובים המוצלחים ב-20% ויצרה הכנסה נוספת משמעותית.
foreach (getFailedCharges() as $sub) { // Повторяем через 1, 3, 7 дней $delays = [1, 3, 7]; $delay = $delays[$sub['retry_count']] ?? 7; if (daysSinceLastAttempt($sub) < $delay) continue; if ($sub['retry_count'] >= 3) { suspendSubscription($sub['id']); sendSuspendedEmail($sub['user_id']); continue; } $success = chargeRecurring($sub['customer_key'], $sub['amount'], generateOrderId()); updateRetryCount($sub['id'], $success); } מדוע טוקניזציה היא חובה לאבטחה?
ללא טוקניזציה, הייתם צריכים לאחסן מספרי כרטיסים וקודי CVV על השרת שלכם. זה דורש הסמכת PCI DSS, שעולה עשרות אלפי דולרים בתוספת ביקורות שנתיות. עם טוקניזציה, החנות מתמודדת רק עם מזהה אטום שלא ניתן לשימוש מחוץ לסולק הספציפי. גם אם תוקף יקבל גישה למסד הנתונים, הוא יראה רק קבוצה של foreach (getFailedCharges() as $sub) { // Повторяем через 1, 3, 7 дней $delays = [1, 3, 7]; $delay = $delays[$sub['retry_count']] ?? 7; if (daysSinceLastAttempt($sub) < $delay) continue; if ($sub['retry_count'] >= 3) { suspendSubscription($sub['id']); sendSuspendedEmail($sub['user_id']); continue; } $success = chargeRecurring($sub['customer_key'], $sub['amount'], generateOrderId()); updateRetryCount($sub['id'], $success); } , חסרי תועלת לחיוב כרטיסים אחרים. אנחנו גם מצפינים טוקנים במסד הנתונים ומגבילים גישה לטבלאות באמצעות RebillId.
איך אנחנו מתקינים חיובים חוזרים
תהליך ההטמעה מחולק לשלושה שלבים, כל אחד עם צעדים טכניים ספציפיים.
שלב 1: בחירת סולק וטוקניזציה
ראשית, אנחנו מחברים סולק שתומך בטוקניזציה. עבור Tinkoff, אנחנו מאתחלים תשלום עם הדגל Bitrix\Main\ORM, ומקבלים את ה-Recurrent: 'Y' לאחר חיוב ראשון מוצלח. אנו שומרים טוקנים בטבלה נפרדת:
CREATE TABLE b_user_payment_tokens ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, paysystem VARCHAR(32) NOT NULL, rebill_id VARCHAR(128) NOT NULL, card_mask VARCHAR(20), card_type VARCHAR(10), created_at TIMESTAMP DEFAULT NOW(), is_active BOOLEAN DEFAULT TRUE ); לחלופין, השתמשו ב-HL-blocks של Bitrix (Highload-blocks) לאחסון טוקנים עם גישה נוחה ל-API דרך RebillId.
שלב 2: הטמעת חיוב אוטומטי
כתבו את הפונקציה CREATE TABLE b_user_payment_tokens ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, paysystem VARCHAR(32) NOT NULL, rebill_id VARCHAR(128) NOT NULL, card_mask VARCHAR(20), card_type VARCHAR(10), created_at TIMESTAMP DEFAULT NOW(), is_active BOOLEAN DEFAULT TRUE ); שמתחילה תשלום חדש ומחייבת מיד כספים לפי טוקן:
function chargeRecurring(string $customerKey, int $amountKopecks, string $newOrderId): bool { $rebillId = getRebillId($customerKey, 'tinkoff'); // Шаг 1: инициализируем новый платёж $init = tinkoffPost('/v2/Init', [ 'TerminalKey' => TINKOFF_TERMINAL, 'Amount' => $amountKopecks, 'OrderId' => $newOrderId, 'CustomerKey' => $customerKey, 'Recurrent' => 'Y', 'Token' => tinkoffSign([...], TINKOFF_SECRET), ]); // Шаг 2: списываем по RebillId $charge = tinkoffPost('/v2/Charge', [ 'TerminalKey' => TINKOFF_TERMINAL, 'PaymentId' => $init['PaymentId'], 'RebillId' => $rebillId, 'Token' => tinkoffSign([...], TINKOFF_SECRET), ]); return $charge['Success'] ?? false; } שלב 3: הגדרת התראות ותהליכים עסקיים
שלבו לוגיקת ניסיונות חוזרים עם סוכני Bitrix והגדירו התראות דרך Bitrix24: על חיוב מוצלח — התראה, על כישלון — אימייל המבקש עדכון כרטיס. לתרחישים מורכבים, השתמשו ב-Bizproc. פרטים נוספים על תהליכים עסקיים ניתן למצוא בתיעוד בdev.1c-bitrix.ru.
טעויות אינטגרציה נפוצות
- אחסון טוקנים בסשן — טוקנים חייבים להיות מקושרים למשתמש ולשמורים במסד הנתונים, אחרת הגישה תאבד לאחר איפוס סשן.
-
התעלמות ממפתח אידמפוטנטיות — בקשות חוזרות יכולות ליצור חיובים כפולים. השתמשו ב-
HLBlockTable::getEntityייחודי לכל חיוב. - טיפול שגוי בהצלחה חלקית — אם השלב הראשון הצליח אך השני נכשל, יש לבצע גלגול לאחור או לתקן את העסקה.
לוחות זמנים ומה כלול
| משימה | משך זמן |
|---|---|
| תשלום ראשון עם טוקניזציה | יום אחד |
| חיוב אוטומטי + אחסון טוקנים | 1–2 ימים |
| לוגיקת ניסיונות חוזרים והתראות | 0.5–1 יום |
| לוח ניהול כרטיסים | 1–2 ימים |
מחזור מלא עם בדיקות — עד 5 ימים. אנו מספקים תיעוד API, קוד אינטגרציה, הגדרת תהליכים עסקיים ב-Bitrix24, ואחריות ל-6 חודשים. קבלו ייעוץ על התקנת חיובים חוזרים — נעריך את הפרויקט שלכם בחינם. צרו קשר, ונספר לכם איך להתחיל.