Скрипт для бота Telegram по продаже звёзд: что внутри готовых сборок и чего в них нет

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

Я разобрал по исходникам три сборки, которые Яндекс держит первыми по запросам про скрипт и магазин звёзд телеграм. В одной звёзды отправляет админ руками. Во второй за автоматическую выдачу отдают мнемонику кошелька. Третья — аккуратный проект на 65 файлов, и он просто подключён к API чужого поставщика. Вывод из всех трёх один, и он не про качество программирования.

Что делает скрипт магазина звёзд

Любая такая сборка — это пять кусков: меню с пакетами, приём денег, база заказов, админка и доставка звёзд. Первые четыре скрипт закрывает. Пятый — отправку получателю — не закрывает никто, потому что купить Stars программно внутри Telegram нельзя: в Bot API нет метода покупки за деньги, баланс бота наполняется только платежами пользователей.

Вся разница между сборками — как они решают чужую задачу.

Сборка первая: аккуратная, с поставщиком по API

evansvl/telegram-stars-bot — open-source под MIT, 65 файлов, aiogram 3, PostgreSQL, Redis, миграции alembic, Docker, две локали, реферальная программа. Создан 18 июня 2026, последний коммит 3 июля 2026. Видно, что писали для эксплуатации, а не для скриншота.

Оплата у покупателя — карта и СБП через WATA плюс TON: отдельный поллер следит за поступлениями на кошелёк. А звёзды берутся у сервиса GreenGamePay, четырьмя запросами:

POST /api/token            → токен, живёт около 15 минут
POST /api/get_stars_price  → оптовая цена N звёзд
POST /api/check_balance    → наш предоплаченный баланс
POST /api/buyStars         → выдать N звёзд на @username, списать с баланса

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

Что в этом проекте стоит знать до запуска:

• Авторизация логином и паролем. В .env кладутся GGP_USERNAME и GGP_PASSWORD, из них раз в 15 минут добывается токен. Утёк такой доступ — утёк аккаунт целиком; отозвать один ключ, оставив остальное, нельзя.
• У выдачи нет ключа идемпотентности. В buyStars уходят только username и количество. При этом клиент повторяет запрос при таймауте и на 429/500/502/503/504 — до трёх попыток с задержкой. Повтор не различает «не дошло» и «дошло, но ответ потерялся» — защита от второй выдачи целиком на стороне сервиса, и в коде она не подтверждена.
• Наценка ограничена кассой. В модуле цен видно: сумма заказа не может превышать минимальную больше чем в 1,5 раза — это требование WATA. Работает от 50 до 50 000 звёзд.
• .env.example вместо .env. Ключей автора в репозитории нет. Дальше будет видно: это редкость.

Сборка вторая: звёзды приходят сами, но в обмен на кошелёк

dobrozor/tg_buy_stars — десять файлов, telebot, SQLite, экспорт заказов в Excel, ЮKassa и приём TON, реферальные пять рублей. Создан в сентябре 2025, последний коммит 2 апреля 2026. Файла лицензии в репозитории нет вовсе.

Звёзды здесь берутся через сторонний сервис api.fragment-api.com, и механику стоит прочитать внимательно — она типична:

POST /auth/authenticate/
{
  "api_key": "...",
  "phone_number": "+7...",
  "mnemonics": ["слово", "слово", ...],
  "version": "V4R2"
}

В ответ приходит JWT, он кладётся в файл рядом со скриптом, а заказ уходит одним запросом POST /order/stars/ с username и количеством.

Смотрите, что уезжает наружу: номер телефона и мнемоника кошелька — та самая сид-фраза. Кто её знает, тот распоряжается деньгами на кошельке. Не дыра конкретной сборки, а условие работы: чтобы обёртка купила звёзды за вас, она должна платить с вашего кошелька, а значит — им владеть.

Остальное по мелочи, но эти мелочи стоят денег:

• у создания платежа в ЮKassa ключ идемпотентности есть, а у заказа звёзд его снова нет;
• оплата узнаётся опросом статуса, вебхука с проверкой подписи нет;
• цена звезды — константа STAR_PRICE = 1.5 в конфиге, минимум 50 штук;
• в репозитории закоммичен .env — с токеном бота, секретным ключом кассы, ключом TON API, ключом и мнемоникой для обёртки. Живые ли значения, я не проверял; важно, что так выглядит норма жанра.

Сборка третья: витрина и касса, выдача руками

MrShoon/StarsShopTG — один файл main.py на 1265 строк, aiogram 3, SQLite, лицензия Apache-2.0. Создан и последний раз обновлён 6 января 2026: с тех пор не трогали.

Внутри шесть пакетов с ценами, вбитыми константами: 100 звёзд — 115 ₽, 250 — 275 ₽, 500 — 525 ₽, 1000 — 1050 ₽, 2500 — 2625 ₽, 5000 — 5250 ₽. Два способа оплаты: ЮKassa и перевод на карту с ручным подтверждением. Список ID администраторов — прямо в коде, двадцать шестой строкой.

А теперь главное: поиск по всему файлу не находит ни fragment, ни валюты XTR, ни любого другого способа отправить звёзды. Устроено так: админ жмёт кнопку, статус меняется на completed, покупателю уходит «Администратор выдал вам N Telegram Stars». Отправил ли админ что-нибудь на самом деле, код не знает и не проверяет.

