Если вы выбрали путь «напишу сам», эта статья - список того, что придётся написать, кроме сайта. Она не отговаривает: своя разработка оправдана, когда у вас есть механика, которой нет у других. Она про то, чтобы срок и бюджет вы называли, зная про все части, а не про одну видимую.
Витрина - это меньшая часть работы
Каталог, карточка услуги, корзина, кабинет клиента, история заказов. На современном фреймворке это действительно недели, а не месяцы, и именно поэтому оценка «панель за месяц» звучит правдоподобно. Дальше начинается то, чего в вёрстке не видно.
Первое неочевидное место - сам каталог. Услуга поставщика это не «название и цена»: у неё есть минимум и максимум заказа, шаг, тип, требования к ссылке и собственные правила. Тысяча позиций у поставщика превращается в тысячу строк, которые нужно обновлять, наценивать и отключать, когда поставщик их снял. Ручной каталог живёт ровно до первой недели работы, дальше нужен импорт и синхронизация. Как собирать ассортимент осмысленно - в статье каталог услуг SMM-панели.
Мост к поставщикам: похоже - не значит одинаково
Почти все поставщики отдают API в одном стиле: один адрес, действие в параметре, ключ в теле запроса. Из-за этого кажется, что достаточно написать один клиент и подставлять адреса. На практике различия начинаются сразу.
- Разные наборы типов услуг: где-то заказ описывается ссылкой и количеством, где-то нужны комментарии, подписки, имена аккаунтов или расписание.
- Разные ответы на ошибку: кто-то возвращает
errorстрокой, кто-то HTTP-кодом, кто-то отдаёт HTML вместо JSON, когда у него авария. - Разные лимиты частоты запросов - и разное поведение при их превышении.
- Разные названия статусов и разное понимание частичного выполнения.
Отсюда первое архитектурное решение: свой внутренний формат заказа и адаптер на каждого поставщика. Если этого не сделать сразу, второй поставщик разнесёт условия по всему коду, а третий сделает правки опасными. Про сами типы услуг и почему ссылки с количеством недостаточно - в статье типы услуг поставщика.
Диспетчер: место, где ломается всё
Заказ живёт не в момент нажатия кнопки, а следующие несколько дней. Кто-то должен ходить по незавершённым заказам, спрашивать статус, обновлять его у вас, возвращать деньги за недоставленное и делать это, пока вы спите.
Что здесь ломается у всех, кто пишет впервые:
- Двойная отправка. Клиент нажал кнопку дважды, или задача повторилась после сбоя - и поставщик получил два заказа, а деньги списаны один раз. Лечится ключом идемпотентности на стороне вашего кода, а не надеждой на поставщика.
- Потерянный id. Заказ ушёл, ответ не дошёл из-за таймаута. Заказ у поставщика есть, у вас его нет. Нужна отдельная процедура сверки, иначе это прямой убыток.
- Опрос статусов в лоб. Тысяча активных заказов, опрос каждую минуту по одному - это тысяча запросов и бан по лимиту. Нужны пакетные запросы и разный интервал для свежих и старых заказов.
- Partial без возврата. Поставщик доставил половину, вернул остаток на ваш баланс, а клиенту деньги не вернулись. Это не бухгалтерская мелочь, а прямая причина спора и возврата.
Что значат сами статусы и что панель должна делать с каждым - в статье статусы заказов на SMM-панели.
Деньги: единственная часть без права на ошибку
Баланс клиента - это не поле в таблице, а история операций, из которой поле пересчитывается. Как только вы начнёте хранить только текущее число, первая же двойная запись превратится в спор без доказательств.
Минимум, который придётся написать: журнал транзакций, зачисления по вебхуку кассы, повторные вебхуки без двойного зачисления, ручная корректировка оператором со следом в истории, возвраты. Плюс защита от гонки, когда два заказа одновременно списывают с одного баланса. Отдельная работа - подключение самих касс и их протоколов, разобранная в статье способы приёма платежей на SMM-панели.
Обвязка, которую не считают заранее
Дальше идёт то, что не влияет на демонстрацию, но без чего панель нельзя показать клиентам: регистрация и восстановление пароля, письма с домена, чтобы они не падали в спам, свой домен с сертификатом и автопродлением, бэкапы с проверенным восстановлением, защита форм от ботов, тикеты поддержки, роли операторов, антифрод на выводах и промокодах, логи для разбора спорных заказов. Каждый пункт - от нескольких часов до нескольких дней, и вместе они дают больше, чем витрина.
Отдельно заложите нагрузку и атаки: панели регулярно ловят перебор паролей и мусорный трафик, и об этом лучше подумать до запуска, а не после. Разбор - в статье безопасность SMM-панели.
Сколько это времени и когда оно оправдано
Честная вилка для одного опытного разработчика: витрина и каталог - недели, мост и диспетчер - месяц-полтора, деньги и обвязка - ещё столько же. Плюс постоянная поддержка: чужие API меняются, и это ваша работа навсегда, а не разовый проект.
Своя разработка оправдана в двух случаях: у вас есть механика, которой нет ни у кого, и она и есть ваш бизнес; или объёмы такие, что экономия на аренде превышает стоимость команды. Во всех остальных случаях разумнее сначала запустить панель на готовом решении, собрать реальные заказы и узнать, чего вам действительно не хватает, - а список требований к своему движку писать уже по этим данным, а не по догадкам. Сравнение всех путей целиком - в статье как создать SMM-панель; проверить спрос можно бесплатно: заказы через наш каталог не тарифицируются вообще, а по сторонним поставщикам первые 100 заказов в месяц идут без оплаты.
