הגדרת תשלומי מנוי ב-1C-Bitrix

הגדרת תשלומי מנוי ב-1C-Bitrix

מונטיזציה של מנויים היא לוגיקה עסקית השכבה על גבי תשלומים חוזרים. ל-Bitrix אין מודול מנויים מובנה—היישום הוא תמיד מותאם אישית. המורכבות אינה בחיוב עצמו (זה נפתר ב-1–2 ימים), אלא בניהול מחזור החיים: מעבר בין תוכניות, תקופות ניסיון, ביטול עם גישה עד סוף התקופה, וניסיונות חוזרים בתשלומים שנכשלו.

אנחנו בונים פתרונות כאלה ללקוחות כבר למעלה משבע שנים. לאורך הדרך נתקלנו בבעיות טיפוסיות: אי-תאימות API של שערי תשלום, חיובים כפולים, אובדן נתונים בזמן כשלי cron, ומורכבות בטיפול בהחזרים חלקיים. הניסיון שלנו מראה שבלי ארכיטקטורה מחושבת היטב, עסקי מנויים מאבדים עד 20% מההכנסות עקב חיובים שנכשלים ונטישת לקוחות. לדוגמה, נטישה כתוצאה משגיאות חיוב יכולה להוביל לאובדן הכנסות משמעותי. יישום נכון מונע זאת.

בעיות שאנחנו פותרים

ניהול תעריפים גמיש

מודולים מוכנים לרוב אינם תומכים בתרחישים מורכבים כמו ניסיון, freemium, או תוכניות משפחתיות. אנחנו יוצרים לוגיקה מותאמת אישית לעסק שלך.

חיוב אמין

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

שילוב שער תשלום

נדרשת הגדרה נכונה של rebill_id דרך APIs של Tinkoff, Sber, או YooKassa. אנחנו מבטיחים העברת token חלקה וטיפול ב-hold.

איך אנחנו עושים את זה

טכנולוגיות: PHP 8.1+, Bitrix (infoblocks v2.0, ORM), MariaDB, cron, REST API. אנחנו משתמשים בטבלאות נפרדות לתעריפים ומנויים (ראה מבנה למטה). מטמון מתויג—המטמון מתנקה כשמנוי משתנה. כל הפעולות הקריטיות עטופות בטרנזקציות.

CREATE TABLE b_subscription_plans ( id SERIAL PRIMARY KEY, code VARCHAR(32) UNIQUE NOT NULL, name VARCHAR(128), price DECIMAL(10,2), currency CHAR(3) DEFAULT 'USD', period_days INT NOT NULL, trial_days INT DEFAULT 0, is_active BOOLEAN DEFAULT TRUE ); CREATE TABLE b_user_subscriptions ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, plan_id INT REFERENCES b_subscription_plans(id), rebill_id VARCHAR(128), status VARCHAR(16) DEFAULT 'trialing', trial_ends_at TIMESTAMP, period_start TIMESTAMP, period_end TIMESTAMP, cancel_at_period_end BOOLEAN DEFAULT FALSE, retry_count INT DEFAULT 0, last_payment_at TIMESTAMP, created_at TIMESTAMP DEFAULT NOW() ); 

סטטוסים: trialing → active → past_due → paused / cancelled / expired. דוגמת קוד למתזמן חיוב:

// /local/cron/subscription_billing.php // Cron: 0 9 * * * php /var/www/shop/local/cron/subscription_billing.php define('NO_KEEP_STATISTIC', true); require $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; $db = Bitrix\Main\Application::getConnection(); $due = $db->query(" SELECT s.id, s.user_id, s.rebill_id, p.price, p.currency, p.period_days, u.EMAIL FROM b_user_subscriptions s JOIN b_subscription_plans p ON p.id = s.plan_id JOIN b_users u ON u.ID = s.user_id WHERE s.status = 'active' AND s.cancel_at_period_end = FALSE AND DATE(s.period_end) = CURRENT_DATE "); while ($row = $due->fetch()) { try { $success = chargeRebill($row['rebill_id'], $row['price'], $row['currency']); if ($success) { $db->query("UPDATE b_user_subscriptions SET period_start = period_end, period_end = period_end + INTERVAL '" . (int)$row['period_days'] . " days', retry_count = 0, last_payment_at = NOW() WHERE id = " . (int)$row['id']); createBitrixOrderForSubscription($row); } else { $db->query("UPDATE b_user_subscriptions SET status = 'past_due', retry_count = retry_count + 1 WHERE id = " . (int)$row['id']); sendPaymentFailedNotification($row['EMAIL']); } } catch (\Exception $e) { logError('billing', $row['id'], $e->getMessage()); } } 

