Первый раз, когда у нас в проде сломалась платёжка, я понял: тестировать казино как обычный интернет-магазин — это не просто неправильно, это опасно. Потому что там, где в e-commerce пользователь расстраивается и пишет негативный отзыв, в gambling пользователь теряет деньги. А иногда — и платформа тоже.
Платёжная система в казино — это не форма ввода карты. Это депозиты, выводы, заморозка средств при активных ставках, конвертация валют, крипто, хост-то-хост интеграции с провайдерами, комплаенс-ограничения по юрисдикциям и несколько слоёв антифрода. Тестирование платёжных систем в gambling требует отдельного подхода — и этот чеклист я собирал по живым кейсам, а не по документации.
Тестирование депозитов: что проверять на входе
Депозиты тестируют лучше всего — это видимая часть, её обычно покрывают в первом же регрессе. Но и здесь есть углы, которые пропускают.
Начни с базы: успешный депозит через каждый активный метод оплаты — отдельным тестом, не одним «проверил карту, значит всё ок». Минимальная сумма часто приходит из конфига провайдера, и QA об этом не знает, пока не столкнётся. Максимальная сумма — аналогично, плюс надо проверить, что именно происходит при попытке превысить: корректный отказ или 500.
Отдельно — жизнь платёжной сессии. Пользователь нажал «оплатить», ушёл на страницу провайдера и там завис. Через 15 минут вернулся. Сессия истекла — что видит? Баланс не изменился? Получил понятное сообщение, а не белый экран?
Статусы и переходы — это отдельная история. Платёж может зависнуть в pending по разным причинам: медленная карта, банк держит авторизацию, провайдер не ответил. Важно знать, что происходит дальше: есть ли таймаут, триггерится ли он, возвращает ли деньги. Провайдер вернул declined — пользователь должен увидеть человеческое сообщение, не код ошибки и не «что-то пошло не так».
Два кейса, которые всегда проверяю отдельно:
Двойной webhook. Провайдеры отправляют webhook повторно, если не получили 200 OK в ответ. Если сервис упал в момент обработки и поднялся — webhook придёт снова. Баланс должен пополниться ровно один раз, не два. Это идемпотентность, и её надо проверить явно.
Вкладка закрылась до коллбека. Пользователь оплатил, закрыл вкладку быстрее, чем пришёл редирект. Платёж прошёл, но страница «спасибо» не открылась. Баланс должен обновиться в фоне — и он обновится, если webhook обрабатывается корректно. Проверяй именно это, а не только синхронный путь.
Тестирование выводов: здесь ломается чаще
Выводы технически сложнее, потому что деньги идут в другую сторону — с платформы к пользователю. Любая ошибка означает либо потерю для платформы, либо недовольного пользователя с обоснованной претензией.
Вывод всего баланса — обязательный кейс. Не «вывести 100 из 500», а именно всё. Вывод при наличии незакрытой ставки — зарезервированные средства не должны попасть в запрос на вывод. Это звучит очевидно, но реализовано правильно примерно в половине случаев.
Конкурентные сценарии — это отдельный приоритет. Два параллельных запроса на вывод одновременно. Если оба проходят — у вас нет идемпотентности, и платформа теряет деньги. Подробно об этой race condition — в статье про критические баги в gambling. Вывод плюс ставка одновременно — баланс должен остаться консистентным. Проверяй явно.
Машина состояний вывода. Не все переходы тестируют — обычно проверяют pending → completed и на этом останавливаются. А что с pending → failed? Средства вернулись на баланс? Пользователь получил уведомление? Что происходит, если провайдер не ответил в течение N часов — есть ли таймаут? Если есть — что он делает: отменяет вывод, ставит его в очередь, ждёт бесконечно?
Ручное одобрение вывода — если оно есть в системе, проверь весь путь: оператор одобрил из админки, статус изменился, провайдер получил запрос, деньги ушли. Каждое звено.
Комплаенс при выводах — это зона, которую QA часто отдаёт «на откуп бизнесу». Не надо. KYC-ограничение на вывод — пользователь без верификации не должен вывести больше установленного лимита. Требование выводить только на тот метод, которым был депозит — если это требование юрисдикции, оно должно работать. Суточный и месячный лимит на вывод — проверяй граничные значения: ровно на лимите, на лимите плюс один рубль.
Конвертация валют и мультивалютность
Если платформа работает в нескольких валютах — это умножает количество сценариев и вероятность ошибок.
Курс фиксируется в момент создания транзакции или в момент обработки? Разница может быть существенной при волатильном рынке. Кто несёт разницу — платформа или пользователь? Это должно быть явно задокументировано и явно протестировано.
Округление — недооценённая проблема. При конвертации из USD в EUR и обратно итоговая сумма не должна уменьшаться из-за флоатинг-арифметики. На маленьких суммах это незаметно. На больших — пользователь замечает.
Минорные валюты — отдельный кейс. Японская иена, индонезийская рупия, вьетнамский донг — там нет дробной части, и суммы большие по значению. Если форматирование сделано неправильно, нули теряются. Отображение «¥1000» превращается в «¥1». Это не гипотетически — это случается.
Антифрод и лимиты: не чужая зона
Это та часть, которую QA часто считает «не своей». Антифрод — значит security, значит другая команда. На практике же именно QA первым замечает, что блокировка при превышении лимита молчаливая (пользователь не понимает, почему платёж не прошёл), или что временная блокировка метода оплаты не снимается через положенное время.
Проверяй: блокировка при превышении суточного лимита даёт понятное сообщение, не просто declined. Несколько неудачных попыток подряд приводят к временной блокировке метода — и эта блокировка снимается корректно. Карта, заблокированная системой, отклоняется на всех попытках, а не только на первой.
Фрод-скор по IP — если пользователь пришёл с известного VPN или прокси, что происходит? Блокировка? Дополнительная верификация? Молчаливый отказ? Любой из этих ответов может быть правильным — но надо знать, что именно задокументировано и именно это реализовано.
Возвраты и chargeback
Это редкий сценарий, который тестируют реже всего. Из-за этого он ломается тогда, когда особенно неприятно.
Провайдер инициировал возврат средств (refund) — баланс в платформе должен скорректироваться, статус транзакции обновиться. Если по правилам юрисдикции chargeback означает заморозку аккаунта — это тоже должно произойти автоматически, а не по тикету в поддержку.
Пользователь начал депозит, не завершил, ушёл. Вернулся через три дня. Сессия давно истекла, но запись в базе есть. Что показывает UI? Незавершённая транзакция зависла? Или система её корректно закрыла с таймаутом?
Этот чеклист — стартовая точка, а не финальный список. Платёжные провайдеры меняются, юрисдикции добавляются, пользователи находят пути, которые никто не предусмотрел. Дополняй его каждым новым инцидентом из прода — и через год у тебя будет живой документ, который реально работает.