Это не магазин, а бланк заказа. Ночью покупатель заплатил — ночью же кто-то должен вручную купить и перевести их. Цены при этом с января не двигались: 1,15 ₽ за штуку в пакете на сотню и 1,05 ₽ в пакете на пять тысяч. Для покупателя выглядит привлекательно, но при более дорогой закупке — минус с каждого заказа.

Что общего у всех трёх

Ни один телеграм-бот из этой тройки не доводит доставку до состояния «можно оставить без присмотра». Список того, чего нет ни в одной сборке, короткий, но именно он отделяет «работает у автора на видео» от «работает у вас с живыми покупателями»:

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

Речь не о витрине, а о слое доставки. Витрину можно взять готовую и допилить под себя. Выдачу — нет.

Четыре риска, которые скрипт приносит с собой

Чужие ключи в комплекте. Если в архиве лежит заполненный .env — неизвестно, чьи это ключи и кто ещё их читает. Первое действие после распаковки — выкинуть все значения и выпустить свои.

Непонятная лицензия. MIT и Apache-2.0 — это разрешение. Отсутствие файла лицензии означает обратное: по умолчанию все права у автора, и использовать код в своём проекте вам формально нельзя.

Заброшенность. Две из трёх сборок не трогали месяцами, а Telegram за это время правил Bot API не раз. Тестов нет ни у одной — чинить придётся вам.

Форумные сборки без исходников. Половина результатов по запросу — темы на закрытых форумах, где сборку вроде «автоматизированный магазин звёзд и Premium» продают файлом. Прочитать код до оплаты там нельзя, а после уже поздно: закладку в сотне килобайт обфусцированного питона вы не найдёте. Если всё же берёте, запускайте на отдельном сервере и с отдельными ключами.

Как проверить чужой скрипт за пятнадцать минут

Не читайте весь код — ищите ответы на семь вопросов. Первые три находятся обычным поиском по папке:

grep -ril "fragment\|buyStars\|order/stars\|XTR\|sendGift" .
grep -rin "mnemonic\|seed\|phrase\|private_key" .
grep -rn "Idempot\|idempotency" .

1. Как выдаются звёзды. Первый поиск ничего не нашёл — выдача ручная, это бланк заказа.
2. Требуют ли мнемонику. Нашлось во втором поиске в коде авторизации — вы отдаёте кошелёк наружу.
3. Есть ли идемпотентность у заказа, а не только у платежа. Разница именно здесь.
4. Откуда берётся цена. Константа в конфиге — при движении курса продаёте в убыток.
5. Как узнаётся оплата. Опрос в цикле или вебхук с проверкой подписи.
6. Дата последнего коммита. git log -1 --date=short — и сравните с датой последних изменений Bot API.
7. Лицензия. Нет файла — нет разрешения.

Что писать самому, а что не надо

Вопрос «как создать бота по продаже звёзд» сводится к четырём вещам, и свой код нужен ровно на них: пакеты на витрине, касса, один запрос к поставщику, показ статуса покупателю. Это вечер работы на aiogram или telebot, и готовые сборки как образец годятся — посмотрите, как сделаны клавиатуры, состояния и хранение заказов.

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

Вариант «свой TON-кошелёк плюс своя обвязка к Fragment» тоже рабочий, но это не скрипт на вечер: держать запас TON под скачки курса, следить за доставкой, разбирать сбои и переписывать обвязку после каждой правки на стороне телеграма.

Наш API закрывает ту половину, которую скрипт не закрывает

Мы — поставщик звёзд телеграм: отдаём Telegram Stars и Premium оптом по REST API: до 50 000 звёзд в заказе, звёзды Telegram уходят получателю официальным переводом на username — обычно в пределах пары минут. Ключ идемпотентности у заказа, проверка получателя до оплаты, вебхуки с подписью X-Signature, автовозврат при неудачной доставке, 120 запросов в минуту на ключ.

Кошелёк и мнемоника остаются у нас. Вам выдаётся ключ вида pk_live_... — его можно ограничить по IP и в любой момент перевыпустить в кабинете, не меняя пароль от аккаунта. Что умеет каждый метод и какие бывают ошибки, видно заранее: документация API звёзд телеграм и машиночитаемая спека лежат открыто.

Частые вопросы

Есть ли бесплатный скрипт магазина звёзд, который сразу работает? Витрина с кассой — да, в открытом доступе их несколько, и одна написана хорошо. Товара нет ни в одной: скрипт либо оставляет выдачу админу, либо обращается к сервису, доступ к которому вы получаете отдельно.

Почему обёртки просят мнемонику кошелька? Потому что покупка звёзд на Fragment платится с кошелька. Без доступа к нему сервис не проведёт оплату за вас. Обход один — работать с поставщиком, который платит своим кошельком и отдаёт готовый товар.

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

Чем плох Idempotence-Key только у платежа? Он защищает от двойного списания у покупателя, но не от двойной выдачи товара. Это разные запросы к разным системам, и ключ нужен обоим.

Нужна ли база данных? Да, хотя бы SQLite: без сохранённых заказов вы не разберёте споры и не сделаете возврат. Идентификатор платежа и ключ идемпотентности заказа храните вместе с заказом.