Если магазин не получил ответ на создание платежа ЮKassa, это ещё не основание выставлять покупателю новую оплату. Сначала нужно установить результат исходной операции и сохранить её идентичность при повторе. Техническая инструкция проверена 12 октября 2026 года; ниже — порядок расследования для владельца магазина и его разработчика.

Отделите заказ от попытки оплаты

ЮKassa распознаёт повтор по заголовку Idempotence-Key и тем же данным запроса. Длина ключа ограничена 64 символами. Если отправить прежние данные с другим ключом, сервис обработает запрос как новую операцию. Гарантия идемпотентности действует 24 часа после первого запроса.

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

Не превращайте ошибку связи в отказ платежа

По документации HTTP 500 сам по себе не сообщает, выполнена ли операция. До решения о повторной оплате нужно выяснить результат обработки. Сообщение браузера об ошибке и состояние денежной операции относятся к разным уровням проверки.

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

Разберите повтор на учебном заказе

Представим заказ на две лампы. Сервер отправил запрос, но соединение оборвалось до ответа. Правильная первая задача — найти запись этой попытки. Если разработчик просто нажмёт «создать заново», в журнале появится другая операция, хотя покупатель собирался совершить одну покупку.

Для безопасной повторной отправки сохраните исходные параметры. Изменение состава заказа нужно согласовать отдельно: это уже другая бизнес-задача, которую нельзя незаметно смешать с восстановлением связи. Если прошло больше документированного срока, перед любым новым действием проведите сверку истории, а не рассчитывайте на прежнюю защиту от дублей.

Как принять исправленную интеграцию

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

Контроль связан с общим порядком сопоставления внешнего платежа и заказа, но конкретный механизм повторов здесь относится к ЮKassa. Закрывайте инцидент после сверки операции и внутреннего заказа. Само исчезновение ошибки из журнала не доказывает, что деньги и товар учтены правильно.