Тестирование криптошлюза перед запуском

Что на самом деле доказывает тестовый режим?

Что ваш код правильно разговаривает с API. Платежи создаются, вебхуки срабатывают, подписи проверяются, заказы переходят в оплаченные. Это стоит иметь, и это лёгкая половина.

Чего он не доказывает — как провайдер ведёт себя, когда что-то идёт вкось, потому что большинство тестовых сред симулируют счастливый путь и мало что ещё. Сбои, которые имеют значение, связаны с реальной сетью, реальным кошельком и реальной суммой, и несколько провайдеров не дают способа вызвать их синтетически.

Какие живые тесты стоит провести?

Три, все дешёвые, все до запуска, а не после.

Намеренная недоплата примерно на 2%. Отправьте чуть меньше суммы инвойса. Посмотрите, что делает провайдер, что получает ваш вебхук и в каком состоянии оказывается заказ. Это самое частое исключение в реальности и наименее задокументированное поведение в категории.

Платёж после истечения срока. Дайте инвойсу истечь, потом оплатите. Покупатель отправил реальные деньги по заказу, который ваша система уже закрыла. Узнайте сейчас, зачислит ли провайдер их, удержит или ничего не сделает.

Отправка не в ту сеть. Отправьте верный актив через сеть, за которой провайдер не следит. Узнайте, восстановление автоматическое, ручное или невозможное, и запишите ответ для поддержки до того, как он понадобится покупателю.

Чек-лист интеграции описывает код, который эти тесты проверяют.

Что проверить на выходе из тестового режима?

Что тестовые и боевые учётные данные действительно различаются и ничто в конфигурации тихо не откатывается на тест. Платёжный поток, указывающий на тест в продакшене, ломается худшим образом — делая вид, что работает.

Что эндпоинт вебхуков доступен из публичного интернета и не спрятан за allowlist, привязанным к IP, который провайдер однажды сменит. Гайд о вебхуках описывает остальные требования к обработчику.

Что у вас есть сверка по расписанию, а не только путь колбэков. Колбэки теряются, и иначе первым, кто это заметит, будет покупатель.

Как выглядит первый день?

Следите за тремя вещами. Вебхуки приходят и подтверждаются. Проведённые суммы совпадают с заказами. Может ли кто-то вне инженерной команды найти отчёт о расчётах, не спрашивая.

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

Что если провайдер это затрудняет?

Считайте это данными. Провайдер, чья тестовая среда не умеет симулировать недоплату, а документация не описывает поведение, рассказал вам кое-что о следующих двух годах. Каталог фиксирует, что публикует каждый провайдер, и картина в этой колонке — честный предиктор того, как пойдут разговоры с поддержкой.

Почему живые тесты так дёшевы

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

Против этого: обработка недоплат, открытая в первую загруженную неделю, с ждущим покупателем и без уверенности в том, что делает провайдер. Асимметрия настолько велика, что пропуск тестов трудно оправдать чем-либо, кроме того, что никто о них не подумал.

Чек-лист для переключения

Тестовые и боевые учётные данные разделены, без тихого отката. Эндпоинт вебхуков доступен из публичного интернета, не за allowlist, привязанным к IP, который сменится. Задача сверки запланирована и отчитывается куда-то видимое. Инструкция для платежа, пришедшего без подходящего заказа.

И один человек, кроме разработчика, который может найти отчёт о расчётах. Этот пункт пропускают, и он вызывает проблему через три месяца.

Первая неделя

Следите за путём колбэков и сверкой независимо. Если они сходятся, интеграция здорова. Если расходятся, вы нашли ошибку сейчас, а не в конце квартала.

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

О чём говорит тестовая среда провайдера

Умеет ли она симулировать недоплату и истечение срока — говорит о том, насколько серьёзно провайдер относится к исключениям, с которыми его мерчанты реально столкнутся. Тестовый режим, гоняющий только счастливый путь, — честный предиктор качества документации в остальном.

Куда дальше

Чек-лист интеграции описывает сборку, которую эти тесты проверяют, а гайд о вебхуках — обработчик, который скорее всего откажет под нагрузкой. Статья о недоплате описывает исключение, которое стоит протестировать первым.

Документирование найденного

Запишите, что провайдер реально сделал в каждом сбойном случае, потому что этого нет в его документации и через полгода не будет ни в чьей памяти.

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

Что перепроверять после любого изменения

Обновление версии у провайдера, ротация учётных данных или изменение вашей собственной кассы. Сбойные сценарии дёшево прогнать заново, и именно их изменение скорее всего сломает тихо.

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

Базовый принцип умещается в одно предложение. Тестовый режим доказывает, что ваш код верен; живые тесты доказывают, что провайдер ведёт себя так, как вы предположили, — и только одно из этих двух предположений когда-либо оказывалось дорогим.