איך לנהל את מחזור החיים של המנוי?

לאחר חיוב מוצלח, תאריכי התקופה מתעדכנים ומונה הניסיונות החוזרים מתאפס. אם החיוב נכשל, הסטטוס משתנה ל-past_due, מה שמפעיל שרשרת ניסיונות חוזרים. אם לקוח מבטל, אנחנו שומרים על גישה עד סוף התקופה ששולמה (cancel_at_period_end = TRUE). המתזמן לא ייצור תשלום חדש עבור מנוי כזה.

דוגמת פונקציה לבדיקת מנוי פעיל:

function userHasSubscription(int $userId, string $planCode = null): bool { $db = Bitrix\Main\Application::getConnection(); $sql = "SELECT COUNT(1) FROM b_user_subscriptions s JOIN b_subscription_plans p ON p.id = s.plan_id WHERE s.user_id = " . (int)$userId . " AND s.status IN ('active', 'trialing') AND s.period_end > NOW()"; if ($planCode) { $sql .= " AND p.code = '" . $db->getSqlHelper()->forSql($planCode) . "'"; } return (int)$db->queryScalar($sql) > 0; } // В шаблоне закрытого раздела if (!userHasSubscription($USER->GetID(), 'premium')) { LocalRedirect('/subscribe/?redirect=' . urlencode($APPLICATION->GetCurPage())); } 

למה יישום מותאם אישית על פני מוכן?

מודולים מוכנים מה-Marketplace מוגבלים לרוב לתרחישים סטנדרטיים: הם לא מאפשרים ניסיונות חוזרים גמישים, חיוב יחסי (prorated), או שילוב עם CRM ייחודי. פתרון מותאם אישית נותן לך שליטה מלאה—אתה מחליט מתי לחייב, אילו הודעות לשלוח, ואיך לטפל בהחזרים. יתר על כן, אנחנו יכולים לשלב את מערכת המנויים עם כל סולק: Tinkoff, Sber, YooKassa, ATOL.

מקרה בוחן: מעבר פלטפורמת SaaS למנויים

הלקוח שלנו—שירות אוטומציית דוחות B2B על Bitrix. בעבר הם מכרו רישיונות חד-פעמיים. משימה: להעביר לקוחות למנויים חודשיים עם חידוש אוטומטי. יישמנו שלוש תוכניות תעריף, חיוב דרך Tinkoff עם rebill_id, ממשק ניהול מנויים נפרד, הודעות אימייל 3 ימים לפני חיוב, וניסיונות חוזרים אחרי 1/3/7 ימים. שילוב עם מערכת הגישה באמצעות בדיקת userHasSubscription() בכל רכיב מוגן. תוצאה: נטישת לקוחות ירדה ב-15%, הכנסות חוזרות הוכפלו.

מה כלול

• ניתוח דרישות עסקיות ועיצוב ארכיטקטורה.
• יצירת מסד נתונים ומודל נתונים.
• פיתוח API לניהול מנויים (יצירה, שינוי, ביטול).
• שילוב שער תשלום (Tinkoff, Sber, YooKassa).
• הגדרת מתזמן cron ולוגיקת ניסיונות חוזרים.
• בדיקת כל התרחישים ובדיקות עומס.
• תיעוד API וניהול.
• הדרכה למפתחים שלך.
• תמיכה באחריות ל-3 חודשים.

התהליך שלנו

1. ניתוח — דיון בטבלת תעריפים, תרחישי מנוי, אפשרויות תשלום.
2. עיצוב — יצירת סכמת מסד נתונים, API, תיעוד.
3. פיתוח — קוד ב-PHP, ניהול גרסאות דרך Git.
4. בדיקות — בדיקות יחידה, תרחישי אינטגרציה, אימות נתונים אמיתיים.
5. פריסה — הגדרת cron, מיגרציות, בדיקות עומס.
6. תמיכה — ניטור, שיפורים, זמינות 24/7.

לוחות זמנים משוערים

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