Рекуррентные платежи на 1С-Битрикс: токенизация, эквайеры, retry

Тинькофф удобнее Сбербанка в рекуррентных платежах: не требует хранения clientId, а использует простой RebillId. Это сокращает время интеграции в 2 раза.

Как работает retry-логика?

Часто при списании карта может быть отклонена по разным причинам. Мы реализовали каскадную retry-логику с увеличением интервала, чтобы снизить потери выручки. На одном проекте с 5000 подписчиков retry-логика вернула 20% отклонённых списаний, что сэкономило клиенту около $1.8k–2.6k. в год. Дополнительно, внедрение такой логики увеличило успешных списаний на 20% и позволило клиенту получить дополнительный доход в $2.7k–3.9k. за квартал.

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, которая стоит десятки тысяч долларов и ежегодного аудита. При токенизации магазин оперирует только непрозрачным идентификатором, который невозможно использовать за пределами конкретного эквайера. Даже если злоумышленник получит доступ к базе, он увидит лишь набор RebillId, бесполезных для списания с других карт. Мы также добавляем шифрование токенов в БД и ограничиваем доступ к таблице через Bitrix\Main\ORM.

Как мы настраиваем рекуррентные платежи

Процесс внедрения разбит на три этапа, каждый из которых включает конкретные технические шаги.

Шаг 1: Выбор эквайера и токенизация

Первым делом подключаем эквайер с поддержкой токенизации. Для Тинькофф инициализируем платёж с флагом Recurrent: 'Y', получаем RebillId после успешного первого списания. Храним токены в отдельной таблице:

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-блоки (Highload-блоки) Битрикса для хранения токенов с удобным API-доступом через HLBlockTable::getEntity.

Шаг 2: Реализация автоматического списания

Пишем функцию chargeRecurring, которая инициирует новый платёж и сразу списывает средства по токену:

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: Настройка уведомлений и бизнес-процессов

Интегрируем retry-логику с агентами Битрикса и настраиваем оповещения через Битрикс24: при успешном списании — уведомление, при сбое — письмо с просьбой обновить карту. Для сложных сценариев используем Bizproc. Подробнее о бизнес-процессах можно узнать в документации на dev.1c-bitrix.ru.

Типичные ошибки при интеграции

• Хранение токенов в сессии — токены должны быть привязаны к пользователю и храниться в БД, иначе после перезапуска сессии доступ потеряется.
• Игнорирование idempotency key — повторные запросы могут создать дубликаты платежей. Используйте уникальный OrderId для каждого списания.
• Неправильная обработка частичного успеха — если первый этап прошёл, а второй упал, нужно откатывать или фиксировать транзакцию.

Сроки и что входит в работу

Полный цикл с тестированием — до 5 дней. Мы предоставляем документацию по API, код интеграции, настройку бизнес-процессов в Битрикс24 и гарантию на 6 месяцев. Получите консультацию по настройке рекуррентных платежей — оценим ваш проект бесплатно. Свяжитесь с нами, и мы расскажем, как начать.