Платёж прошёл, а заказ не оплачен: где искать рассогласование

Приостановите повторную оплату и соберите одну карточку случая

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

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

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

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

Различайте заказ, платёж и движение денег

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

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

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

Сопоставьте конкретную операцию с конкретным заказом

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

Условный пример: покупатель создал заказ А, закрыл окно и оформил заказ Б с тем же составом. Оплата связалась с А, а менеджер открыл Б из последнего письма. Здесь обновление статуса Б наугад скроет реальную связь. Нужно восстановить последовательность и согласовать, какой заказ будет исполнен, сохранив историю обеих записей.

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

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

Проверьте, где остановилось подтверждение

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

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

В инструкции ЮKassa по уведомлениям предусмотрено подтверждение получения ответом HTTP 200 и проверка подлинности сообщения. Успешный ответ сервера ещё стоит сопоставить с записью в заказе: сообщение могло быть принято, но последующее действие завершилось ошибкой. Разработчик должен показать результат обработки, а не только доступность адреса.

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

Выберите действие по подтверждённой картине

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

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

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

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

Ограничьте ручные действия, пока идёт разбор

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

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

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

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

Проверьте исправление при обычной оплате и сбоях

Проверка не заканчивается тем, что старому заказу поставили «оплачен». Нужен новый тест, подтверждающий исправленный путь. В согласованной среде проводят успешную оплату, закрытие страницы до возврата, отмену, повторное открытие заказа и повторную доставку результата. Для проверки используют предусмотренный провайдером тестовый режим, не случайные платежи реальных клиентов.

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

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

Закройте инцидент так, чтобы его можно было распознать снова

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

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

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

Для разбора с ШТАБ ИТ подготовьте номера заказа и операции, сумму, время и последовательность наблюдений. Полный проект подключения описан отдельно в статье о проверке платёжного пути. При текущем расхождении цель конкретна: установить факт операции, восстановить связь с заказом и подтвердить, что новые события обрабатываются корректно.