Оплата прошла, а заказ в CRM не обновился: как исправить сбой

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

Что проверить, прежде чем менять статус заказа?

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

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

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

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

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

Где искать сбой между платёжным сервисом, сайтом и CRM?

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

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

1. В кабинете платёжного сервиса найдите историю отправки уведомления, если сервис её показывает. Проверьте адрес получателя и результат попытки.
2. В журнале сайта или модуля найдите входящее сообщение по идентификатору платежа. Если доступа нет, передайте идентификатор разработчику.
3. Проверьте, нашёл ли модуль нужный заказ и какой статус попытался записать.
4. В журнале обмена с CRM посмотрите ответ системы. Отдельно проверьте права доступа интеграции и соответствие полей.
5. Откройте историю заказа после попытки обновления. Убедитесь, что другое правило не вернуло прежний статус.

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

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

Как исправить статус и не запустить обработку заказа повторно?

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

Дальнейший порядок зависит от места сбоя.

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

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

Для автоматической обработки нужна защита от повторов. Интеграция должна узнавать уже учтённую операцию по её идентификатору и не создавать ещё одну оплату при повторном уведомлении. Попросите разработчика проверить это поведение до повторного запуска обмена.

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

Как проверить исправление на заказе?

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

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

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

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

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

Типичные ошибки при исправлении статуса оплаты

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

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