01
План оплаты следует условиям абонемента
Сотрудник создаёт план для конкретного абонемента и указывает плательщика, сумму, периодичность, дату начала, день списания и срок действия. Для семейного профиля ребёнок остаётся получателем услуги, а родитель становится плательщиком. Начисление получает собственный срок, сумму, оплаченный остаток и версию, поэтому финансовая история сохраняется при изменении будущих условий.
В плане задаются пауза, перерасчёт и политика возврата задолженности. Система формирует наступившие периоды по календарю и защищает повторный запуск идемпотентным ключом. Руководитель видит активные планы, ближайшие начисления и общую сумму к оплате, а клиент получает безопасный платёжный календарь в своём кабинете.
- еженедельный и ежемесячный график;
- отдельный плательщик и получатель услуги;
- связь с абонементом и правом доступа;
- пауза, окончание и отмена плана;
- версионные изменения и журнал операций.
02
Разрешение на списание хранится без карточных данных
ProGym принимает токенизированное разрешение провайдера и сохраняет его в зашифрованном виде. Номер карты и CVV в систему не передаются. Сотрудник видит понятную подсказку способа оплаты, статус согласия и срок действия, но не получает платёжный секрет. Разрешение можно отозвать, после чего новые попытки прекращаются.
Для полной проверки без денег используется sandbox с ручным успехом, ручным отказом и автоматическими сценариями. Серверный адаптер Payme Subscribe уже создаёт чек через receipts.create и оплачивает его через receipts.pay по подтверждённому recurrent token. Для боевого запуска клуб добавляет собственные merchant credentials и проходит provider acceptance. Click AutoPay остаётся закрытым до отдельного технического контракта и приёмки.
03
Неопределённый ответ останавливает повтор до сверки
Платёжный запрос может завершиться без надёжного ответа: соединение оборвалось после отправки, провайдер вернул неполное состояние или результат нельзя однозначно подтвердить. ProGym не считает такой платёж успешным и не переводит его в обычный отказ. Попытка получает отдельный безопасный статус, а разрешение Payme временно приостанавливается.
Фоновая очередь больше не повторяет списание по этому разрешению. Сотрудник видит действие «Сначала сверить Payme», проверяет операцию в кабинете провайдера и только после сверки продолжает работу с долгом. Такой порядок защищает клиента от второго списания и сохраняет честную финансовую историю клуба.
- успех создаёт receipt и закрывает начисление;
- явный отказ запускает dunning policy;
- неопределённый ответ блокирует автоматический повтор;
- raw token и provider response остаются вне интерфейса;
- Click AutoPay включается после отдельной приёмки.
04
Отказ запускает управляемый сценарий возврата
После отказа система открывает дело по задолженности, записывает попытку и назначает следующий повтор по правилам клуба. Льготный период, число попыток и действие с доступом настраиваются в плане. Каждое событие остаётся в хронологии: открытие, отказ, следующий повтор, исчерпание попыток, приостановка абонемента, успешная оплата и восстановление.
Фоновая очередь обрабатывает наступившие платежи под блокировкой, поэтому параллельные процессы не создают двойное списание. Успех формирует каноническую проводку Taska Ledger и распределяет сумму на начисление в одной транзакции. Если ProGym ранее приостановил абонемент из-за этого долга, погашение возвращает прежний доступ.
- гибкое расписание повторов;
- льготный период перед ограничением;
- причина и номер каждой попытки;
- автоматическая проводка и распределение;
- контролируемое восстановление абонемента.
05
Сотрудник и клиент видят подходящий уровень деталей
В рабочем месте сотрудника есть планы, начисления, разрешения и дела по задолженности. Уполномоченный сотрудник может сформировать следующий период, имитировать sandbox-результат, списать часть долга с обязательным основанием, закрыть дело и восстановить абонемент. Роли разделяют просмотр, корректировки и управление списаниями.
Клиент видит название плана, сумму, остаток, срок и публичное состояние возврата оплаты. Provider token, внутренний reference, служебные meta и аудит в кабинет не попадают. Для пилота команда проходит полный сценарий: план, начисление, отказ, повторы, ограничение, погашение, проводка и восстановление доступа.