Начнём с примера: клиент оплатил доступ на сутки в 01:00, а первый ответ эксперта получил в 10:00. Тогда если таймер запустился в 01:00 (сразу после оплаты), то девять часов оплаченного периода уже прошли. На переписку осталось всего пятнадцать.

Для разбора кода, архитектуры или интеграции с API мало подключить платёжку. Нужно определить объём работы, момент старта и правила завершения консультации. Ниже — пример условий, настройка диалога через готовый сервис и требования к собственному бэкенду.

Что покупает клиент

Возьмём условный тариф «Разбор интеграции с API». До оплаты фиксируем:

• Объём: одна заранее согласованная задача, первичный разбор и до двух раундов уточнений в пределах окна приёма. Полный аудит репозитория и внедрение изменений в тариф не входят.

• Окно приёма вопросов: 24 календарных часа с момента активации.

• SLA ответа: до четырёх рабочих часов на каждое принятое обращение; график — будни, 10:00–18:00 МСК. Автоответ бота содержательным ответом не считается.

• Завершение: принятые обращения разбираем и после окончания окна, с тем же SLA. Новые обращения после дедлайна требуют следующей консультации.

Это один из возможных вариантов договорённостей с клиентом. Ограничения по теме, сложности и объёму согласуем заранее: один сложный вопрос может вполне тянуть на отдельный проект.

Сутки полученного доступа не означают сутки работы эксперта. Если одна консультация в среднем занимает час вместе с перепиской и админкой, четыре рабочих часа дают расчётные четыре консультации в день. Это оценка без резерва на сложные задачи и сбои; фактический лимит должен учитывать разброс трудозатрат. В цену также необходимо заложить расходы на платежи и сервис.

Когда запускать таймер

Есть два варианта:

Суточный тариф с рабочим графиком требует внимания. При оплате и первом вопросе в пятницу в 19:00 окно закроется в субботу в 19:00, а ответ в понедельник до 14:00 ещё уложится в четыре рабочих часа. Для клиента это означает отсутствие времени на уточнения.

Поэтому тарифы, которые предоставляют доступ на короткие периоды продаём в заранее объявленные интервалы, оставляющие рабочее время на ответы и уточнения, либо согласуем отложенный старт. Само подтверждение готовности вечером перед выходными проблему не решает — график всё равно нужно учитывать.

В собственной реализации отложенный режим требует состояния paid_waiting и отдельного перехода в active. Перед активацией проверяем готовность эксперта и маршрута переписки. Оплаченная заявка ещё не равна начавшейся консультации.

Как организовать переписку

Удобный маршрут: клиент пишет личному боту, сообщения попадают в отдельный топик служебной группы, эксперт отвечает из него.

Такой сценарий описан в документации Nemiling. В нём таймер начинается сразу после оплаты, а по окончании периода диалог закрывается. Отложенный старт и доставку ответов после закрытия нужно проверить отдельно, прежде чем обещать эти условия клиентам.

Базовая настройка проекта состоит из пяти шагов:

1. Создать проект «Платные диалоги».

2. Создать бота через BotFather и подключить его к проекту.

3. Подключить служебную группу с включёнными темами.

4. Добавить тариф с ценой и длительностью. Инструкция описывает дни и месяцы; часы пока отмечены как будущая возможность.

5. Включить Stars и настроить сообщения с условиями, приветствием и уведомлением об окончании периода.

Клиента в служебную группу не добавляем. Топики упорядочивают переписку, но не скрывают материалы от остальных участников этой группы. Доступ сотрудников к коду, логам и документам выдаём с учётом этого.

Если пишем своего бота, маршрут храним по составному ключу (bot_id, support_chat_id, message_thread_id), с привязкой к Telegram ID клиента. Username может измениться и для идентификации не подходит. Ответы принимаем только от разрешённых сотрудников. Для создания топиков в супергруппе боту нужны права администратора с can_manage_topics.

Оплата и доступ: требования к своему бэкенду

Рассматриваем цифровую консультацию, которую продаём через бота и оказываем внутри Telegram. Для этого сценария Telegram требует Stars, валюта счёта — XTR. Наличие внешней платёжки этого требования не отменяет.

