Как протестировать платежи в интернет-магазине перед запуском
План проверки онлайн-оплаты: успешный платёж, отказ, повторные уведомления, возврат и сверка заказа. Чем тестовый режим отличается от реальной оплаты.
Проверяйте оплату как цепочку: заказ создан, платёж подтверждён провайдером, магазин получил достоверный статус, сумма совпала, покупатель получил предусмотренные документы, а заказ перешёл в правильную обработку. Успешная страница банка или сообщение «Спасибо» не подтверждают работу всей интеграции. Отдельно проверьте отказ, обрыв соединения, повторную попытку и возврат.
Начните в тестовом режиме платёжного сервиса, затем проверьте рабочую конфигурацию и доступные только в ней способы оплаты. Ниже — план для владельца магазина и сотрудника, который отвечает за подключение. Выбор провайдера разобран в статье о подключении онлайн-оплаты.
Определите границы проверки
Составьте список способов оплаты и сценариев, которые вы действительно предлагаете: карта, Система быстрых платежей (СБП), оплата при получении, один или два этапа списания. Проверка карты не подтверждает работу СБП, а онлайн-оплата не проверяет расчёт при выдаче. У каждого способа есть собственные состояния и ограничения.
Обсудите с интегратором, где создаётся платёж, кто получает уведомление, что запускает сборку и кто формирует кассовые документы. В готовой платформе часть проверки выполняется через личные кабинеты и пробные заказы, а технические сценарии — через поддержку или разработчика. Зафиксируйте ответственного за каждое расхождение.
Не ограничивайте результат фразой «платёж прошёл». Для каждого теста сохраните номер заказа, идентификатор операции у провайдера, сумму, режим, ожидаемый и фактический результат. Эти данные помогают воспроизвести сбой, не передавая кому-либо полный номер карты или секретные ключи.
Подготовьте тестовый режим
Тестовая среда имитирует поддерживаемые операции без реального движения денег. Например, в ЮKassa для этого используется тестовый магазин со своими идентификатором и секретным ключом. Документация сервиса отдельно указывает доступные сценарии и специальные платёжные данные.
Разделите тестовые и рабочие ключи, адреса уведомлений и заказы. Тестовая покупка не должна отправлять реальный товар в сборку или попадать в выручку магазина. ЮKassa прямо рекомендует отдельный адрес для тестовых уведомлений и запрещает выдавать товар, оплаченный через тестовый магазин.
Используйте тестовые карты именно вашего провайдера: они задают успешные и неуспешные исходы. Не переносите номера из инструкции другого сервиса. Настоящие карты в тестовом магазине ЮKassa использовать нельзя; рабочий режим, напротив, предполагает реальные деньги.
Проверьте ограничения среды до составления плана. В тестовом магазине ЮKassa можно проверять карты и кошелёк ЮMoney, а другие способы, включая СБП, требуют настоящего магазина. Имитация ответа кассы тоже не подтверждает, что реальный чек прошёл фискализацию.
Секретный ключ должен оставаться в защищённой серверной конфигурации. Не помещайте его в код страницы, письмо или общий отчёт о тестировании. Если готовый модуль просит настройки, используйте предусмотренный защищённый интерфейс и проверьте, какой режим он включает.
Пройдите успешную покупку от начала до конца
Выберите товар с известной ценой и доступным количеством. Добавьте доставку и скидку, если они используются в магазине: платёж без этих условий не выявит ошибку итоговой суммы. Не отправляйте тестовый заказ физически.
Последовательность проверки:
- Создайте заказ и запишите его итоговую сумму.
- Перейдите к оплате и сравните сумму у провайдера с заказом.
- Проведите документированный успешный тест.
- Вернитесь на сайт и проверьте понятное подтверждение.
- Убедитесь, что сервер магазина получил и проверил статус платежа.
- Сверьте заказ, операцию в кабинете провайдера и дальнейшее действие системы.
- Проверьте предусмотренную передачу данных чека и уведомление покупателю.
Для учебной корзины два товара по 1 200 ₽, общая скидка 200 ₽ и доставка 300 ₽ дают 2 × 1 200 − 200 + 300 = 2 500 ₽. Именно эта сумма должна согласованно использоваться в заказе и оплате. Если при переходе цена поменялась, система должна пересчитать условия и получить подтверждение покупателя.
При двухэтапной схеме отдельно проверьте резервирование средств, подтверждение списания и отмену резерва. В ЮKassa состояние waiting_for_capture означает ожидание подтверждения, а не окончательный успешный платёж succeeded. Порядок передачи заказа в работу должен соответствовать вашей схеме, а не одному общему тексту «оплачено».
Повторите покупку на телефоне и компьютере. Проверьте переход в банковское приложение, если способ его использует, возвращение на сайт и поиск созданного заказа. Успешная серверная интеграция ещё не гарантирует, что покупателю удобно завершить оплату.
Проверьте отказы, обрывы и повторные попытки
Провайдер может успешно принять запрос, но покупатель не завершит действие. Магазин должен различать ожидание, отказ и подтверждённую оплату. Не показывайте один и тот же совет «попробуйте ещё раз» для всех неопределённых состояний.
| Сценарий | Что проверить | Ожидаемое поведение магазина |
|---|---|---|
| Отказ банка | Документированный неуспешный тест | Заказ не отмечен оплаченным, понятен следующий шаг |
| Покупатель отменил подтверждение | Выход из платёжного сценария | Нет ложной оплаты, можно вернуться к заказу |
| Вкладка закрыта после оплаты | Статус у провайдера и серверное уведомление | Оплата определяется независимо от возврата в браузер |
| Уведомление задержалось | Порядок сверки статуса | Заказ ожидает проверки, человеку не навязывают новую оплату |
| Кнопка нажата дважды | Число операций и списаний | Нет ненамеренной дублирующей покупки |
| Сумма корзины изменилась | Пересчёт до создания операции | Подтверждается актуальный состав и итог |
| Истёк срок операции | Фактический статус у провайдера | Новая попытка не подменяет неопределённую старую |
Тайм-аут запроса не доказывает, что платёж не был создан. Перед новой попыткой система должна проверить прежнюю операцию по сохранённому идентификатору и правилам провайдера. Иначе покупатель может получить две ссылки и оплатить оба платежа.
Для сотрудника подготовьте порядок разбора: найти заказ, проверить операции в кабинете, сверить сумму и статус, затем сообщить покупателю результат. Сообщение о списании в банковском приложении полезно для обращения, но не заменяет проверку со стороны магазина. Не просите человека повторить оплату, пока предыдущая остаётся неопределённой.
Проверьте серверные уведомления
Webhook — запрос, которым платёжный сервис сообщает вашему серверу о событии. Он приходит независимо от того, вернулся ли покупатель на сайт. Страница возврата в браузере нужна для интерфейса; её адрес или параметры нельзя считать доказательством оплаты.
Уведомление нужно проверить способом, который предусмотрен именно провайдером. CloudPayments документирует проверку HMAC-подписи — кода аутентификации сообщения на основе хеш-функции. ЮKassa описывает проверку статуса объекта и адреса отправителя. Не требуйте от одного сервиса заголовок другого: интегратор должен применять официальную схему.
Дополнительно сверяйте операцию с сохранённым заказом: идентификатор платежа, получателя, сумму, валюту, режим и итоговый статус. Для ЮKassa надёжная проверка включает получение текущего объекта через авторизованный запрос к программному интерфейсу (API). Одного номера заказа из произвольного запроса недостаточно для смены статуса.
Повтор одного события не должен повторять действие
Платёжные уведомления могут быть доставлены повторно. Обработчик должен безопасно принять одно и то же событие несколько раз, сохранив один результат: один переход статуса, одно задание на сборку и отсутствие дублирующего возврата. Проверьте это в тестовой среде собственной интеграции.
Идемпотентность означает, что повтор одной операции не создаёт дополнительный эффект. В API ЮKassa для повторяемых запросов используется Idempotence-Key: повтор с тем же ключом и параметрами в пределах гарантируемого сервисом срока возвращает результат исходной операции. Для новой самостоятельной операции нужен новый ключ.
Это два разных контроля. Ключ запросов защищает повтор создания платежа, а ваша обработка событий — повтор изменения заказа. Один из них не заменяет другой. Сохраняйте идентификаторы и используйте согласованное изменение состояния, чтобы две обработки не отправили один заказ в сборку дважды.
Отдельно проверьте задержанные события и их порядок. Старое сообщение об ожидании не должно отменять более позднюю подтверждённую оплату; сообщение о возврате должно менять состояние возврата, а не просто переписывать платёж как неоплаченный. При сомнении сверяйте текущее состояние с провайдером.
Убедитесь, что событие не потеряется при ошибке
Попросите интегратора проверить временную недоступность обработчика и повторную доставку по правилам сервиса. Подтверждение приёма должно означать, что событие надёжно сохранено или обработано, а не только получено в памяти. Необходимые коды ответа зависят от документации провайдера.
Ошибка кассы, почтового уведомления или склада не должна исчезать вместе с записью об оплате. Разделите подтверждение денег и дальнейшие действия, сохраняя их статусы. Сотрудник должен видеть, какой шаг требует повторения, а покупатель — понятный результат.
Проверьте возвраты и кассовые документы
Проведите полный возврат, а при поддержке вашего сценария — частичный. Сверьте сумму, связь с исходным платёжным идентификатором, результат в кабинете и локальный статус. Созданный запрос на возврат ещё не всегда означает завершённое возвращение денег.
В учебной оплате 2 500 ₽ полный возврат должен соответствовать этой сумме. Если по условиям отдельного теста возвращается один товар за 1 100 ₽ после распределённой скидки, оставшаяся оплаченная сумма составит 1 400 ₽. Это проверка арифметики интеграции, а не универсальное правило возврата доставки или скидки.
Повтор запроса на один возврат не должен создавать новый возврат, а сумма завершённых возвратов должна согласовываться с исходной оплатой. Проверьте ошибку или отказ возврата и порядок действий сотрудника. Возврат денег и восстановление складского остатка — разные процессы: физический товар может ещё не поступить обратно.
Кассовый чек не равен письму «заказ оформлен» или банковскому подтверждению. Для вашей схемы расчёта проверьте ответственную систему, состав передаваемых данных, доставку предусмотренного документа и обработку ошибок. В тестовом магазине ЮKassa ответ онлайн-кассы может имитироваться; финальную фискализацию нужно подтверждать в рабочем процессе.
Розничные правила и организация возврата подробно разобраны в статье о возврате товара в интернет-магазине. Здесь задача уже: убедиться, что согласованный возврат технически проходит и правильно отражается в системах.
Перейдите к рабочему режиму и сверке
После тестов проверьте рабочий идентификатор магазина, ключи, адрес уведомлений, способы оплаты и подключение кассовой схемы. Функция, доступная в тесте, может требовать отдельного подключения в настоящем магазине. Не считайте переключение ключа единственным шагом запуска.
Когда рабочий магазин подключён, выполните согласованный контрольный платёж на небольшую сумму с реальным способом оплаты, затем предусмотренный возврат. Это реальные деньги и возможные комиссии, поэтому заранее проверьте условия и обозначьте заказ как контрольный в своём учёте. Для СБП и других способов, недоступных в тесте провайдера, нужен отдельный рабочий сценарий.
Сопоставьте оплату, заказ, чек и выплату по условиям договора. Оплата покупателя и зачисление на расчётный счёт происходят на разных этапах; сумма выплаты также может учитывать комиссию и другие операции. Не объявляйте деньги потерянными только потому, что выплата ещё не наступила.
Перед запуском добейтесь конкретного результата: каждый выбранный сценарий имеет подтверждение и ответственного, а критичных расхождений нет. После запуска организуйте регулярную сверку оплаченных заказов, возвратов и проблемных документов. Частоту выбирайте по объёму продаж и нагрузке.
Частые вопросы
Достаточно ли одной успешной тестовой покупки?
Она подтверждает только проверенный сценарий. Нужны как минимум отказы, прерывание, повторные события и возврат, а также каждый предлагаемый способ оплаты. Рабочую конфигурацию проверяют отдельно.
Можно ли проверить СБП в тестовом магазине ЮKassa?
По документации ЮKassa тестовый магазин поддерживает карты и кошелёк ЮMoney. Другие способы проверяют в настоящем магазине. Перед запуском уточните доступные сценарии своего провайдера и интеграции.
Почему заказ остался неоплаченным после успешного списания?
Возможно, уведомление задержалось, было отклонено или не обработалось, либо операция неверно связана с заказом. Сначала проверьте её у провайдера и сравните идентификаторы и сумму. Не предлагайте повторную оплату до выяснения статуса первой.
Нужно ли тестировать после обновления модуля оплаты?
Повторите сценарии, которых касается обновление, и базовый путь оплаты и возврата. Смена адреса сайта, ключей, кассовой схемы или обработчика тоже может нарушить ранее проверенную цепочку.
Храните результаты проверок так, чтобы по номеру заказа можно было восстановить платёж, возврат и дальнейшие действия. Это поможет после запуска разобрать расхождение без догадок и ненужной повторной оплаты.