📋 Чек-лист: оплата

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

В чек-листе про блокерные проверки и требования. Если есть что добавить, то пиши в комментариях, не пропустим баги вместе :)

Получить реальную карту для тестирования. Как только слышишь про тестирование оплаты, задавай вопрос: "С какой карты платим?". Понятно, что скорее всего будет тестовая среда, будет эмуляция и там достаточно использовать тестовые карты с атрибутами реальной. Но не забывай, как минимум блокерные кейсы надо будет проверить на проде. Также будет прохождение регресса, тут не обойтись без реальной тестовой карты. На берегу обсуди выдачу реальной-тестовой карты.

Никогда не используй свою банковскую карту для тестирования!

Тестовая карта по алгоритму Луна. Это контрольная сумма любой карты, которая говорит о валидности номера карты. Эти карты нужны будут в тестовом окружении. Подробнее про алгоритм почитай на википедии (см. Алгоритм Луна). Руками карты можно не придумывать, для это есть сервис CartoVed, а БИНы банков можно взять в сервисе iBankie (т.е. берешь БИН ВТБ с iBankie, а на CartoVed генерируешь карту с этим БИНом).

Сгенерируй пачку валидных и невалидных карт. В принципе можно не сохранять пул карт, но если тебе нужны карты с определенным БИНом или датой, то лучше иметь список готовых. Экономия времени.

Длина карты бывает от 12 до 18 символов. Это для России. Учитывай местные правовые документы (ГОСТ, ISO) при планирование тестов. Вот, например, ГОСТ Р 50809-95 для РФ, где говорится, что длина может быть до 18 символов.

Учитывать платежные системы. Если по какой-то причине тестировал только с глобальными платежными системами (далее ПС), то при релизе тебя может ждать неприятный сюрприз - система блочится при использовании, например, национальной ПС.
Разная длина CVV/CVC. Имей в виду, что где-то CVV 3 символа, а где-то 4. Плюс, что помимо CVV и CVC, есть CVP. Это важный момент при указании этих сущностей в тексте, например, на форме оплаты.
Многие банки требуют верификацию оплаты 3DS-кодом. Этот код высылается чаще всего на телефон СМСкой, редко в виде пуш-уведомления. Нужно учитывать это в тестах и проверки ТЗ, например, чтобы не забыли сделать дизайн экрана ввода 3DS-кода или не забыли подключить библиотеки показа СМС над клавиатурой по клику в поле ввода.
Ввод просроченного 3DS-кода или случайного. Пояснение не требуется. Хотя это проверяется на стороне банка, но вдруг ты тестируешь именно с банковской стороны ;)
Отдельная почта для чеков или настроенный фильтр. Часто после оплаты нужно получить электронный-чек. Чтобы четко понимать, что чек пришел сразу после оплаты и отследить хронологию, нужно либо завести отдельный ящик или настроить фильтр для сбора чеков.

Никогда не используй личную и рабочую почту для получения чеков после тестовой оплаты!

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

Если не знаешь, что такое сниффер - подписывайся на канал, подробно рассмотрим.

Протокол HTTPS. Железное правило - вся оплата только через защищенный протокол.
Комбинация корректных и некорректных данных, например, корректный номер карты и неверный CVV/CVC. Как ты помнишь из теории, чем больше включается параметров подающихся на вход, тем больше ошибок получаем на выходе. Поэтому комбинируй.
Внимательно читай ТЗ. Там будет то, что я не рассказал. Скорее всего это требования к продукту, например, возможность привязки к сервису.