alexalexes

Проблемы с очередью платежей.
Ограничения API платежного шлюза.
Блокировки или задержки на стороне сервера или базы данных.
Конфликты с кэшированием или балансировкой нагрузки.

Ну, так закажите аудит логов платежной части сайта, до входа в режим оплаты и есть ли возвраты на страницу сайта после оплаты.
Если до входа нет скриптов трекинга поведения пользователей в браузере, то пусть разработчики прикрутят их, тогда сможете получать логи до самого последнего шага перед оплатой.
Нет никакой мистики, вы просто не запрашиваете необходимый анализ при аномальных случаях, или не знаете в какой форме хотите получить отчет по логам сервера.
Но для этого нужно обеспечить необходимый уровень журналирования на сайте (логирование), чтобы проводить такой анализ. Это нужно обговаривать в ТЗ.

На каком сервере разместить обработку защищенного алгоритма (тот который обрабатывает 30 значений)?

Тут нужно проанализировать реквизиты тестируемого человека, не привязаны они к персональным данным пользователя.
Если какая-та совокупность реквизитов получает признаки персональных данных, то простым хранением этих сведений абы где вы не отделаетесь. Вам придется изучить с юристом регламенты ФСТЭК и ФЗ о персональных данных, чтобы не нарушить закон.

Насколько целесообразна регистрация пользователей сразу или дать возможность бесплатно провести тест работы алгоритма?

Зависит от вашей бизнес модели, как вы хотите зарабатывать деньги и завлекать пользователей - это работа маркетолога.

И как сделать абонентскую плату 100 руб в месяц?

Тут у вас появляется обязанность завести кассовый сервис, и стать юр. лицом, чтобы правильно отчитываться налоговой.

Сколько будет стоить разработка такого сайта?

Сущие копейки, допустим, 100К руб.
Тех задание будет, в основном, включать работу по адаптации админ. панели популярной CMS.
Вопрос лишь в том, хотите ли вы вести дела, как маленький предприниматель, следить за налоговой отчетностью, отслеживать законодательство в плане того, что там изменилось по ПДн, и нужно ли чего передавать третьим лицам.

1. Активные пользователи хранятся там же, где неактивные пользователи - в нормальной реляционной СУБД, а не редис.
Активный пользователь отличается от неактивного, наличием даты-время подтверждения эл. почты. В этой же записи пользователя в отдельном атрибуте храните сгенерированный хеш-код для подтверждения, который используете в ссылке.
2. В неавторизованном состоянии предусматриваете возможность повторной высылки кода подтверждения на указанный эл. адрес. (Прямо отдельная форма).
3. Любые действия, связанные с высылкой письма должно подтверждаться проверкой пользователя, что он человек (капча, или использование сторонних сервисов проверки).
4. Скрипт, который обрабатывает ссылку подтверждения почты тоже должен иметь защиту от ддоса.
Все.

Пока ТЗ - ХЗ. Берете любую CMS устанавливаете ее - это ваша админ-панель.
Далее, устанавливаете плагин для этой CMS для ведения списка пользователей, которые не пользователи CMS.
Или можете использовать список пользователей CMS с усеченной ролью, в которой нет доступа к CMS.

Вот в таких ситуациях я понимаю, зачем придумали VueJS )).
Если серьезно, то чтобы решить задачу в рамках существующего стека, то где-то тут нужно прервать поток выполнения JS функцией setTimeout с нулевым временем ожидания, и продолжить работать с инпутами внутри вызываемой функции setTimeout. Это позволит передать управление браузеру, чтобы он успел отрисовать то, что закинуто в DOM через innerHTML:

if (code[i] == nameBlock) {
                currentBlock.innerHTML = callback();
                setTimeout(function(currentBlock, inputs)
     {
  
for (var j = 0; j < currentBlock.querySelectorAll('input').length; j++) inputs.push(currentBlock.querySelectorAll('input')[j].getAttribute('name'));

                callback(null, null, inputs);
}, 0, // нулевое время setTimeout
currentBlock, inputs // проверьте, чтобы правильно передавались аргументы внутрь setTimeout
);
        break; // тут, наверное, можно прерывать внешний цикл, раз нашли нужное
            }

