Клиент присылает подтверждение оплаты и спрашивает, когда отправят покупку. Менеджер открывает заказ: там всё ещё стоит ожидание платежа. Приходится искать операцию в кабинете платёжного сервиса, выяснять сумму и вручную сообщать складу о готовности к сборке. Пока команда занята поиском, следующий оплаченный заказ попадает в ту же очередь.
Проблема может возникнуть даже после успешно настроенного приёма платежей. Уведомление задержалось, обработчик завершился с ошибкой, связь с заказом потерялась при переносе данных. Сверка нужна для поиска таких расхождений. Она сопоставляет сведения из нескольких систем и выделяет записи, которые требуют действия.
Ниже разобрана техническая сверка интернет-магазина. Для примеров используем вымышленные заказы. Процедуру расчётов с банком и бухгалтерский учёт компания определяет отдельно: успешная оплата покупателя и поступление выплаты магазину описывают разные события.
Сначала свяжите заказ с платёжной попыткой
У заказа на сайте и операции у платёжного провайдера обычно разные идентификаторы. Магазин должен хранить их связь с момента создания платежа. Тогда поддержка сможет открыть обе записи и сравнить результат без поиска по имени покупателя.
Одному заказу могут соответствовать несколько попыток оплаты. Например, человек закрыл первую платёжную страницу и вернулся позже. Сохраните историю попыток, включая неуспешные. Если перезаписать первый идентификатор последним, будет трудно разобраться с запоздавшим результатом предыдущей операции.
Для начальной таблицы достаточно номера заказа, идентификатора попытки, провайдера, суммы с валютой, текущего состояния и времени его получения. Добавьте время последней проверки источника. Оно объяснит менеджеру, насколько свежая информация перед ним. Точные поля зависят от магазина и схемы расчёта.
Имя клиента и совпадающая сумма полезны как подсказки при ручном поиске. Автоматическое сопоставление лучше строить на устойчивых идентификаторах. Два покупателя могут заказать одинаковый товар за одну цену в соседние минуты. Привязка по сумме в таком случае оставит системе выбор, которого быть не должно.
Если связь отсутствует, выделите запись в отдельную очередь. Сотрудник установит соответствие по доступным данным и сохранит основание решения. Не стоит автоматически назначать найденный платёж первому подходящему заказу. Похожие проблемы с идентификаторами разобраны в статье о настройке обмена через API. Так называют программный интерфейс для обмена данными между системами.
Определите, какой источник подтверждает оплату
Платёжный сервис сообщает о состоянии операции, сайт хранит состояние заказа, склад знает об исполнении. Эти сведения относятся к разным частям покупки. В сверке нужно заранее указать, откуда брать подтверждение для каждого решения.
Например, в ЮKassa можно получать уведомления об изменении состояния платежа и отдельно запрашивать сведения об операции по её идентификатору. Назначение уведомлений описано в документации ЮKassa, методы работы с объектами приведены в справочнике API. Для другого провайдера разработчик проверяет его собственные состояния и порядок подтверждения.
Названия состояний нельзя без проверки переносить между сервисами. В одном процессе деньги сначала резервируются и позже подтверждаются к списанию. В другом используется одностадийная оплата. Условие передачи заказа на склад должно соответствовать выбранной схеме. Команда записывает его словами, разработчик связывает с конкретным подтверждением провайдера.
Страница после возврата из оплаты помогает покупателю понять дальнейшие действия. Основанием для изменения рабочего заказа служат проверенные серверные сведения. Браузер пользователь может закрыть до возвращения на сайт. Поэтому успешная обработка платежа должна продолжаться независимо от того, увидел ли он страницу благодарности.
Для уведомлений разработчик выполняет предусмотренную провайдером проверку подлинности. Внутренние журналы хранят достаточные сведения об обработке, исключая секреты доступа и данные карты. Менеджеру в обычной карточке заказа нужны номер операции, результат и время проверки. Полный технический запрос в интерфейсе продаж создаёт лишнюю путаницу.
Составьте таблицу расхождений до автоматического исправления
Начните с небольшого набора ситуаций, которые команда уже умеет разбирать вручную. Для каждой запишите наблюдение, проверку источника и допустимое действие. Такая таблица ограничит полномочия автоматизации и покажет, где потребуется решение человека.
| Наблюдение |
Что уточнить |
Следующее действие |
| Провайдер подтвердил оплату, заказ ждёт |
Совпали ли идентификатор, сумма и валюта |
Обновить заказ по согласованному правилу |
| Сайт считает заказ оплаченным, подтверждения нет |
Как появилась отметка и насколько свежи данные |
Передать сотруднику для разбора |
| У заказа две успешные попытки |
Относятся ли обе к одной покупке |
Остановить повторное исполнение и выяснить ситуацию |
| Платёж найден, связь с заказом отсутствует |
Какие сведения сохранились при создании |
Восстановить связь с записью основания |
| Сумма отличается от ожидаемой |
Менялся ли состав заказа |
Разобрать версии и условия покупки |
У каждого действия должно быть проверяемое основание. Условие «похожая сумма» для автоматического изменения слишком слабое. Условие с известным идентификатором операции, подтверждённым состоянием и совпадающей суммой позволяет построить гораздо более определённое правило.
При изменяемой корзине сохраните состав и сумму на момент создания платёжной попытки. Поздняя правка заказа может сделать сравнение с текущей корзиной бессмысленным. В этом случае сотруднику нужны обе версии и время изменения. Система сможет объяснить расхождение вместо повторного сообщения о том, что числа отличаются.
Подготовку таких правил можно начать с выгрузки нескольких реальных спорных записей без персональных данных. Feature IT разрабатывает автоматизацию обмена и проверки заказов. На этих примерах проще согласовать поведение, чем на общем требовании синхронизировать статусы везде.
Сразу определите поведение при частичном возврате. Допустим, покупатель оплатил две позиции и позже отказался от одной. Первоначальная успешная операция останется частью истории, но доступный к исполнению состав заказа изменится. Если сверять только сумму текущего заказа с исходным платежом, такая покупка будет каждый раз попадать в ошибки. Храните возврат отдельно и сравнивайте записи по правилу, учитывающему эту историю.
Для проверки подготовьте пример с одной возвращённой позицией и повторным получением сведений о возврате. После повторной обработки сумма возвращённых средств должна остаться прежней. Сотрудник в карточке видит исходную оплату, подтверждённый возврат и оставшиеся обязательства по заказу. Спорные суммы передаются ответственному за расчёты; автоматизация сохраняет основание для такого разбора.
Проверяйте незавершённые операции повторно
Уведомления о платежах удобны для быстрой реакции. Плановая проверка дополняет их и обнаруживает записи, которые остались без ожидаемого результата. Для неё выделите незавершённые попытки и операции с недавними изменениями. Частоту согласуйте с нагрузкой, условиями провайдера и допустимой задержкой в работе магазина.
Сравнение должно учитывать время. Если платёжная попытка создана несколько секунд назад, ожидание ещё может соответствовать обычному процессу. Сотруднику полезнее видеть, сколько времени заказ ожидает подтверждения оплаты, чем получать одинаковую тревогу сразу после каждой покупки. Порог для обращения в поддержку задают под конкретный способ оплаты.
Храните отметку о последней успешной проверке. При недоступности источника оставьте прежние данные с указанием их возраста и повторите запрос по предусмотренному порядку. Ошибка соединения сама по себе не подтверждает отмену платежа. Автоматическая смена состояния на основании такой ошибки способна запутать заказ ещё сильнее.
После восстановления связи обработайте пропущенный период. Проверка только новых операций оставит старые расхождения без внимания. Для выгрузок по времени предусмотрите небольшой согласованный перекрывающийся интервал и повторную обработку уже известных записей без лишних действий. Границы периода и часовой пояс должны совпадать с правилами источника.
Повторное чтение одной операции не должно создавать второй заказ или ещё одно задание на отгрузку. Сохранённый идентификатор результата помогает обработчику узнавать уже выполненное действие. Общий принцип передачи событий описан в материале о собственных вебхуках, уведомлениях одной системы для другой.
Дайте менеджеру очередь понятных исключений
В рабочем списке расхождений показывайте номер заказа, проблему и ожидаемое действие. Запись «состояния различаются» потребует дополнительного поиска. Запись «провайдер подтвердил оплату, заказ ждёт сборки» сразу объясняет, с чего начать проверку.
Отдельная колонка с ответственным предотвратит одновременную работу двух сотрудников над одним случаем. При назначении исполнителя сохраняйте время и комментарий. Если ситуация требует участия разработчика, передавайте ему идентификаторы и сведения о проверке. Клиентскую переписку и платёжные секреты для этого копировать целиком не нужно.
Ручное исправление должно оставлять историю. Кто изменил статус, на каком основании, что проверил и какие действия уже выполнили. Иначе следующая автоматическая сверка обнаружит новое расхождение, а команда снова начнёт разбор с самого начала. Подробности организации работы при сбоях есть в материале о причинах поломок обмена с 1С.
В учебном примере заказ А имеет подтверждённую оплату и ещё не передан складу. Заказ Б уже собран, но его статус на сайте отстал. Одинаковая команда «передать в сборку» для обеих записей создаст лишнюю работу. Очередь должна учитывать состояние исполнения и предлагать действие после проверки всей связи.
Закрытие расхождения тоже проверяйте. Сотрудник указывает принятое решение, затем система убеждается, что ожидаемые состояния совпали. При временном исключении сохраните срок следующего просмотра. Постоянное скрытие строки без пояснения превратит очередь в список, которому постепенно перестанут доверять.
Испытайте сверку на подготовленных случаях
До включения автоматических изменений запустите проверку в режиме отчёта. Она покажет найденные расхождения и предложенные действия, сохранив рабочие заказы без изменений. Сравните результат с ручным разбором ответственного сотрудника. Ошибки в правилах дешевле исправлять на этом этапе.
Набор для проверки должен включать обычную успешную оплату, задержанное уведомление и повтор одного события. Добавьте операцию с потерянной связью, изменённым составом заказа и двумя попытками оплаты. Отдельно проверьте недоступность источника. В тестовой среде можно воспроизвести эти ситуации без вмешательства в реальные покупки.
Для каждого примера заранее запишите ожидаемый результат. У повторного уведомления должен сохраниться один результат исполнения. При отсутствии подтверждения система оставляет понятный повод для проверки. После восстановления связи пропущенный результат должен попасть в обработку, даже если заказ создан до текущего запуска.
Начните автоматические исправления с правил, по которым отчёт стабильно совпадает с ручной проверкой. Для спорных состояний сохраните очередь сотрудника. Расширять список действий удобнее по накопленным примерам: у команды появятся понятные основания и готовые случаи для повторного испытания.
Следите за количеством открытых расхождений и возрастом самого старого. Дополнительно полезно знать, какие причины встречаются чаще. Если постоянно теряется связь с заказом, требуется исправление её записи при создании платежа. Более частый запуск сверки найдёт ту же проблему быстрее, но источник ошибки останется.
Перед постановкой задачи соберите схемы статусов, пример платёжной попытки и перечень действий менеджера. Обсудите с Feature IT автоматизацию сверки оплат, чтобы определить источники подтверждения и порядок работы с исключениями. Первую проверяемую версию можно ограничить одним магазином и одним способом приёма платежей.
Читайте также
