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