Платёжный flow:

1. Создаём заказ с зафиксированными ценой, длительностью, режимом старта и условиями. Его ID передаём в invoice_payload.

2. На pre_checkout_query проверяем заказ, плательщика, валюту, сумму и наличие свободного места. Если мест мало, резервируем слот атомарно. Ответ через answerPreCheckoutQuery должен дойти до Telegram в течение 10 секунд после отправки запроса — ожидание в очереди тоже расходует этот срок.

3. На successful_payment повторно сверяем платёж с заказом и подтверждаем оплату. При немедленном старте открываем доступ, при отложенном — переводим заявку в paid_waiting. Одобрение checkout само по себе оплату не подтверждает.

Если резерв истёк до обработки успешного платежа, оплату всё равно сохраняем. Дальше согласуем доступный старт либо оформляем возврат; молча отклонять оплаченный заказ нельзя.

Для дедупа платежей ставим UNIQUE(bot_id, telegram_payment_charge_id). В одной транзакции БД блокируем заказ, записываем новую оплату, меняем его состояние и создаём доступ либо ожидающую заявку. Повтор того же платежа не запускает таймер заново. Новый платёж по уже оплаченному заказу учитываем отдельно и разбираем как лишнюю оплату.

Задачи на создание топика и отправку подтверждения записываем в outbox той же транзакцией. Воркер обрабатывает их после коммита. Это сохраняет намерение выполнить действие при падении процесса, но не гарантирует exactly-once вызов Telegram API: после тайм-аута результат отправки может остаться неизвестным. Ретрай уведомления не должен менять оплаченный срок.

Для немедленного старта также нужен порядок действий при техническом простое: сохранение входящих вопросов и предусмотренное условиями продление либо возврат.

Где проходит граница доступа

В своей реализации проверяем право на каждый новый вопрос. Один cron, который позже закроет топик, точную границу не обеспечивает.

В короткой транзакции получаем блокировку записи консультации, читаем актуальное состояние и берём свежее время проверки из единого источника. Изменения доступа выполняем с той же блокировкой. Условие допуска:

state == "active"
and not revoked
and starts_at <= checked_at < access_until

Помимо времени доступа проверяем лимиты по объёму. После прохождения проверок сохраняем вопрос с accepted_at = checked_at и consultation_id. Уникальный ключ (bot_id, chat_id, message_id) для новых сообщений защищает от повторного сохранения того же вопроса. Даты храним в UTC, рабочие часы SLA считаем по объявленному графику и таймзоне.

Если вопрос сохранён в 17:59, а окно закрывается в 18:00, воркер может доставить его эксперту в 18:02. Это уже принятое обращение: задержка доставки не меняет его статус. Здесь 17:59 — время принятия сервером, а не время отправки сообщения клиентом.

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

Новое сообщение после дедлайна бот может получить, но не передаёт его эксперту как оплаченное. Клиенту показывает состояние доступа и условия следующего обращения.

Для MVP достаточно одной активной консультации на клиента. Если одновременно разрешены несколько, клиент явно выбирает задачу; ответы эксперта сохраняют привязку к исходной консультации.

Что проверить до запуска

Условия доступны до оплаты, а для проблем с платежами есть отдельный канал поддержки. Telegram требует обработку /paysupport. Возврат Stars выполняется через refundStarPayment; удаление записи из БД деньги не возвращает.

Для первого запуска я бы ограничился одним тарифом и небольшим числом консультаций. Первые разборы покажут реальные трудозатраты: по ним можно проверить SLA, скорректировать цену и определить допустимую нагрузку.

Схема из статьи связывает условия услуги с конкретными правилами бэкенда: когда открыть доступ, какие вопросы принять и какие ответы ещё нужно доставить. Клиент получает понятные границы оплаченной услуги, а эксперт — основу для планирования работы и разбора спорных ситуаций по сохранённой истории оплаты и обращений.

Поделитесь, как бы вы поступили с уточнением к ответу, который эксперт прислал уже после окончания оплаченного окна? Включили бы его в исходный разбор или открыли новую консультацию?