Отладить оплату, не имея возможности воспроизвести отказ, почти невозможно. Именно поэтому тестовые карты Stripe существуют как отдельный, управляемый набор: часть значений гарантированно приводит к успешной операции, часть — к заранее известной ошибке банка, а отдельные карты нужны для проверки подтверждения личности. Ниже — зачем поставщики платежей вообще публикуют такие номера, как устроены их сценарии и почему список нужно смотреть в актуальной документации, а не переписывать из чужих статей.
Почему поставщик выдаёт свои тестовые карты
Любая платёжная интеграция — это разговор двух сторон. Ваша система собирает данные и передаёт их дальше, а поставщик решает, что с ними делать. Чтобы этот разговор можно было тестировать, поставщику нужно уметь управлять результатом: по одному номеру вернуть успех, по другому — отказ по недостатку средств, по третьему — потребовать дополнительное подтверждение.
Поэтому в тестовом режиме номер карты превращается в подобие команды. Вы не «проверяете карту» — вы просите сервис воспроизвести нужное поведение. Это принципиально отличается от реального режима, где значение имеют состояние счёта и решение банка.
Чем тестовый режим отличается от рабочего?
Разница не только в адресе сервера. В тестовом режиме реквизиты существуют только внутри инфраструктуры поставщика, не покидают её и не попадают в банковскую сеть. Никаких денег, никаких запросов к эмитенту, никаких следов в выписке.
Из этого следует важное правило: тестовый ключ нельзя использовать в рабочей конфигурации, а рабочую карту нельзя подставлять в тестовый режим. Перепутать их легко, а последствия разные: в первом случае вы рискуете совершить настоящую операцию, во втором просто получите отказ, из-за которого можно долго искать несуществующий дефект.
Что можно смоделировать с помощью тестовых карт
Набор сценариев, который публикует поставщик, обычно шире, чем «успех и ошибка». Практически полезны следующие группы.
| Группа | Что проверяет |
|---|---|
| Успешная операция | Основной путь оплаты и корректность его обработки |
| Отказ банка | Поведение формы и сообщение при неудаче |
| Требование подтверждения | Переход на страницу проверки личности и возврат обратно |
| Некорректные данные | Отдельно: номер, срок и код проверки |
| Спорные ситуации | Возвраты, повторные попытки, отмена операции |
Последняя группа особенно ценна: успешную оплату обычно уже проверили, а вот корректно ли система обрабатывает возврат или отменённый платёж, часто неизвестно.
Нужен ли определённый номер, чтобы получить успех?
Для успешной операции существует широко известный номер из шестнадцати цифр, начинающийся с четвёрки, в котором остальные цифры — повторяющаяся пара. В тестовом режиме он принимает любой будущий срок действия и любое трёхзначное значение поля с кодом проверки.
Однако заучивать конкретные значения не стоит. Главное — понимать логику: номер в тестовом режиме выбирает сценарий, а не банк. Если ваш код опирается на один определённый успешный номер и не проверяет остальные сценарии, вы тестируете не интеграцию, а её витрину.
Как связать тестовые карты с собственными данными
Тестовые значения поставщика не отменяют потребности в собственных наборах данных. Номера нужны для проверки поведения платёжного шлюза, а для проверки самой формы — маски ввода, подсказок, длины, неизвестного начала — удобнее свои значения. Их можно получить в генераторе: он выдаёт структурно корректные номера, которые заведомо проходят проверку формы, но никогда не выпускались ни одним банком и не подходят ни для одной реальной операции.
Держите эти два набора раздельно. Смешивание приводит к путанице: непонятно, отказ пришёл от шлюза или от вашего собственного правила проверки.
В работе с тестовым режимом повторяются пять ошибок, и все они дешёвые в исправлении:
- Тестовый ключ, оставшийся в рабочей конфигурации. Обнаруживается случайно и в самый неудачный момент.
- Проверка только успешного сценария. Отказ, повторная попытка и таймаут остаются непроверенными.
- Один номер на все случаи. Тогда непонятно, какое именно правило сработало в конкретном тесте.
- Забытый сценарий 3-D Secure. Возврат со страницы подтверждения — отдельный путь, который легко не заметить в тестах.
- Копирование списка карт из чужой статьи. Наборы меняются, а бесконечно поддерживать чужие таблицы никто не обязан.
Как понять, откуда пришёл отказ?
Это самый частый вопрос при отладке, и на него стоит ответить до того, как вы начнёте менять код. Отказ может появиться в трёх разных местах: в самой форме, в вашем сервере до обращения к поставщику и в ответе поставщика. Внешне все три выглядят одинаково — пользователь видит одно и то же сообщение.
Разделить их помогает порядок действий. Сначала проверьте, ушёл ли запрос вообще: если форма отвергла данные сама, обращения не было, и это ошибка проверки на клиенте. Затем посмотрите, что ответил ваш сервер: иногда он отклоняет операцию по своим правилам, например по сумме заказа или по ограничению на валюту. И только потом разбирайте ответ поставщика, где причина указана машинным кодом.
Полезно договориться о едином формате: каждому отказу присваивается собственный код, и этот код попадает и в интерфейс, и в журнал. Тогда вопрос «откуда отказ» решается за несколько секунд, а не за полчаса чтения логов.
Что важно разработчику
Тестовые значения пригодятся и после того, как форма заработала, — просто в другой роли. Их удобно использовать для проверки обновлений: если вы меняете вёрстку поля или обновляете библиотеку, быстрый прогон на тестовом значении покажет, что базовый сценарий не сломан. Ещё одна полезная привычка — держать рядом два набора: один короткий, для повседневных проверок, второй полный, для регрессии перед выпуском. Короткий не должен занимать больше пары минут, иначе его перестанут запускать, а полный стоит прогонять целиком, включая неуспешные сценарии: именно они чаще всего ломаются при изменениях в обработке ответов.
Соберите сценарии в один перечень и держите его рядом с тестами — это избавляет от ситуации, когда половина отказов проверена, а половина нет. Для каждого значения зафиксируйте: что оно моделирует, какой код ошибки ожидается и как система должна на это отреагировать.
Отдельно продумайте 3-D Secure. Этот путь состоит из трёх частей: уход со своей страницы, проверка личности у поставщика и возврат обратно — причём пользователь может вернуться по кнопке «назад», закрыть вкладку или обновить страницу. Проверьте все три варианта возврата: они часто дают разное состояние заказа. Ещё один частый дефект: заказ считается оплаченным до получения подтверждения от поставщика. В тестовом режиме это легко пропустить, потому что ответ почти всегда приходит мгновенно.
И заведите правило: результат операции определяется ответом сервиса, а не тем, что браузер вернулся на страницу успеха. Клиентская страница — лишь отображение, а истина живёт в ответе сервера и в состоянии заказа у поставщика.
Что делать дальше
Сверьте свой набор сценариев с актуальной документацией поставщика — она меняется чаще, чем кажется, и в ней же указаны точные коды ошибок для каждого значения. Затем пройдите оставшиеся проверки по чек-листу платёжной формы, а если ваша работа касается не только оплаты, посмотрите материал про проверку регистрации по почте — приёмы там похожие.