Проверка приёма платежей: 16 тестов перед запуском

Что подготовить до тестирования

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

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

Команда заранее определяет, что считается выдачей покупки: отгрузка, активация доступа, начисление цифрового товара или передача заказа сотруднику точки. Тогда можно проверить, что это действие выполнено нужное число раз.

Матрица из 16 сценариев

Добавьте к таблице столбцы «Фактический результат», «Доказательство», «Ответственный» и «Исправление». Результат «пройдено» ставьте после проверки и интерфейса, и серверной записи.

№	Сценарий	Ожидаемый результат	Что сохранить как доказательство
1	Обычная успешная оплата	Подтверждённый платёж связан с правильным заказом; покупка исполняется один раз	Идентификаторы заказа и платежа, итоговый статус, запись выдачи
2	Двойное нажатие на кнопку оплаты	Повторное действие не вызывает двойную выдачу; обработка создания попыток соответствует документации	Число созданных попыток и число исполнений заказа
3	Новая попытка после завершившейся неуспешной	История прежней попытки сохранена; новая корректно связана с тем же заказом	Оба идентификатора попыток и связь с заказом
4	Покупатель отменил подтверждение	Заказ не становится оплаченным только из-за открытия страницы результата	Состояние попытки, состояние заказа, сообщение покупателю
5	Истёк срок действия попытки	Показывается понятный результат; замена попытки происходит по правилам интеграции	Срок действия, проверенный статус, результат повторного открытия
6	Вкладка закрыта после перехода к оплате	Обновление заказа не зависит от открытого браузера покупателя	Серверное уведомление или проверка, итог заказа без клиентской вкладки
7	Покупатель вернулся раньше уведомления	Интерфейс показывает ожидание, затем актуальный результат; преждевременной выдачи нет	Последовательность состояний страницы и заказа
8	Одно уведомление доставлено повторно	Событие учитывается по правилам интеграции; товар, доступ и баланс не изменяются повторно	Повторные события и единственная запись исполнения
9	Уведомления пришли в другом порядке	Система соблюдает допустимые переходы, не подменяя актуальное состояние устаревшим	Время получения событий и история переходов
10	Обработчик уведомления временно недоступен	Результат восстанавливается согласованным способом: повторной доставкой, запросом статуса или сверкой	Причина сбоя, действие восстановления и подтверждённый итог
11	Браузер отправляет изменённую сумму	Сервер сохраняет согласованную стоимость заказа и отклоняет некорректные данные	Ожидаемая сумма, полученный запрос без секретов и итоговая запись
12	Полный и доступный частичный возврат	Возврат связан с исходной операцией, имеет отдельный результат и не превышает допустимую сумму	Идентификаторы исходного платежа и возврата, суммы, статусы
13	Сверка за выбранный период	Успешные операции сопоставляются по ID и суммам; возвраты и комиссии выделены отдельно	Реестр, список заказов и перечень объяснённых расхождений
14	Оплата на разных устройствах	Фактически поддерживаемые телефон, компьютер и встроенный браузер проходят полный путь	Устройство, браузер, способ запуска и результат каждого прогона
15	Поиск обращения поддержкой	Сотрудник находит исходную попытку по заказу и объясняет следующий шаг без платёжных секретов	Учебное обращение, найденные записи и назначенный ответственный
16	Проверка доступа и измерения	Секретов нет в публичном интерфейсе и открытых журналах; заказы считаются отдельно от попыток	Результат проверки размещения ключей и описание событий аналитики

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

Как записывать полезное доказательство

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

Не ограничивайтесь отметкой «не работает». Полезная запись объясняет последовательность: какой заказ создали, какое действие выполнили, какое событие получили, что изменилось в заказе и почему результат отличается от ожидаемого.

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

Кто принимает результат

Разработчик проверяет создание попыток, статусы, обработку уведомлений и журналирование. Ответственный за бизнес подтверждает, что покупка выдаётся правильно и сообщения понятны. Финансовая команда сверяет суммы, комиссии и возвраты. Сотрудник поддержки проверяет поиск заказа и порядок эскалации.

Для торговой точки добавьте сотрудника смены: он должен различать «ожидается подтверждение» и «оплачено». Для цифрового сервиса отдельно посчитайте число активаций доступа. Это помогает увидеть ошибки, которые не обнаруживаются одним просмотром API-ответа.

Критерии готовности к запуску

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

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

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

Следующие шаги с WhiteCapital Tech

Матрицу можно использовать при обсуждении подключения платёжного API и приёма платежей на сайте. Для мобильного пути есть отдельное руководство по СБП на телефоне, для физической точки — схема работы с QR.

WhiteCapital Tech рассматривает подключение после проверки проекта. Состав методов, среды, возвраты, лимиты и коммерческие условия согласуются отдельно. Этот список тестов не заявляет наличие неподключённых функций и не подменяет приёмку конкретного проекта.

Вопросы и ответы

Достаточно ли одной успешной тестовой оплаты?

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

Можно ли применять матрицу к любому API без изменений?

Используйте её как основу. Названия статусов, допустимые переходы, повторные уведомления и возвраты нужно сверить с документацией конкретного API.

Скриншот страницы успеха подтверждает успешный тест?

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

Что делать с недоступной функцией из списка?

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

Источники и границы материала

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

Практическое руководство. Доступные методы, интеграция оборудования, лимиты, комиссии и расчёты зависят от одобрения проекта и согласованных документов.