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

Списание в банке и отметка в сделке отвечают на разные вопросы

Клиент показывает списание в банковском приложении, а менеджер всё ещё видит неоплаченный заказ в Битрикс24. Повторную оплату пока не просите. Сначала нужно найти тот же платёж у платёжного сервиса и связанный с ним заказ в CRM — системе ведения клиентов и продаж, где менеджер ждёт подтверждения успешной оплаты. Иначе ручная смена статуса может скрыть ошибку, которая снова проявится при следующей покупке.

Дальше разберём приём денег по ссылке из сделки через ЮKassa, когда расчёты ведёт одно юридическое лицо. Здесь руководителю нужны ответы на разные вопросы: завершил ли сервис платёж, дошло ли сообщение до Битрикс24 и что CRM сделала после его получения. Поиск неисправности идёт по этой цепочке. Сотрудник продаж собирает сведения по заказу, бухгалтерия уточняет состояние расчёта, а специалист по интеграции разбирает передачу события. Так никто не принимает решение по чужому скриншоту без связи с конкретной покупкой.

Где заканчивается ожидание оплаты

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

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

Как найти оплату именно этого заказа?

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

В Битрикс24 подробности оплаты находятся в ленте событий сделки — таймлайне. Справка о статусах заказа описывает запись успешной оплаты с её стоимостью и номером заказа. Руководитель может начать с этой записи, а при её отсутствии передать специалисту ссылку на сделку вместе с данными операции из ЮKassa. Это позволит выяснить, отсутствует вся запись об оплате или только дальнейшее действие.

Один набор сведений вместо переписки по частям

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

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

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

Почему событие осталось между сервисом и CRM

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

Адрес и события в кабинете сервиса

Для подключения через Битрикс24 адрес уведомлений задают в ЮKassa, в разделе «Интеграция → HTTP-уведомления». Инструкция подключения указывает получателя с окончанием /bitrix/tools/sale_ps_result.php. Полный адрес относится к конкретному порталу, поэтому его сверяют с действующим подключением. Сайт компании и портал Битрикс24 могут иметь разные адреса: уведомление направляют на портал, где создан заказ.

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

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

Повторные сообщения надо учитывать. Обработка одного события несколько раз не должна создавать несколько оплат или повторно запускать выдачу товара.

Для собственного обработчика закладывают защиту от повторов и способ узнать актуальное состояние операции. ЮKassa также описывает проверку подлинности уведомления по состоянию объекта или IP-адресу отправителя. Это задача специалиста. Руководитель формулирует требование через последствия: случайное или поддельное сообщение не даёт заказу статуса оплаченного, а повторная доставка уже учтённого события сохраняет прежнюю финансовую запись и не запускает повторную выдачу товара покупателю.

Деньги приняты, но стадия не изменилась

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

Какая отметка запускает продолжение

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

Автоматическую смену статуса оплаты Битрикс24 описывает в частых вопросах о центре продаж. Для ЮKassa там указана необходимость включить HTTP-уведомления. Это ориентир для штатного подключения, а приложение стороннего поставщика может принимать события своим способом. Перед изменением настроек исполнитель называет используемый вариант и документ, которому он следует.

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

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

Испытание на понятных исходах

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

Одна таблица для приёмки

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

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

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

Откуда менеджер узнает о следующем расхождении?

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

Вопрос исполнителю перед закрытием работ

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

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