Последний месяц два разных клиента пришли почти с одной фразой: «хотим бота в телеграм, чтобы клиенты записывались и платили». Ещё год назад я бы собрал форму на inline-кнопках и сдал проект за пару дней. Но к 2026-му у Telegram появились Mini App с нормальными платежами и Stars, и «бот для записи» превращается в проект с настоящим интерфейсом и биллингом. Разберу, что изменилось, что из этого стоит брать в работу и где я набил шишки сам.
Что вообще изменилось в Telegram за два года
Года три назад типовой «бот для бизнеса» выглядел одинаково: приветствие, пять inline-кнопок, форма из трёх вопросов, заявка падает в почту. Дешёвка, которая работала. В 2026-м Bot API ушёл далеко вперёд, и часть того, что раньше требовало писать отдельное мобильное приложение, теперь делается внутри телеграма.
Коротко о главном:
- Mini App повзрослели. Bot API 8.x дал им полноэкранный режим, запуск с ярлыка на домашнем экране, нормальную работу с камерой и геолокацией. По сути это уже веб-приложение с авторизацией «из коробки» — пользователь не регистрируется, телеграм сам передаёт его идентификатор.
- Платежи внутри Mini App. Сторонние провайдеры с Google Pay и Apple Pay «из коробки» — корзина, оплата, возврат в чат. Для цифровых товаров у Telegram своя валюта, Stars.
- Stars перестали быть игрушкой. Это монетизация цифровых услуг и контента с выводом через Fragment. Не замена обычным платежам, но для подписок на ботов и доступа к контенту — рабочий механизм.
- AI поверх ботов. Подключение LLM к треду поддержки стало рутиной: бот отвечает на свободные вопросы, а человек подключается там, где модель пасует.
Из этого набора собираются вещи, которые раньше заказывали как «мобильное приложение за несколько сотен тысяч». Витрина услуг с записью, клубные боты с платным доступом, внутренние инструменты для сотрудников — всё это теперь живёт в мессенджере, где у пользователя уже есть аккаунт, уведомления и привычка открывать его двадцать раз в день.
Вебхук или long polling: что выбрать и как не налажать
Техническая развилка, с которой начинается любой бот. Long polling проще: один процесс, никаких сертификатов, работает на чём угодно. Для прототипа — идеально. Но в продакшене я почти всегда ставлю вебхук, и вот почему: polling-процесс — это единственная точка отказа. Упал сервер — обновления копятся у Telegram максимум сутки и потом теряются. Вебхук превращает бота в обычное stateless-приложение, которое масштабируется и переезжает без боли.
Настройка с секретным токеном, чтобы чужие запросы к вашему endpoint отбрасывались сразу:
curl -s "https://api.telegram.org/bot$TOKEN/setWebhook" \
-d "url=https://bot.example.com/webhook" \
-d "secret_token=my_webhook_secret_2026" \
-d "allowed_updates=["message","callback_query","pre_checkout_query"]" \
-d "drop_pending_updates=true"А на стороне бэкенда проверяйте заголовок X-Telegram-Bot-Api-Secret-Token до любой другой логики. Это две строки кода, которые избавляют от подделки апдейтов.
Единственное место, где polling всё ещё оправдан, — локальная разработка. Вебхук наружу без HTTPS не поставить, а городить туннель ради отладки лень. Берите python-telegram-bot или aiogram в режиме polling, а на проде переключайте на вебхук — код обработчиков при этом не меняется.
Mini App: когда он нужен, а когда хватает кнопок
Модное слово, за которое любят переплатить. Честный критерий простой: если взаимодействие укладывается в диалог — выбрал пункт, ввёл данные, подтвердил — вам нужен обычный бот с inline-кнопками. Mini App нужен, когда есть настоящий интерфейс: каталог с картинками, календарь записи, карта, drag-and-drop. Всё, что в чате выглядит мучением.
Технически Mini App — это веб-страница, которую бот открывает внутри Telegram. Вся магия авторизации — в параметре initData, который Telegram передаёт при запуске. Его надо проверять на сервере, иначе любой школьник подделает идентификатор пользователя:
import hmac, hashlib, urllib.parse
def validate_init_data(init_data: str, bot_token: str) -> dict | None:
parsed = dict(urllib.parse.parse_qsl(init_data, keep_blank_values=True))
received_hash = parsed.pop("hash", None)
if not received_hash:
return None
data_check_string = "\n".join(f"{k}={v}" for k, v in sorted(parsed.items()))
secret_key = hmac.new(
b"WebAppData", bot_token.encode(), hashlib.sha256
).digest()
calculated = hmac.new(
secret_key, data_check_string.encode(), hashlib.sha256
).hexdigest()
return parsed if hmac.compare_digest(calculated, received_hash) else NoneТри практических замечания. Первое: сравнивайте хэши через compare_digest, а не == — это защита от timing-атак, и она бесплатна. Второе: auth_date стоит проверять на свежесть — initData старше суток лучше отклонять. Третье: Mini App наследует тему пользователя (светлая/тёмная), и это надо уважать — белый фон в тёмной теме выглядит как баг.
Оплата: Stars для цифрового, провайдеры для остального
Здесь в 2026-м развилка по типу товара. Физические услуги и товары — обычные платёжные провайдеры через Payments API или оплату внутри Mini App. Цифровые товары и подписки внутри бота — Stars, у Telegram для них жёсткое правило: App Store и Google Play вынуждают цифровой контент вести через их биллинг, и Stars — ответ Telegram на это.
Инвойс в Stars выглядит так:
from aiogram.types import LabeledPrice
await bot.send_invoice(
chat_id=chat_id,
title="Доступ к клубу на месяц",
description="Закрытый канал + разборы проектов",
payload="subscription_monthly_001", # ваш внутренний ID товара
currency="XTR", # XTR = Telegram Stars
prices=[LabeledPrice(label="Месяц", amount=150)], # 150 звёзд
)Что надо знать заранее. Звёзды покупатель платит через Telegram, а вы выводите их через Fragment — конвертация и вывод съедают ощутимую часть, и эти условия стоит проверить на актуальность до того, как называть клиенту цену. Второе: payload — ваш ключ идемпотентности; когда придёт pre_checkout_query, вы обязаны ответить за несколько секунд, иначе оплата отменится сама. Третье: для РФ-клиентов есть нюансы и с покупкой звёзд, и с выводом — закладывайте время на юридическую часть, она здесь не менее реальна, чем код.
Оплата внутри Mini App через провайдера — отдельная история: корзина собирается в веб-приложении, платёж проходит через sendInvoice с обычной фиатной валютой, после подтверждения пользователь возвращается в Mini App. Google Pay и Apple Pay работают из коробки, что резко поднимает конверсию по сравнению с «переведите на карту и пришлите скрин».
Интеграция с CRM: где все обычно и ломается
Самая недооценённая часть проекта. Лид из бота должен попасть в CRM быстро, ровно один раз и с достаточным контекстом, чтобы менеджер не задавал клиенту вопросы, на которые тот уже отвечал боту. Три правила, которые я теперь закладываю в любую интеграцию.
Идемпотентность. Telegram иногда шлёт update повторно — это нормально, сеть. Без проверки update_id получите дубли лидов, и менеджер начнёт звонить одному клиенту дважды. Redis с TTL на сутки решает:
async def process_update(update_id: int, payload: dict):
if not redis.set(f"upd:{update_id}", 1, nx=True, ex=86400):
return # дубликат, уже обработан
await handle(payload)Очередь, а не прямые вызовы. Обработчик вебхука должен ответить Telegram за секунды. Всё тяжёлое — запись в CRM, письма, обогащение данных — уезжает в фоновую очередь (хоть Redis + RQ, хоть Celery). Иначе при лагах CRM Telegram начнёт ретраить вебхуки, и вы получите шторм повторов.
Синхронизация в обе стороны. Если бот продаёт что-то, статус заказа должен возвращаться из CRM в бот: «оплачено», «отправлено», «менеджер назначен». Односторонняя интеграция «бот → CRM» порождает поддержку на ровном месте: клиент пишет в чат «где мой заказ?», а бот вежливо молчит, потому что не знает.
Грабли, о которых пишут только в комментариях
Токен в истории git. Утечка токена бота — это «кто-то рассылает спам от имени вашего бизнеса». Убираем в переменные окружения, при утечке — revoke через BotFather. Проверьте старые репозитории прямо сейчас.
Лимиты. Примерно 30 сообщений в секунду на бота суммарно и 1 сообщение в секунду в один чат. При рассылках — только через очередь с троттлингом и обработкой 429: Telegram честно шлёт retry_after, глупость — игнорировать.
Дубликаты апдейтов. Уже сказал, но повторю: ваш обработчик обязан быть идемпотентным. Это не опция, а требование архитектуры.
Хостинг. Боту хватает VPS за несколько сотен рублей в месяц. Чего не хватает — так это диску под логи: логируйте осознанно, ротация обязательна. И мониторьте доступность самого вебхука — тихо умерший бот узнают по жалобам клиентов, а это худший способ.
Сколько это стоит и когда окупается
По моим проектам расклад такой. Бот-форма (приём заявок + отправка в CRM) — дни работы и копейки на хостинг, окупается на первом же кванте лидов, который раньше терялся в почте. Бот с Mini App, каталогом и оплатой — недели, и тут главный вопрос не в разработке, а в том, есть ли у бизнеса реальный сценарий возврата пользователя. Клубный бот с платной подпиской через Stars окупается, когда есть хотя бы пара сотен тёплых подписчиков — математика простая, и она честнее любой воронки на слайдах.
Отдельно скажу про AI-надстройки. Подключить LLM к боту — вечер работы. А вот сделать так, чтобы модель не путала тарифы клиента и не выдумывала условия доставки, — работа на недели: базы знаний, тесты, эскалация на живого оператора. Заказывайте её с пониманием цены.
Итог
Telegram-бот в 2026-м — это уже не «кнопка с меню», а полноценный канал с интерфейсами, платежами и CRM-интеграцией, у которого нет своей стоимости привлечения: пользователь уже здесь. Мой порядок действий при новом проекте стал короче: сначала сценарий и что где платится, потом решение «кнопки или Mini App», и только потом код — причём вебхук, идемпотентность и очередь закладываются с первого дня.
А какие боты вы делали сами и что из этого живо до сих пор? Особенно интересно про опыт с Stars — делитесь в комментариях.
