Рекуррентные платежи и подписки: токены, off-session, ретраи

Рекуррентные платежи и подписки: токены, off-session, ретраи

Рекуррентные платежи по API — это надёжный способ автоматизировать регулярные списания за сервисы, подписки, рассрочки и пожертвования. Ниже разобраны ключевые понятия: токенизация для рекуррентных списаний, off-session списание без участия плательщика, ретраи биллинга и dunning-стратегии, уведомления и миграция токенов.

Что такое рекуррентные платежи и чем они отличаются от подписок

• Рекуррентный платеж — повторяющееся списание с сохранённого способа оплаты без повторного ввода данных. Это может быть фиксированная сумма (абонентка) или переменная (metered/usage‑based).
• Подписка — бизнес‑правило над рекуррентными платежами: планы, периоды, пробный период, пауза, автопродление, уведомления и ретраи.

Через наше рекуррентные платежи API вы управляете как отдельными повторными списаниями (разово на основе сохранённого токена), так и полноценной подпиской API (создание планов, привязка клиентов, биллинг по расписанию и пр.). См. также страницы: Приём платежей API и Документация API.

Модели рекуррентного биллинга

• Фиксированная подписка: одна сумма каждые N дней/месяцев/год.
• Usage‑based (по потреблению): сумма зависит от объёма (минуты, гигабайты, пользователи). Возможен биллинг по итогам периода.
• Tiered (ступенчатая): стоимость зависит от диапазонов использования.
• Предоплата/кошелёк: пополнение баланса с автосписанием при падении ниже порога.
• Триал и grace‑периоды: бесплатный период или отсрочка отключения сервиса.

Рекомендуем заранее спроектировать модель, чтобы корректно настроить off-session списания и фискализацию чеков по 54‑ФЗ — подробнее см. Фискализация 54‑ФЗ.

Токены карт и оплата в один клик: как это работает

Токен — это безопасный идентификатор сохранённой карты. Хранение реквизитов выполняется в защищённом хранилище провайдера, соответствующем PCI DSS, поэтому вашему бэкенду не нужно обрабатывать PAN/CVV.

Ключевые преимущества токенизации для рекуррентных:

• Безопасность: соответствие PCI DSS.
• Конверсия: «оплата в один клик» для on‑session и автоматические списания off‑session.
• Обновление реквизитов: автоматический апдейтер карт (если доступно), снижающий отказы из‑за истечения срока.

Как создать токен карты

1. Клиент вводит данные в защищённой форме/SDK (поля подгружаются с нашей стороны — ваш сервер не видит PAN/CVV). См. Методы оплаты и Mobile SDK.
2. Мы проводим токенизацию рекуррентные: формируем token_id, который вы сохраняете у себя.
3. При необходимости выполняется первоначальная проверка и привязка с 3‑D Secure (setup/zero‑auth).
4. Токен привязывается к клиенту, и вы можете запускать off-session списание.

Полезные ссылки: Быстрый старт интеграции, Документация API, Безопасность PCI DSS.

Off-session списание и 3‑D Secure: лучшие практики

Off-session списание — автоматический платеж без присутствия плательщика в момент списания (MIT — Merchant Initiated Transaction). Это ключ к бесшовным подпискам.

Рекомендованный алгоритм:

• На этапе привязки карты сформировать «мандат» на будущие списания: сообщить сумму/периодичность/условия подписки.
• Выполнить initial 3‑DS (challenge или frictionless) при сохранении способа оплаты.
• При наступлении срока списания провести off‑session транзакцию. Если банк требует подтверждение — отправить ссылку на on‑session подтверждение (fallback) через уведомление.

Сравнение сценариев инициирования:

Инициатор	Сценарий	Примеры
CIT (Customer‑Initiated)	Клиент присутствует и подтверждает платеж	Первая оплата, on‑session продление с кнопкой «Оплатить»
MIT (Merchant‑Initiated)	Клиента нет, списание по мандату	Автопродление подписки, списание за перерасход

Для стабильности конверсии используйте оповещения о предстоящем списании, возможность изменить карту и гибкий fallback‑процесс. События и статусы интегрируйте через Вебхуки и события.

Ретраи биллинга и dunning‑стратегия

Ретраи биллинга — повторные попытки списания после отказа (insufficient funds, временные лимиты, SCA и т. п.). Dunning‑стратегия — коммуникации и события вокруг ретраев: письма, SMS, push‑уведомления, пауза/блокировка сервиса.

Рекомендованный базовый график ретраев (пример):

Попытка	Когда	Что отправить клиенту
1	В день списания	Уведомление об оплате: успешно/ошибка
2	+1 день	Письмо/пуш со ссылкой «Обновить карту», on‑session подтверждение
3	+3 дня	Повтор off‑session утром (в «богатые» часы)
4	+7 дней	Последнее напоминание, предупреждение о паузе
5	+14 дней	Финальный ретрай и переход в paused/canceled

Советы:

• Коммуницируйте ценность: что клиент теряет при неуспешном платеже.
• Меняйте время суток ретраев под BIN‑регион и поведение банка‑эмитента.
• Предлагайте альтернативные методы оплаты при повторных отказах.

