01
Сначала определите, что клуб считает задолженностью
Задолженность начинается не с неприятного разговора на ресепшене, а с точного начисления. Клубу нужно разделить цену договора, плановый платёж, фактически полученную сумму, списанную корректировку и доступный остаток. Если эти значения живут в одной редактируемой ячейке, команда теряет причину расхождения и не может доказать, почему клиенту ограничили услугу.
Зафиксируйте типы договоров и момент возникновения обязательства. Для месячного членства это может быть первый день периода, для детской секции конкретная дата по договору, для персонального пакета отдельный график. Опишите льготный период, допустимую частичную оплату, правила паузы и основания для ручного списания. Эти решения становятся политикой плана оплаты.
02
Разделяйте участника, плательщика и договор
В фитнес-клубе деньги часто поступают от другого человека или организации. Родитель оплачивает занятия ребёнка, компания финансирует сотрудника, супруг покупает семейный пакет, страховая подтверждает допуск. Плательщик отвечает за финансовое обязательство, участник получает услугу, а договор задаёт условия. Одна карточка на всех приводит к ошибочным уведомлениям и ограничениям.
Система должна хранить связи и разрешённые области доступа. Родитель может видеть расписание и оплату ребёнка, корпоративный координатор работает только с сотрудниками своего договора, тренер не получает платёжный токен. При смене плательщика будущие начисления переходят на новую связь, а история прошлых периодов сохраняет первоначального ответственного.
03
Стройте начисления как отдельный календарь
План оплаты описывает повторяемое правило, а начисление фиксирует конкретный период. У начисления есть дата, сумма, валюта, оплаченная часть, списанная часть и остаток. Такой подход позволяет заранее видеть нагрузку на денежный поток, отличать будущий платёж от просроченного и сверять поступления с тем периодом, который они действительно закрывают.
Генерация должна быть повторяемой. Перезапуск фоновой задачи или двойной клик сотрудника не создаёт второй период. Для коротких месяцев день оплаты корректно ограничивается последним днём. Дата окончания договора останавливает будущие начисления. Ручной график стоит использовать для исключений, а массовые тарифы удобнее вести недельной или месячной периодичностью.
04
Получайте отдельное согласие на автосписание
Автоматическое списание требует понятного согласия плательщика и токена платёжного провайдера. CRM фитнес-клуба не должна принимать номер карты или CVV. Провайдер возвращает ссылку на разрешение, система шифрует её и показывает сотруднику только безопасную подсказку. Согласие имеет время, статус и при необходимости срок действия.
Отзыв разрешения прекращает будущие попытки, но сохраняет финансовую историю. При замене карты создаётся новое разрешение. В текущем серверном контуре Payme Subscribe использует recurrent token и tenant credentials для последовательных receipts.create и receipts.pay. Номер карты, CVV, token и полный ответ провайдера не выводятся сотруднику. Click AutoPay проходит отдельную техническую приёмку до включения.
05
Задайте разумное расписание повторов
Повторять платёж каждую минуту бессмысленно и раздражает клиента. Практичный график учитывает дату зарплаты, банковские ограничения и формат услуги. Например, первый повтор выполняется через день, второй через три дня, третий через неделю. Между попытками клиент получает понятное сообщение, а сотрудник видит следующую дату и причину предыдущего отказа.
Для каждого результата нужен идемпотентный ключ и номер попытки. Параллельные воркеры блокируют одно начисление, поэтому не отправляют два запроса одновременно. Явный отказ Payme запускает dunning policy. Сетевой timeout, неполный ответ или неподтверждённое состояние считаются неопределённым результатом: mandate приостанавливается, а автоматические повторы прекращаются до ручной сверки.
06
Связывайте ограничение доступа с льготным периодом
Мгновенная блокировка после первого отказа часто разрушает отношения с постоянным клиентом. Клуб задаёт льготный период и число допустимых попыток. До его окончания доступ сохраняется или получает явный статус grace. После исчерпания политики система может приостановить связанный абонемент и показать сотруднику конкретное дело, из-за которого изменилось право прохода.
Автоматическое восстановление безопасно только для изменения, которое сделала сама система. Если абонемент ранее заморожен по медицинской причине или закрыт сотрудником, успешная оплата не должна активировать его самовольно. Дело хранит прошлый статус и идентификатор членства, поэтому возврат долга восстанавливает доступ лишь в разрешённом случае.
07
Проводите оплату и распределение одной операцией
Успешный ответ провайдера ещё нужно связать с бухгалтерским учётом. Система создаёт receipt в общем ledger и распределяет доступную сумму на начисление. Валюта, остаток проводки и остаток начисления проверяются до записи. Повторный callback возвращает существующий результат и не увеличивает оплаченную сумму второй раз.
Частичный платёж переводит начисление в отдельное состояние и оставляет видимый остаток. Ручное списание долга требует суммы и основания, сохраняет автора и версию объекта. Отмена или возврат опираются на исходную операцию. Такой журнал позволяет бухгалтеру сверить кассу, provider statement и клиентский баланс без ручного восстановления цепочки событий.
08
Дайте сотруднику рабочую очередь, а не общий отчёт
Список просрочки полезен, когда рядом есть следующее действие. Сотрудник должен видеть плательщика, остаток, число попыток, следующую дату, льготный срок и состояние доступа. История дела объясняет, какие уведомления и технические действия уже произошли. Роль определяет, кто может только читать, кто корректирует сумму, а кто управляет разрешениями и закрывает дело.
Ручное закрытие используется после оплаты переводом, договорённости или подтверждённой ошибки. Сотрудник вводит резолюцию и отдельно решает вопрос восстановления абонемента. Опасные операции требуют подтверждение, актуальную версию и идемпотентный ключ. Аудит связывает действие с пользователем, клиентом и начислением.
09
Сообщайте клиенту ровно то, что ему нужно
В клиентском приложении достаточно показать название плана, сумму, остаток, срок, состояние и дату следующей попытки. Внутренние коды отказа можно перевести в понятное действие: проверить способ оплаты, дождаться обработки или связаться с клубом. Платёжный token, provider reference, служебные meta и внутренний аудит клиенту не передаются.
Тон сообщения влияет на удержание. Формулировка должна объяснять ситуацию и следующий шаг, а не обвинять человека. После погашения статус обновляется сразу, начисление закрывается, а ранее приостановленный системой абонемент восстанавливается. Клиент видит результат без звонка на ресепшен, сотрудник получает меньше повторных вопросов.
10
Измеряйте возврат задолженности и качество процесса
Минимальный набор показателей включает сумму наступивших начислений, долю оплаты в срок, просрочку по возрасту, успешность первой и повторных попыток, среднее время возврата, ручные списания и число приостановленных абонементов. Сравнивайте тарифы, филиалы и способы оплаты с учётом размера базы, чтобы крупный клуб не выглядел хуже только из-за объёма.
Отдельно следите за техническими отказами, повторными callback и делами без следующего действия. Резкий рост конкретного кода может означать сбой провайдера, а не ухудшение платёжной дисциплины. Drill-down должен вести к попыткам и начислениям, сохраняя права роли и организационную изоляцию.
11
Связывайте оплату с коммуникацией и NPS
Финансовое событие не должно превращаться в хаотичную рассылку. Для каждого этапа подготовьте отдельное сообщение: напоминание до срока, уведомление об отказе, дата следующей попытки, окончание льготного периода и подтверждение погашения. Текст называет сумму, договор и безопасный способ действия. Частота ограничивается правилами, а доставка и реакция сохраняются в журнале кампании.
Низкая оценка NPS после платёжного инцидента требует внимания сервиса. Ответ с оценкой от нуля до шести может автоматически открыть приоритетное обращение, связанное с клиентом и источником. Сотрудник видит контекст, отвечает и фиксирует решение. Так клуб отличает техническую задолженность от ситуации, где неудачный процесс оплаты уже угрожает удержанию клиента.
12
Сохраняйте организационную изоляцию и историю
В сети клубов каждое начисление, разрешение, попытка и дело принадлежит конкретной организации. Row level security и составные внешние ключи защищают от случайной связи объектов разных tenant. Фоновая задача передаёт organization identifier явно от родительской записи, потому что у неё нет пользовательской сессии, из которой можно безопасно вывести область данных.
Попытки списания и события взыскания полезно хранить как append-only историю. Исправление выполняется новой операцией, а не редактированием результата банка. Агрегаты плана, начисления и дела используют optimistic version, поэтому позднее окно сотрудника не перезаписывает свежий статус. Аудит дополняет финансовую цепочку автором, временем, действием и техническим источником.
13
Закрывайте период после сверки задолженности
Перед закрытием месяца бухгалтер сверяет начисления, ledger receipts, кассовые продажи, возвраты, ручные списания и отчёты платёжных провайдеров. Открытое дело может законно перейти в следующий период, но его сумма, возраст и следующее действие должны быть определены. Неопознанный платёж или попытка без итогового статуса остаются блокирующим пунктом чек-листа.
После закрытия операционные даты защищаются от незаметного изменения. Корректировка проходит через повторное открытие периода с основанием и отдельным событием. Руководитель получает сумму просрочки по возрастным корзинам и прогноз поступлений, а бухгалтер может раскрыть итог до начисления, проводки и provider reference. Такой порядок соединяет ежедневную работу с управленческой отчётностью.
14
Проведите пилот на полном отрицательном сценарии
Приёмка начинается с активного абонемента, плана и sandbox-разрешения. Сформируйте начисление, зафиксируйте отказ, проверьте дело и следующий повтор. Доведите процесс до исчерпания попыток и убедитесь, что при политике suspend изменился только связанный абонемент. Затем проведите успешную оплату и сверьте проводку, распределение, закрытие долга и возврат доступа.
Повторите запросы с теми же ключами, запустите два обработчика параллельно и проверьте границы ролей. Отдельно оборвите соединение после отправки Payme-запроса: начисление не должно стать оплаченным или уйти на автоматический повтор, а сотрудник должен увидеть требование сверки. После программной приёмки подключайте merchant sandbox Payme, сверяйте первый платёж по отчёту провайдера и Taska Ledger. Click AutoPay принимайте отдельным сценарием после получения официального контракта.
Зафиксируйте результаты пилота в таблице сценариев. Для каждого шага сохраните ожидаемый статус, фактический ответ, автора проверки и ссылку на операцию. Отдельно пройдите просроченное разрешение, отсутствующий способ оплаты, частичное погашение, ручное списание, закрытие без восстановления и повторный callback. Проверьте мобильный кабинет на узком экране, клавиатурную навигацию рабочего места и тексты на русском, узбекском и английском. Внешний провайдер считается принятым после положительного и отрицательного боевого сценария, подтверждённой сверки, настроенного мониторинга и назначенного ответственного за инциденты. До этого capability остаётся закрытой и сообщает сотруднику точную причину. Первый день после запуска контролируйте по журналу очереди, уведомлениям и расхождениям сверки каждый час.
- план и корректное начисление;
- отказ и расписание повторов;
- льготный период и доступ;
- погашение и проводка;
- идемпотентность, роли и безопасная проекция.