Когда в платформу приходят крипто-выплаты, QA-команда обычно применяет тот же подход, что и к фиатным: ввёл сумму, нажал отправить, проверил статус. Это работает примерно до первого инцидента.
Блокчейн не возвращает деньги. Неправильный адрес, неправильная сеть, транзакция зависла без подтверждений — всё это либо необратимо, либо решается через саппорт провайдера за несколько дней. Тестирование крипто-выплат в gambling требует понимания, как блокчейн работает на базовом уровне — без этого сложно придумать правильные негативные сценарии.
Валидация адресов: первая и важнейшая линия защиты
Это самый критичный момент во всём тестировании крипто-транзакций. Если адрес неправильный и деньги ушли — вернуть невозможно. Поэтому валидация адреса — не просто UX-задача, а обязательный барьер безопасности.
Сценарии, которые надо проверить явно:
Адрес правильного формата, но несуществующий — система должна его принять (это нормально для блокчейна, средства просто никогда не дойдут до получателя). Это не баг, но стоит понимать, что валидация формата ≠ валидация существования адреса.
Адрес неправильного формата — должен быть отклонён немедленно с понятным сообщением. Не «ошибка сервера», не молчаливый сброс формы.
Адрес от другой сети — это самый частый источник потерь. BTC-адрес в поле для ETH. TRC20-адрес вместо ERC20. USDT существует в нескольких сетях, и визуально адреса TRC20 (TRON) и ERC20 (Ethereum) очень похожи. Пользователи путают их постоянно — не потому что невнимательные, а потому что разница неочевидна. Система должна чётко показывать выбранную сеть и валидировать адрес именно под неё, а не позволять любой строке пройти формальную проверку.
Адрес смарт-контракта вместо кошелька — некоторые контракты не принимают прямые переводы. Средства могут зависнуть навсегда. Хорошая система либо предупреждает, либо блокирует такие адреса.
Copy-paste с пробелами — форма должна trim'ить пробелы в начале и конце строки или явно их отклонять. Это мелочь, но она воспроизводится регулярно на мобильных устройствах.
Статусы и подтверждения: крипто не работает как фиат
В фиате транзакция либо прошла, либо нет. В блокчейне всё сложнее: транзакция может быть отправлена, видна в сети, но ещё не считаться завершённой.
Жизненный цикл выглядит так: broadcast — транзакция отправлена в мемпул, но ещё не включена ни в один блок. pending с N подтверждениями — в блокчейне, ждёт. confirmed — нужное количество подтверждений набрано, средства засчитаны. failed — транзакция упала, обычно из-за недостаточной комиссии.
Что проверять: депозит должен засчитываться только после N подтверждений, не раньше. Это защита от double-spend атаки — пользователь не должен получить средства, пока транзакция не стала необратимой. Сколько подтверждений требуется — зависит от монеты: у Bitcoin обычно 3–6, у Ethereum 12–30, у TRON — секунды, буквально.
Пользователь должен видеть прогресс. Не просто «в обработке», а «3 из 6 подтверждений» — это снижает количество обращений в поддержку.
Транзакция застряла в pending дольше обычного — есть ли таймаут? Что он делает? Автоматически возвращает средства или создаёт задачу для ручной обработки? Оба варианта могут быть правильными — важно, что поведение задокументировано и именно оно реализовано.
Комиссии: движущийся элемент, который часто ломает логику
Комиссия сети — это не фиксированная величина. Она меняется в зависимости от загрузки блокчейна, иногда в разы в течение часа.
Первый вопрос: кто платит? Если платформа берёт комиссию на себя — пользователь видит итоговую сумму к получению. Если комиссия вычитается из суммы вывода — пользователь должен видеть это явно до подтверждения, не после.
Граничный кейс: пользователь выводит минимальную сумму в момент high-load сети, когда комиссия высокая. Может ли комиссия превысить сумму вывода? Что происходит в этом случае? Транзакция блокируется? Пользователь получает предупреждение? Или система молча отправляет транзакцию и она зависает без шансов на выполнение?
Особо внимательно: вывод всего баланса в крипте. Если комиссия не зарезервирована заранее — транзакция не пройдёт или пользователь получит меньше ожидаемого. Это регулярный источник жалоб.
Spike комиссии после нажатия «вывести»: пользователь нажал, система отправила запрос, за эти 2–3 секунды сеть резко загрузилась и комиссия выросла в три раза. Что происходит? Транзакция уходит с пониженным приоритетом и зависает? Или система пересчитывает и переспрашивает?
Курс и момент его фиксации
Если пользователь выводит в фиате, а платформа конвертирует в крипту для отправки — курс критически важен.
Фиксируется ли курс в момент создания запроса на вывод или в момент фактической отправки транзакции? Разница может составить несколько процентов при волатильном рынке. Пользователь должен знать, по какому курсу произошла конвертация — это должно быть отражено в истории транзакций.
Если платформа использует несколько источников курса (агрегатор + резервный), что происходит при расхождении между ними? Есть ли максимально допустимый spread, при котором транзакция блокируется до ручной проверки?
Разные монеты — разные источники курса. USDT, BTC, ETH должны тянуть каждый свой актуальный курс, а не общий «крипто-курс».
Неуспешные транзакции: «просто вернуть» не всегда работает
Это самая неприятная часть тестирования крипто-транзакций, потому что блокчейн необратим, и «просто откатить» нельзя.
Транзакция упала из-за недостаточной комиссии — средства должны вернуться на внутренний баланс пользователя. Звучит очевидно, но логика возврата при падении транзакции в блокчейне требует дополнительной синхронизации: сервис должен отслеживать статус отправленных транзакций и реагировать на failed.
Транзакция зависла в мемпуле на несколько дней — у платформы должна быть задокументированная политика: ждать, сделать RBF (replace-by-fee, если сеть поддерживает), или отменить и вернуть средства. Тестируй, что реализованный вариант работает именно так.
Технический сбой в момент отправки — сервис упал после того, как транзакция была broadcast в блокчейн, но до того, как статус обновился в базе. После перезапуска сервис должен синхронизировать статус из блокчейна, а не создавать новую транзакцию. Это идемпотентность на уровне blockchain-взаимодействия, и без неё двойные выплаты — это вопрос времени.
Тестирование в нескольких сетях для одной монеты
Если платформа поддерживает USDT на ERC20 и TRC20 одновременно — это не удвоение одного и того же сценария. Это два разных протокола с разным поведением.
Каждая сеть тестируется отдельно: скорость подтверждений разная, комиссии разные, минимальные суммы могут отличаться. Депозитный адрес в платформе — один на все сети или разный для каждой? Это принципиально разные архитектурные решения, и у каждого своя логика тестирования.
Пользователь при вводе адреса выбрал не ту сеть — есть ли предупреждение? Или система принимает любой адрес правильного формата независимо от выбранной сети?
Тестирование крипто-транзакций в gambling-платформах — это работа на стыке QA и понимания блокчейна. Без базового знания того, как работают подтверждения, мемпул и комиссии, сложно придумать правильные негативные сценарии. Зато после первого хорошего тест-плана — это просто чеклист, который прогоняется при каждом релизе.
О тестировании фиатных платёжных систем в казино — в отдельном чеклисте.