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

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

Ниже — порядок расследования для владельца магазина на «1С-Битрикс: Управление сайтом» и разработчика интеграции. Особенности уведомлений приведены на примере действующего API ЮKassa, сверенного 26 сентября 2026 года. У другого провайдера могут отличаться статусы, способы проверки подлинности и правила повторной доставки. Старый протокол и новый API нельзя разбирать по одной инструкции.

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

Условный пример: первая попытка на 7 400 рублей не завершилась, вторая прошла успешно, но модуль сохранил в заказе только ссылку на первую. Поиск по старому идентификатору честно покажет неуспех. Это ещё не потеря уведомления: проблема возникла раньше, при связывании второй попытки с оплатой. Исправление обработчика входящих сообщений само по себе такую связь не восстановит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A buyer shows a deduction, the payment service account shows a transaction, but the store continues to wait for funds. Asking for payment again only complicates the investigation. First, you must link the specific payment to the specific order payment and find the last point where the confirmation was reliably processed. This requires records from both systems, not just a single screenshot from the buyer.

Below is the investigation procedure for a store owner on 1C-Bitrix: Site Management and an integration developer. Notification specifics are illustrated using the current YooKassa API, verified on September 26, 2026. Other providers may have different statuses, verification methods, and rules for re-delivery. The old protocol and the new API cannot be analyzed using a single instruction.

An order can have multiple payment attempts, partial payments, and various payment documents. The order number does not replace the transaction ID provided by the payment gateway. Construct a linkage comprising: the order, its payment document, the external payment ID, amount, currency, timestamp, and the merchant store. The secret key and full card data are not included in such a record.

Hypothetical example: the first attempt for 7,400 rubles did not complete, the second succeeded, but the module saved only a link to the first attempt in the order. Searching by the old ID will correctly show a failure. This is not yet a lost notification: the issue arose earlier, during the linking of the second attempt to the payment. Fixing the incoming message handler alone will not restore this linkage.

Returning the user to the store page occurs via the browser. The payment status notification arrives via a separate request from the payment service. The buyer may close the tab, lose internet connectivity, or never return; the server-side route must continue functioning regardless. Conversely, a loaded thank-you page does not prove payment was successful.

It is useful for a developer to trace the server route across three boundaries: whether the request reached the store infrastructure, whether the application accepted it, and whether it saved the result in the correct payment document. Each transition requires a timestamp and an operation ID. If logs use different time zones, first convert all times to a single zone; otherwise, adjacent events are easily mistaken for different attempts.

Start with the delivery log on the provider side, if available, and the store's incoming request log. Look for the specific attempt within the required time interval. The absence of an entry in the application log does not mean the network request was absent: it could have been blocked by a reverse proxy, access restrictions, or site protection.

After migrating a site, the old notification address often remains. After enabling protection, the handler may start requiring browser verification or visitor authorization. Another option is redirecting the request to a different page: the store appears to work, but the service entry point now leads elsewhere. You must check the notification route, not the availability of the main page.

Do not disable the entire site's protection for testing. A responsible specialist correlates the failure with access rules and the specific payment service's requirements. If an exception is truly needed, it must be narrow and preserve notification authenticity. A random message from the internet must not alter the order's financial status.

A successful HTTP response indicates interaction with the endpoint but does not guarantee a correct business operation. A placeholder page can also return a success code. An application may confirm receipt and then lose the task in the queue. Therefore, the next record to look for is the saving of an event or processing result, not just a web server string.

If the integration uses a queue, its acceptance must be reliable: confirmation of receipt is sent only after the necessary information is stably stored. This reveals which task is linked to the payment, how many attempts were made, and the reason for the stop. This is an architectural requirement for the enhancement; enabling a queue without error control can simply shift the loss to another location.

When processing directly, check for application exceptions, save conflicts, and the search for a payment document. Conditional case: an external payment is found, but the corresponding payment in the store has already been replaced by a manager. A silent completion leaves the order unpaid and hides the cause. Such an operation must be routed to a discrepancy review with a specific description, not dissolve among successful responses.

Event replay is an expected integration scenario. The handler must recognize an already accounted result via a stable link to the external payment. Two simultaneously received copies require the same protection as two sequential ones. A simple check for "not yet paid" before saving can be insufficient: both processes may see the same old state.

The developer separately protects the payment change itself and subsequent actions: sending an email, transferring the order to 1C, and creating a shipment. If the payment flag is already saved but the exchange with 1C fails, do not retry the money deduction. Resume the incomplete stage while preserving the link to the original operation.

The idempotency key used during payment creation and the protection of incoming notifications solve different problems. The former helps prevent creating an extra payment when an outgoing request is retried. The latter prevents applying the same financial result to the store twice. The presence of the first mechanism does not prove the correctness of the second.

Before manual correction, the responsible employee compares the provider's current data, amount, and currency with the payment document, checks other successful attempts and refunds. If the funds relate to a different payment or the amount does not match, automatic status assignment must be stopped. Do not select an order based solely on a similar amount and close timing.

Correction is performed using the standard method of the specific module or via an agreed recovery procedure, with a record of the reason and the executor. Directly changing a field in the database can bypass related events and leave inconsistent data. Restarting the entire chain without clarifying already completed actions is dangerous due to double shipping and document duplication.

After correcting one operation, check the time interval from the last confirmed success to the resolution of the cause. Verify not only the number of payments but also their IDs and amounts. The same number of operations can hide both a missing and an extra transaction simultaneously. The buyer can be informed of the result after verifying their specific payment; restoring other discrepancies will continue regardless of whether they open the order page.