Налаштування підписних платежів на 1С-Бітрікс

Налаштування підписних платежів на 1С-Бітрікс

Підписна монетизація — бізнес-логіка поверх рекурентних платежів. У Бітрікс немає нативного модуля підписок, реалізація завжди кастомна. Складність не в самому списанні (воно вирішується за 1–2 дні), а в управлінні життєвим циклом: зміна тарифу, тріальний період, скасування зі збереженням доступу до кінця періоду, retry при невдалому платежі.

Ми розробляємо такі рішення для клієнтів уже більше семи років. За цей час зіткнулися з типовими проблемами: несумісність API платіжних шлюзів, дублювання платежів, втрата даних при збоях cron, складність обробки часткових повернень. Наш досвід показує, що без продуманої архітектури підписний бізнес втрачає до 20% виручки через невдалі списання та відтік клієнтів. Наприклад, при значному середньому чеку та великій кількості активних підписників відтік через помилки білінгу може призводити до суттєвих фінансових втрат. Правильна реалізація рятує ці гроші.

Проблеми, які вирішуємо

Гнучке управління тарифами

Готові модулі часто не підтримують складні сценарії: тріали, фріміум, сімейні плани. Ми створюємо кастомну логіку, адаптовану під ваш бізнес.

Надійний білінг

Планувальник з retry-механізмом мінімізує втрати від невдалих платежів. Кожна спроба логується, при вичерпанні спроб підписка призупиняється, а клієнт отримує сповіщення.

Інтеграція з еквайрингом

Потрібна коректна настройка rebill_id через API Тінькофф, Сбера або ЮKassa. Ми забезпечуємо безшовну передачу токенів і обробку холдів.

Як ми це робимо

Стек: PHP 8.1+, Бітрікс (інфоблоки 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 'RUB',
    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());
    }
}

Як управляти життєвим циклом підписки?

Після успішного списання оновлюються дати періоду та скидається лічильник retry. При відмові в списанні статус переводиться в 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()));
}

Чому кастомна реалізація краща за готові рішення?

Готові модулі (наприклад, з Маркетплейсу) часто обмежені стандартними сценаріями: вони не дозволяють гнучко налаштувати retry, пропорційний білінг або інтеграцію з унікальною CRM. Кастомне рішення дає повний контроль над логікою — ви самі вирішуєте, коли списувати, які сповіщення надсилати, як обробляти повернення. Крім того, ми можемо інтегрувати підписну систему з будь-яким еквайрингом: Тінькофф, Сбер, ЮKassa, АТОЛ.

Кейс: SaaS-платформа, перехід на підписки

Наш клієнт — B2B-сервіс автоматизації звітності на Бітрікс. До цього — одноразові ліцензії. Завдання: перевести клієнтів на щомісячну підписку з автоматичним продовженням. Зробили: три тарифні плани, білінг через Тінькофф з rebill_id, окремий ОС управління підпискою, email-сповіщення за 3 дні до списання, retry через 1/3/7 днів. Інтеграція з системою доступів — через перевірку userHasSubscription() у кожному захищеному компоненті. Результат: відтік клієнтів знизився на 15%, регулярний дохід зріс у 2 рази.

Що входить в роботу

• Аналіз бізнес-вимог та проєктування архітектури.
• Створення БД та моделі даних.
• Розробка API для управління підписками (створення, зміна, скасування).
• Інтеграція з еквайрингом (Тінькофф, Сбер, ЮKassa).
• Налаштування cron-планувальників та retry-логіки.
• Тестування всіх сценаріїв та навантажувальне тестування.
• Документація по API та адмініструванню.
• Навчання ваших розробників.
• Гарантійна підтримка 3 місяці.

Процес роботи

1. Аналітика — обговорюємо тарифну сітку, сценарії підписок, варіанти оплати.
2. Проєктування — створюємо схему БД, API, документацію.
3. Розробка — пишемо код на PHP, версіонуємо через Git.
4. Тестування — unit-тести, інтеграційні сценарії, перевірка на бойових даних.
5. Деплой — налаштування cron, міграції, навантажувальне тестування.
6. Підтримка — моніторинг, доопрацювання, 24/7 на зв'язку.

Терміни орієнтовно

Вартість розраховується індивідуально — залежить від складності інтеграцій та обсягу кастомізації. Зв'яжіться з нами для консультації з архітектури підписок. Замовте розробку підписного модуля під ваші завдання — ми підготуємо комерційну пропозицію з точними термінами.

Як уникнути типових помилок при підключенні платіжних систем на 1С-Бітрікс

