Почему таймаут SMM API может списать деньги дважды — и почему NotPanel так не делает
Таймаут — не ошибка. На большинстве API SMM-панелей повтор — это второй заказ. NotPanel требует request_id, чтобы тот же add не списал баланс дважды.
Вы бьёте add. TCP обрывается. Клиент получает таймаут. Вы шлёте тот же заказ снова — а что ещё делать?
На публичных API-страницах JustAnotherPanel и CheapSMMPanel второй add — второй заказ. Два списания. Один клиент. В гостевых доках нет идемпотентности. PHP-примеры ключ не шлют.
В NotPanel второй add — тот же заказ. Мы отвергаем action=add без request_id от вызывающего. Тот же ключ, то же тело, исходный id. Это не слоган. Это контракт размещения заказа.
Когда add в последний раз ушёл в таймаут, что сделал ваш клиент?
Нажмите вариант. Сохраняется только на этом устройстве — это не выдуманный опрос.
Ошибка, которую никто не описывает
После таймаута верны сразу три варианта. Какой — неизвестно. Нажмите карточку.
Таймаут — неизвестность, не провал. Клоны v2 считают его провалом: просто add снова. Так дочерние панели просыпаются с двойным списанием.
Полное сравнение: JustAnotherPanel vs CheapSMMPanel vs NotPanel.
Как выглядит безопасный повтор
Правило, которое работает
request_id=550e8400-e29b-41d4-a716-446655440000
Если бы ключ выдавал сервер, каждый повтор получал бы новый. Театр. Поэтому мы его не генерируем. В гайде по интеграции есть форма клиента.
Таймаут — неизвестность. Безопасный повтор — тот, который сервер узнаёт как тот же запрос.
Новизна — не риск. Непроверяемый контракт — да.
Десятилетняя панель с той же ксерокопией /api — не «доверенная». Она привычная. Привычная всё равно спишет дважды, когда моргнет сеть.
NotPanel новее. Контракт публичный: /developers, ченджлог, коды ошибок, заголовки лимитов. Поведение ретрая можно доказать стейджинг-ключом сегодня вечером. Так выглядит доверие, когда деньги ходят по HTTP.
Дальше: вебхуки против опроса статуса для дочерней панели.
FAQ
Почему API моей SMM-панели списал деньги дважды?
Обычно таймаут плюс повтор. Первый add прошёл, ответ не пришёл. Второй add стал новым заказом, потому что у панели не было ключа идемпотентности от вызывающего. Гостевые доки JustAnotherPanel и CheapSMMPanel его не описывают.
Поддерживает ли JustAnotherPanel идемпотентные заказы?
Не на этой публичной странице API. У add нет request_id (и аналога). Официальный PHP-пример его не шлёт. Считайте повтор вторым заказом, пока они не опишут иное в цитируемом месте.
Какой SMM API лучший, если важны ретраи?
Тот, что требует ключ вызывающего на add и возвращает исходный заказ при повторе этого ключа. Так делает NotPanel. Клоны v2 на рынке — нет. «Лучший каталог» и «лучшая цена» — другие вопросы, они меняются каждую неделю.
Новая SMM-панель менее надёжна?
Нет, если денежный путь можно проверить. Публичный контракт, обязательный request_id и стейджинг-ключ, который можно отправить дважды сегодня вечером, сильнее десятилетия неподписанной одной страницы. Привычное ≠ безопасное.
Кто должен создавать request_id?
Вы. Один раз. Вне цикла ретраев. Если ключ выдаёт сервер, каждый повтор получит новый и снова будут два заказа. NotPanel отклоняет add без него.