Я разрабатываю ResellFlow — систему автоматизации продажи цифровых товаров. Цепочка простая: GGSEL → ResellFlow → FoxReload → покупатель. Система получает заказ, определяет товар и номинал, достаёт UID игрока, проверяет цену поставщика, маржу, баланс и лимиты — и только потом может создать и оплатить заказ. Сейчас проект работает в режиме контролируемого запуска, а не как массовый сервис. Когда логики становится много, сидеть в админ-панели невозможно. Мне нужен был отдельный канал: новый заказ, успешное выполнение, остановка заказа, ошибка create или pay, неизвестный статус оплаты, низкий баланс FoxReload, аварийная остановка AUTO LIVE. Так появился бот ResellFlow Monitor в MAX. Сначала — API Получить токен бота и определить chat ID оказалось просто, а вот дальше пошли сюрпризы. Через curl сообщения уходили, из Node.js — нет. Сертификаты API MAX использует российскую цепочку сертификатов, и Ubuntu сначала отказывалась её проверять. Я установил Russian Trusted Root CA и Sub CA — curl заработал. Но Node.js продолжал не доверять цепочке: у него свой взгляд на trust store. Решением стала переменная NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt, которую я закрепил в systemd-юните сервиса, чтобы она переживала перезапуски. Системный curl уже работает, а Node требует отдельной настройки — классическая ловушка, на которую я потратил заметную часть вечера. Принцип: MAX только наблюдает Главное архитектурное решение — уведомления не участвуют в покупке. Модуль подключён как наблюдатель: он смотрит на уже принятые системой решения и отправляет сообщение. Если MAX недоступен, отвечает ошибкой или тормозит — это только запись в лог. Create, pay и сверка заказа не зависят от результата отправки. Таймаут короткий, повтор один и только при сетевой ошибке или 5xx. Каждое событие отправляется не более одного раза: повторный polling не спамит. Отдельно — безопасность. В сообщения не попадают ключи, токены, raw payload и stack trace, а UID маскируется: 56160093 превращается в 56****93. Сообщения для человека Внутри системы события называются ORDER_RECEIVED, PAYMENT_UNKNOWN, REVIEW_REQUIRED. Владельцу магазина эти слова ничего не говорят, поэтому я сделал русские тексты: «🛒 Новый заказ», «✅ Заказ выполнен», «🚨 Статус оплаты неизвестен», «💳 Низкий баланс FoxReload», «🛑 AUTO LIVE аварийно остановлен». Причины переводятся словарём: PRICE_ABOVE_LIMIT становится «Цена поставщика выше допустимого лимита». Для диагностики последней строкой остаётся «Технический код: PAY_REJECTED_422». Тестирование без реальных денег Проверять уведомления настоящими покупками я не хотел. Поэтому у инструмента есть preview — все сообщения показываются локально без сети, и test-all — демонстрационный набор в MAX с пометкой «🧪 ТЕСТ — не реальное событие». Затем появился безопасный E2E: npm run e2e:safe. Он проходит путь заказ → товар → вариант → UID → mapping → цена → маржа → баланс → readiness → решение AUTO LIVE → MAX, но запускает реальный сервис на локальных заглушках, а create и pay блокируются. Итог: решение WOULD BUY, create и pay пропущены, потрачено 0 ₽, SAFE E2E PASSED. Результат MAX стал внешним монитором магазина: заказ, блокировка, проблема с оплатой или низкий баланс приходят в мессенджер сразу, а бот не вмешивается в денежную логику. Вывод Для меня эта задача была не про «подключить Telegram-подобного бота», а про наблюдаемость автоматического магазина: отдельный слой, который сообщает о происходящем, но не может ничего сломать. Fail-safe архитектура, TLS на Linux, systemd, API-интеграция и тесты без риска для денег — именно из таких деталей складывается надёжная автоматизация. Хэштеги: #автоматизация #backend #NodeJS #Linux #systemd #API #безопасность