Если брать, например, библиотеку owl carousel, то там разработчики начальный слайд помещают в центр фактического расположения узлов списка слайдера, при прокручивании происходит смена позиций крайних слайдов этого списка.
Так обеспечивается непрерывность прокручивания, и пользователь никогда не дойдет до конца узлов списка.
Особый случай, когда область просмотр слайдов больше чем количество слайдов (можно ведь просматривать по 2-3 слайда одновременно), тогда нужно обеспечивать дубликатами слайдов список слайдов, чтобы обеспечить непрерывность.

Фиксируйте на сервере, когда игрок вошел в определенное состояние. И каждый раз, когда он запускает игру, проверяйте запросом, в каком он состоянии и, соответственно, рисуйте соответствующий интерфейс.

<input id="settime" type="time" step="1" />
Ключевой параметр step - он позволяет открыть градацию секунд во всплывающем интерфейсе.

Нет, только ручками править шаблоны.
Если сайт совсем древний, то вам еще воевать со статическим контентом, чтобы его как-то затащить в некое подобие шаблонов, чтобы сделать адаптивные блоки.

Вообще, в классическом вузе преподам все равно, в каком окружении вертится проект. Они в него даже заходить не будут.
Важно написать отчет, правильно продемонстрировав возможности выходного продукта по скриншотам и комментариям. В конце отчета вставите простыню кода из всех файлов в виде главы-приложения.
Все, печатаете отчет. Одна копия отчета отправляется преподу на подпись. Другая - после защиты работы сжигается в мусорном ведре вместе с флешкой, на которой записаны исходники проекта (сарказм).

У вас полностью клиентский контент без серверной части.
Передаете каталог с файлами любым способом. Только убедитесь, что все необходимые ресурсы страниц имеют относительные ссылки, и они располагаются в данном каталоге.

Не будут регистрироваться, если нет цели проверить, как вы реализовали именно этот функционал.
Вы должны иметь возможность предоставить максимальный функционал для обзора в режиме "галопом по Европам" по одной единственной ссылке. Можете авторизовать пользователя по какому-нибудь токену, переданный через get-параметр. Учетная запись и сервис должны быть нагружены тестовыми данными. Если где-то выводятся какие-то сведения - то они не должны быть пустыми.

Есть какие-то способы просто по внешнему виду или другим признакам узнать движок сайта?

Это бесполезная информация для разработчика.
Нужно описывать функционал, требования и ограничения - составлять техническое задание.
В какой движок это завернет разработчик - это на его вкус и на ваш кошелек.
Вас только должно интересовать, сколько будет это стоить на предложенном разработчиком варианте реализации, и насколько проблемно это будет поддерживать в дальнейшем.

они написаны только на HTML, CSS, JS

Если бэкенда нет, то можно использовать любую бесплатную площадку для размещения сайтов, например, ucoz.ru.
Вы будете ограничены архитектурой конструктора сайта, и отображением рекламы, но тем не менее, у вас будет возможность выкладывать ресурсы html страницы.

На любом, где не предусмотрена авторизация, нет никаких счетчиков посещений, отсутствуют любые iframe-модули сторонних сервисов, и сервер ни для каких операций не открывает сессию пользователя.
Но таких сайтов почти не осталось. Без кук любой сайт теряет свою основную функциональность, и превращается в чемодан без ручки как для пользователя, так и для владельца сайта.

запрос для получение ссылки с использованием прокси, но я так подумал, а разница

Да, вы своей серверной частью берете головняк, чтобы запрос выходил через нужный IP и для конечного сервера пользователь казался валидным по фингерпринту. В этом и прелесть защиты, чтобы вы потратились на инфраструктуру для проброса чужого контента.