Рекуррентные платежи и подписки: токены, off-session, ретраи
Рекуррентные платежи по API — это надёжный способ автоматизировать регулярные списания за сервисы, подписки, рассрочки и пожертвования. Ниже разобраны ключевые понятия: токенизация для рекуррентных списаний, off-session списание без участия плательщика, ретраи биллинга и dunning-стратегии, уведомления и миграция токенов.
Table of contents
- Что такое рекуррентные платежи и чем они отличаются от подписок
- Модели рекуррентного биллинга
- Токены карт и оплата в один клик: как это работает
- Off-session списание и 3‑D Secure: лучшие практики
- Ретраи биллинга и dunning‑стратегия
- Уведомления и вебхуки: контроль жизненного цикла платежа
- Миграция токенов и перенос карт без потери конверсии
- Управление подписками через API
- Антифрод и риск‑контроль при рекуррентных платежах
- Тестирование и быстрый старт
- Mobile и CMS: сохранённые карты в приложениях и магазинах
- Тарифы, фискализация и выплаты
- Чек‑лист внедрения
- Выводы и следующий шаг
Что такое рекуррентные платежи и чем они отличаются от подписок
- Рекуррентный платеж — повторяющееся списание с сохранённого способа оплаты без повторного ввода данных. Это может быть фиксированная сумма (абонентка) или переменная (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.
- Обновление реквизитов: автоматический апдейтер карт (если доступно), снижающий отказы из‑за истечения срока.
Как создать токен карты
- Клиент вводит данные в защищённой форме/SDK (поля подгружаются с нашей стороны — ваш сервер не видит PAN/CVV). См. Методы оплаты и Mobile SDK.
- Мы проводим токенизацию рекуррентные: формируем token_id, который вы сохраняете у себя.
- При необходимости выполняется первоначальная проверка и привязка с 3‑D Secure (setup/zero‑auth).
- Токен привязывается к клиенту, и вы можете запускать 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, ретраи, отмены и возвраты.
Mobile и CMS: сохранённые карты в приложениях и магазинах
- Mobile SDK: нативная токенизация и 3‑DS, «оплата в один клик» и сохранение карты для будущих списаний — см. Mobile SDK.
- CMS‑плагины: готовые модули с рекуррентным биллингом для популярных CMS/Shop — см. CMS‑плагины.
Тарифы, фискализация и выплаты
Чек‑лист внедрения
- Определите модель подписки и циклы биллинга.
- Настройте создание токенов (создать токен карты) и первичную 3‑DS привязку.
- Реализуйте off-session списание и fallback на on‑session подтверждение.
- Спроектируйте ретраи биллинга и dunning стратегию (уведомления об оплате, письма/SMS/push).
- Подключите вебхуки, логи и идемпотентность — см. Вебхуки и события.
- Проведите тесты в песочнице — см. Песочница и тестирование.
- Проверьте фискализацию и возвраты — Фискализация 54‑ФЗ, Возвраты и отмены.
- Включите антифрод‑правила — Антифрод и риск.
Выводы и следующий шаг
Рекуррентные платежи API и подписка API позволяют повысить LTV, снизить отток и автоматизировать всё — от токенизации до ретраев и уведомлений. Настройте безопасные токены, off-session списание и продуманную dunning‑стратегию, чтобы поддерживать высокую конверсию и предсказуемый денежный поток.
Готовы запустить рекуррентные? Начните с Быстрого старта интеграции, изучите Документацию API и свяжитесь с нами через SLA и поддержку. Мы поможем спроектировать архитектуру, миграцию токенов и оптимальные ретраи под ваш бизнес.