Все «уведомления об оплате» (ошибка, предстоящий дебет, успешный ретрай) связаны с событиями API — подключите Вебхуки и события и аналитические Отчёты и выгрузки.

Уведомления и вебхуки: контроль жизненного цикла платежа

Рекомендуемые события для подписок и рекуррентных:

• invoice.created / invoice.upcoming — создан счёт или скоро спишем.
• charge.succeeded / charge.failed — оплата прошла/не прошла.
• charge.retried — удачный ретрай.
• subscription.paused / subscription.canceled — изменение статуса подписки.
• payment.action_required — нужен on‑session шаг (3‑DS).

Подробности форматов и подписей запросов — в разделе Вебхуки и события. Для отказоустойчивости используйте очереди, повторные доставки и идемпотентность запросов.

Миграция токенов и перенос карт без потери конверсии

Если вы переезжаете с другого провайдера или хотите консолидацию хранилища карт, доступна миграция токенов:

• Провайдер‑to‑провайдер: защищённый обмен токенами между токен‑волтами (по согласованию). PCI DSS остаётся на стороне провайдеров.
• Сетевые токены (Visa/Mastercard/MIR): снижение отказов за счёт автоматического обновления реквизитов.
• Поэтапный re‑collect: мягкий сбор карт у активных клиентов с «оплатой в один клик» и промо‑триггерами.

Обсудите план, SLA и сроки с командой поддержки — см. SLA и поддержка и требования безопасности в Безопасность PCI DSS.

Управление подписками через API

Подписка API предоставляет методы для полного жизненного цикла:

• Создание плана (цена, период, пробный период, налоги, фискальные признаки).
• Привязка клиента и способа оплаты (создать токен карты, подтверждение 3‑DS при необходимости).
• Смена плана, апгрейд/даунгрейд, прайорейшн (перерасчёт пропорций периода).
• Пауза/возобновление, отмена в конце периода, мгновенная отмена.
• Инвойсы и чеки — см. Фискализация 54‑ФЗ.
• Возвраты и частичные сторно — см. Возвраты и отмены.

Советы по интеграции:

• Используйте идемпотентные ключи при создании инвойсов и ретраях.
• Отражайте статусы в вашей CRM/БД на основе вебхуков.
• Планируйте биллинг по часовым поясам клиента.

Начните с Быстрого старта интеграции и полной Документации API. Общие сценарии оплаты — в разделе Приём платежей API.

Антифрод и риск‑контроль при рекуррентных платежах

Рекуррентный биллинг снижает риск за счёт раннего 3‑DS при привязке, но требует постоянного мониторинга:

• Маркируйте транзакции корректно как MIT/CIT.
• Включайте поведенческие правила и velocity‑лимиты.
• Используйте списки доверенных клиентов и BIN‑фильтры.
• Логируйте и анализируйте неуспехи: do not honor, insufficient funds, expired card и т. п.

Подробнее о правилах и скоринге — в разделе Антифрод и риск.

Тестирование и быстрый старт

Протестируйте все ветки: успешные дебеты, off-session с требованием 3‑DS, ретраи, отмены и возвраты.

• Воспользуйтесь Песочницей и тестированием.
• Следуйте гайдам из Быстрого старта интеграции.
• Проверьте генерацию чеков (54‑ФЗ) и корректность позиций — см. Фискализация 54‑ФЗ.

Mobile и CMS: сохранённые карты в приложениях и магазинах

• Mobile SDK: нативная токенизация и 3‑DS, «оплата в один клик» и сохранение карты для будущих списаний — см. Mobile SDK.
• CMS‑плагины: готовые модули с рекуррентным биллингом для популярных CMS/Shop — см. CMS‑плагины.

Тарифы, фискализация и выплаты

• Комиссии и стоимость эквайринга, включая рекуррентные — см. Тарифы и комиссии.
• Выплаты продавцам и график вывода средств — см. Выплаты и вывод средств.
• Чеки по каждому списанию, коррекции, авансы — см. Фискализация 54‑ФЗ.

Чек‑лист внедрения

• Определите модель подписки и циклы биллинга.
• Настройте создание токенов (создать токен карты) и первичную 3‑DS привязку.
• Реализуйте off-session списание и fallback на on‑session подтверждение.
• Спроектируйте ретраи биллинга и dunning стратегию (уведомления об оплате, письма/SMS/push).
• Подключите вебхуки, логи и идемпотентность — см. Вебхуки и события.
• Проведите тесты в песочнице — см. Песочница и тестирование.
• Проверьте фискализацию и возвраты — Фискализация 54‑ФЗ, Возвраты и отмены.
• Включите антифрод‑правила — Антифрод и риск.

Выводы и следующий шаг

Рекуррентные платежи API и подписка API позволяют повысить LTV, снизить отток и автоматизировать всё — от токенизации до ретраев и уведомлений. Настройте безопасные токены, off-session списание и продуманную dunning‑стратегию, чтобы поддерживать высокую конверсию и предсказуемый денежный поток.

Готовы запустить рекуррентные? Начните с Быстрого старта интеграции, изучите Документацию API и свяжитесь с нами через SLA и поддержку. Мы поможем спроектировать архитектуру, миграцию токенов и оптимальные ретраи под ваш бизнес.