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