Найчастіша помилка при інтеграції — забути про callback. Покупець оплатив замовлення, гроші списалися, а статус у b_sale_order не оновився: менеджер бачить «Очікування оплати» і починає дзвонити клієнту. Причина — неправильний URL у налаштуваннях шлюзу або обробник, що падає з 500 при нестандартній структурі відповіді. Ми пропонуємо послуги з підключення платіжних систем на 1С-Бітрікс з повним тестуванням усіх сценаріїв: успішна оплата, відмова, тайм-аут, часткове повернення, повторний callback.

Чому callback-сповіщення критичні?

Кожен платіжний шлюз надсилає сповіщення на ваш сервер. Якщо обробник не гарантує ідемпотентність — подвійний виклик призведе до подвійного списання. Ми завжди реалізуємо перевірку за ID сповіщення (external_id) та блокування повторної обробки в \Bitrix\Sale\Order. Також критично налаштувати URL callback в особистому кабінеті агрегатора — /bitrix/tools/sale_ps_result.php для штатного модуля. Якщо використовуєте кастомний обробник, перевіряємо, що він віддає HTTP 200 навіть при помилці параметрів (шлюз не повинен повторювати запит нескінченно). Через некоректний callback втрачається до 30% успішних оплат — покупець платить, але статус не оновлюється, і ви не отримуєте гроші.

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';

Як вибрати платіжний агрегатор для 1С-Бітрікс?

Вибір залежить від географії покупців, середнього чека та потреби у розстрочці. Для ринку РФ базовий набір — ЮKassa (усі основні методи, фіскалізація з коробки) та CloudPayments (віджет без редиректу, Apple Pay, Google Pay). Якщо працюєте з великими корпоративними клієнтами — додайте Ощадбанк (SberPay, СБП). Для міжнародних продажів — Stripe або PayPal. Ми часто використовуємо дворівневу схему: основний агрегатор + резервний (автоперемикання при падінні). CloudPayments забезпечує на 15–25% більше успішних оплат за рахунок віджету без редиректу — покупець не йде з сайту.

Які платіжні агрегатори та способи оплати ми використовуємо

ЮKassa

Один договір — всі основні способи: картки Visa/MasterCard/МИР, ЮMoney, SberPay, інтернет-банки, розстрочка. Фіскалізація за 54-ФЗ з коробки (через модуль sale). Штатний обробник /bitrix/modules/sale/handlers/paysystem/yandexpay/ покриває базові сценарії. Для холдування (двостадійна оплата), підписок або спліт-платежів — кастомна інтеграція через API v3. Callback налаштовуємо на /bitrix/tools/sale_ps_result.php, парсимо notification та оновлюємо \Bitrix\Sale\Order через setField('PAYED', 'Y').

CloudPayments

Заточений на конверсію: віджет оплати прямо на сторінці чекауту, без редиректу на зовнішній домен. Покупець не йде з сайту — відсоток відмов на етапі оплати падає. Підтримує рекурентні платежі (токенізація картки через cryptogram), Apple Pay та Google Pay. 3D Secure з інтелектуальною маршрутизацією — запитується лише при високому ризику фроду. Інтеграція з Бітрікс — через REST API CloudPayments та кастомний обробник.

Тинькофф Оплата

API-інтеграція через TinkoffPaymentAPI (готовий модуль або ручна реалізація). QR-код для оплати через додаток, розстрочка «Тинькофф Кредит» — критично для дорогих товарів. Часткові повернення через метод Cancel — без дзвінків у банк, все з адмінки Бітрікс.

Ощадбанк (SberPay та СБП)

SberPay — оплата за push-сповіщенням або QR, СБП — комісія нижча порівняно з картками. На обсязі це відчутна економія. Холдування через API registerPreAuth / deposit. Враховуємо, що для SberPay потрібне підписання окремого договору з банком.

Apple Pay та Google Pay

Оплата в два дотики, без введення даних картки. Підключаються через агрегатор (ЮKassa, CloudPayments, Тинькофф). Важливі нюанси:

• Apple Pay вимагає верифікації домену: файл apple-developer-merchantid-domain-association в /.well-known/. Без нього кнопка не з'явиться.
• Розміщення кнопок строго за гайдлайнами Apple та Google — інакше відмова в рев'ю.
• Фолбек на стандартну форму оплати, якщо пристрій не підтримує безконтактну оплату.

Розстрочка, BNPL та робота з 54-ФЗ

Якщо середній чек великий і конверсія просідає — розстрочка знімає ціновий бар'єр. Ми підключаємо:

