Начнём с примера: клиент оплатил доступ на сутки в 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. В нём таймер начинается сразу после оплаты, а по окончании периода диалог закрывается. Отложенный старт и доставку ответов после закрытия нужно проверить отдельно, прежде чем обещать эти условия клиентам.
Базовая настройка проекта состоит из пяти шагов:
Создать проект «Платные диалоги».
Создать бота через BotFather и подключить его к проекту.
Подключить служебную группу с включёнными темами.
Добавить тариф с ценой и длительностью. Инструкция описывает дни и месяцы; часы пока отмечены как будущая возможность.
Включить Stars и настроить сообщения с условиями, приветствием и уведомлением об окончании периода.
Клиента в служебную группу не добавляем. Топики упорядочивают переписку, но не скрывают материалы от остальных участников этой группы. Доступ сотрудников к коду, логам и документам выдаём с учётом этого.
Если пишем своего бота, маршрут храним по составному ключу (bot_id, support_chat_id, message_thread_id), с привязкой к Telegram ID клиента. Username может измениться и для идентификации не подходит. Ответы принимаем только от разрешённых сотрудников. Для создания топиков в супергруппе боту нужны права администратора с can_manage_topics.
Оплата и доступ: требования к своему бэкенду
Рассматриваем цифровую консультацию, которую продаём через бота и оказываем внутри Telegram. Для этого сценария Telegram требует Stars, валюта счёта — XTR. Наличие внешней платёжки этого требования не отменяет.
Платёжный flow:
Создаём заказ с зафиксированными ценой, длительностью, режимом старта и условиями. Его ID передаём в
invoice_payload.На
pre_checkout_queryпроверяем заказ, плательщика, валюту, сумму и наличие свободного места. Если мест мало, резервируем слот атомарно. Ответ черезanswerPreCheckoutQueryдолжен дойти до Telegram в течение 10 секунд после отправки запроса — ожидание в очереди тоже расходует этот срок.На
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, скорректировать цену и определить допустимую нагрузку.
Схема из статьи связывает условия услуги с конкретными правилами бэкенда: когда открыть доступ, какие вопросы принять и какие ответы ещё нужно доставить. Клиент получает понятные границы оплаченной услуги, а эксперт — основу для планирования работы и разбора спорных ситуаций по сохранённой истории оплаты и обращений.
Поделитесь, как бы вы поступили с уточнением к ответу, который эксперт прислал уже после окончания оплаченного окна? Включили бы его в исходный разбор или открыли новую консультацию?
