Когда в казино-платформу подключается новый game provider — NetEnt, Pragmatic Play, Evolution, любой другой — кажется, что работы немного: проверить, что игра открылась, ставка прошла, выигрыш выплатился. На деле это одна из самых технически насыщенных зон во всём тестировании игровых платформ.
Интеграция game provider — это сложная связка: оператор управляет балансом и сессией, провайдер управляет игрой. Между ними — API-протокол, обычно Seamless Wallet или Transfer Wallet. Любой сбой на стыке приводит либо к потере денег пользователя, либо к игре без возможности завершить раунд, либо к рассогласованию баланса. Провайдер не тестирует вашу сторону. Вы не контролируете его. Единственное, что защищает — правильный тест-план.
Тестирование запуска игры: сессия и авторизация
Всё начинается с того, как провайдер получает токен сессии — и как этот токен живёт дальше.
Успешный запуск — это не один кейс. Это запуск через браузер, через мобильный, в разных локалях, с разными типами пользователей (новый, верифицированный, с бонусом, с ограничениями). Каждый контекст может влиять на параметры, которые передаются провайдеру.
Истёкший токен — пользователь открыл игру, оставил вкладку на час, вернулся. Должен быть редирект или понятное сообщение, не белый экран с сетевой ошибкой. Это чаще всего и происходит, если не проверить явно.
Два одновременных запроса на открытие одной игры с одного аккаунта — один должен выиграть, второй получить ошибку или закрыть первую сессию. В каком именно порядке — зависит от бизнес-требования, но поведение должно быть детерминированным, а не случайным.
Токен сессии не должен передаваться в URL в открытом виде. Это звучит базово, но встречается — и это уязвимость: любой, кто видит URL в истории браузера или в логах сервера, получает активный токен.
Юрисдикционные ограничения — это отдельный пласт. Игра заблокирована для конкретной страны: провайдер не должен её запускать даже при прямом обращении к API, минуя фронтенд. Возрастные ограничения, ограничения по категории игр для конкретного рынка — всё это должно применяться на уровне бэкенда, не только UI.
Синхронизация баланса: самое важное в интеграции
Это сердце всей интеграции game provider. Каждая ставка и каждый выигрыш — это запрос от провайдера к оператору на изменение баланса. Если что-то пошло не так, пользователь либо теряет деньги, либо играет на несуществующие.
Seamless Wallet — провайдер запрашивает баланс и отправляет транзакции в реальном времени через API оператора. Это быстрее и сложнее с точки зрения тестирования.
Что проверять: провайдер запрашивает баланс перед каждым раундом — ответ должен быть актуальным, не кэшированным. Debit-запрос (списание ставки) должен обрабатываться ровно один раз. Credit-запрос (начисление выигрыша) — ровно один раз. Дублирующийся запрос с тем же transaction ID должен получить идемпотентный ответ: не ошибку, не повторное списание, а повторный 200 OK с тем же результатом.
Запрос с неизвестным transaction ID при credit — это нестандартная ситуация, которая возникает при сбоях. Система должна её обработать: зачислить выигрыш и вернуть корректный ответ, или зафиксировать аномалию и уведомить команду.
Transfer Wallet — оператор переводит часть баланса в кошелёк провайдера до начала игры, после окончания сессии остаток возвращается. Проще в транзакционном смысле, но есть свои углы: что если пользователь закрыл игру без явного закрытия сессии? Остаток завис в кошельке провайдера? Есть ли таймаут и автоматический возврат?
Завершение раунда и поведение при сбоях
Это самая интересная зона тестирования с точки зрения game provider QA.
При нормальном завершении всё выглядит просто: раунд завершён, баланс обновлён. Но надо проверить граничный кейс — большой выигрыш, джекпот. Система должна корректно обрабатывать суммы на несколько порядков больше обычных. Бывает, что при обычной ставке всё работает, а при выплате ×500 от ставки — переполнение типа данных.
Обрыв соединения в момент раунда — пользователь крутит слот, соединение прервалось. Провайдер хранит состояние незавершённого раунда. Пользователь переоткрыл игру — должен увидеть правильный результат, а не пустой экран и потерянную ставку. Сколько времени провайдер хранит незавершённый раунд? Обычно это задокументировано в спецификации интеграции. Проверь, что оператор корректно обрабатывает ситуацию по истечении таймаута — кредит всё равно должен прийти.
Ошибки на стороне оператора — это то, что провайдер тестировать не будет, а вы должны. Сервис оператора не ответил на debit-запрос в течение таймаута: провайдер не должен молча списать ставку и начать раунд — он должен вернуть ошибку и дать пользователю возможность попробовать снова. Сервис вернул 500 при credit-запросе: провайдер ретраит, идемпотентность обеспечивает отсутствие двойного зачисления. Оператор отвечает на balance, но не отвечает на debit: что происходит с раундом? Игра зависает? Пользователь видит ошибку? Ставка не списывается?
Bonus rounds, free spins и специальные транзакции
Это отдельный слой, который часто пропускают, тестируя только базовый paid spin.
Free spin — ставка равна нулю, но раунд всё равно происходит. Credit может прийти. Как обрабатывается нулевая ставка? Debit с суммой 0 — это валидный запрос или ошибка?
Bonus round внутри слота — это не отдельная игра, но это серия транзакций, часто с multiplier. Проверяй, что каждая транзакция в серии обрабатывается корректно и баланс сходится в конце.
Jackpot — отдельная транзакция большого размера поверх обычного выигрыша. Оба кредита должны прийти и обработаться. Иногда jackpot выплачивается через отдельный сервис — убедись, что оба пути задействованы в тесте.
Возврат ставки (refund round) — провайдер может вернуть ставку, если раунд завершился некорректно на его стороне. Это отдельный тип транзакции, который должен корректно обрабатываться: баланс возрастает ровно на сумму ставки, не на выигрыш.
RTP и проверка честности
Статистически тестировать RTP (Return to Player) на уровне QA нереально — нужны миллионы раундов. Но это не значит, что честность игр вне зоны QA.
Что реально проверить: провайдер предоставляет сертификат RTP для каждой игры — он есть, актуален, относится к конкретной версии игры. Для игр с Provably Fair — алгоритм верификации работает, пользователь может проверить результат раунда самостоятельно. История раундов доступна пользователю через личный кабинет — каждая ставка, каждый результат, каждый timestamp.
Для live-игр отдельно: видеозапись раунда должна быть доступна через поддержку в случае спора. Это требование большинства лицензирующих юрисдикций, и лучше убедиться в нём заранее, а не в момент первого спорного кейса.
Обновления SDK и обратная совместимость
Провайдеры обновляют протокол и SDK. Это происходит регулярно и требует регрессионного тестирования.
Новая версия SDK: обратная совместимость с уже сохранёнными транзакциями. Незавершённые раунды, созданные на старой версии, должны корректно завершиться на новой.
Новые поля в запросах провайдера — система оператора не должна падать при наличии неизвестных полей. Graceful degradation: игнорируй незнакомое, обрабатывай знакомое.
Устаревшие поля в ответах оператора — провайдер может перестать их отправлять. Убедись, что их отсутствие не ломает логику на стороне провайдера.
Новый тип транзакции (например, провайдер ввёл новый формат free spin) — система либо обрабатывает его корректно, либо логирует и помечает для ручной обработки. Молчаливое игнорирование с потерей данных — не допускается.
Тестирование интеграции game providers — это во многом работа на стыке двух систем, ни одна из которых полностью не принадлежит вашей команде. Именно поэтому нужен исчерпывающий тест-план: документировать граничные состояния, договариваться с командой провайдера о тестовых сценариях и не полагаться на то, что «они протестировали со своей стороны».
Про другие аспекты тестирования в gambling: критические баги в платёжных сценариях и чеклист по платёжным системам казино.