• Тинькофф Розстрочка (3–24 місяці)
• Покупай зі Сбером
• Мокка / Долями — BNPL: 4 платежі, 0% для покупця

Інтеграція: віджет з розрахунком щомісячного платежу на картці товару («від суми на місяць»), передача даних замовлення в банк через API, обробка статусів (схвалення, відмова, очікування документів) в обробниках OnSaleStatusOrder.

Фіскалізація за 54-ФЗ — обов'язкова вимога. Штраф за відсутність чека — до значної суми. Відповідно до Федерального закону № 54-ФЗ касовий чек повинен бути надісланий покупцю в електронній формі. Підключаємо АТОЛ Онлайн, Orange Data, Модуль.Каса, Евотер, Штрих-М. Налаштування в Бітрікс — розділ «Каси» в модулі sale:

• Ставка ПДВ, предмет та спосіб розрахунку — помилка в будь-якому полі може призвести до штрафу при перевірці.
• Чеки при передоплаті та частковій оплаті (два чеки: при оплаті та при відвантаженні).
• Чеки повернення при скасуванні через \Bitrix\Sale\Cashbox\Cashbox::addChecks().
• Моніторинг: якщо чек не пішов — алерт менеджеру.

При торгівлі взуттям, одягом, парфумерією обов'язкова передача кодів маркування в чеку. Інтеграція з «Честний ЗНАК», сканування DataMatrix при збірці замовлення, автоматичний вивід з обігу при продажу через \Bitrix\Catalog\Product\Marking.

Супровід платежів: повернення, мультивалютність, безпека

Повернення

Повне та часткове повернення без дзвінків у банк — через API агрегатора (refund / cancel). Чек повернення формується автоматично, оновлюється статус замовлення, перераховується сума, сповіщається покупець. Строки: електронні гаманці та СБП — 1–3 дні, банківська картка — до 30 робочих днів (залежить від банку-емітента).

Мультивалютність

Типи цін у b_catalog_price для кожної валюти, курси через API ЦБ (\Bitrix\Currency\CurrencyManager::updateCBRFRates()) або ручне введення. Конвертація на рівні каталогу — покупець бачить ціни у своїй валюті. Для прийому доларів/євро підключаємо Stripe, PayPal. Враховуємо комісії за конвертацію при розрахунку маржинальності.

Безпека

Дані карток обробляються на стороні сертифікованого шлюзу (PCI DSS) — номер картки ніколи не проходить через ваш сервер. Антифрод на рівні агрегатора. Логування всіх подій у b_sale_order_change для аудиту. Моніторинг аномалій: стрибок транзакцій, нетипова географія — алерт.

Як ми працюємо та які орієнтовні терміни?

1. Аналіз — які способи оплати потрібні, ринки, обсяг транзакцій, поточний агрегатор.
2. Підбір рішень — іноді два агрегатори краще одного: ЮKassa як основний, CloudPayments як резерв — при падінні одного трафік іде на другий.
3. Інтеграція — тестуємо кожен сценарій: успішна оплата, відмова 3DS, тайм-аут шлюзу, подвійний callback, часткове повернення.
4. Фіскалізація — онлайн-каса, перевірка коректності чеків на тестових замовленнях.
5. Моніторинг — алерти при збоях шлюзу, дашборд конверсії на етапі оплати.

Як підібрати оптимальний платіжний агрегатор?

Вибір агрегатора залежить від специфіки бізнесу: обсягу продажів, географії клієнтів, необхідності у розстрочці або рекурентних платежах. Ми допомагаємо проаналізувати ваші потреби та обрати найкраще рішення. Маємо понад 7 років досвіду в інтеграції платіжних систем на Бітрікс, реалізували більше 50 проектів. Замовте консультацію — ми розповімо про плюси та мінуси кожного варіанту.

Що входить в роботу

• Повне налаштування вибраних платіжних систем в 1С-Бітрікс: модулі, обробники, callback, тестування.
• Документація з інтеграції (схема роботи шлюзів, опис обробників, логи).
• Навчання вашого менеджера роботі з платіжними модулями та поверненнями.
• Технічна підтримка на етапі запуску та перші 2 тижні експлуатації.
• Моніторинг — налаштовуємо алерти на помилки та падіння конверсії.

Всі роботи виконуються сертифікованими розробниками 1С-Бітрікс. Гарантуємо працездатність кожного сценарію. Для швидкої оцінки вашого проекту залиште заявку на сайті або зв'яжіться з нами — підберемо оптимальне рішення для вашого бізнесу.