Как связать оплату на сайте со статусом заказа
Покупатель оплатил товар, но менеджер видит «ожидает оплаты». Или наоборот: заказ помечен оплаченным после открытия страницы успеха, хотя операция ещё не завершена. Обе ошибки возникают, когда платёж и заказ живут отдельно. Чтобы связать оплату на сайте со статусом заказа, нужно заранее определить состояния и источник подтверждения. Если хотите проверить свой сценарий, начните с БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ.
В A3 Studio связку проектируют от оформления заказа до его исполнения: какое событие меняет статус, кто это видит и что происходит при сбое.
Оплата и статус заказа: две связанные записи
Заказ хранит состав покупки, сумму, контакт, доставку и текущий этап работы. Платёж хранит данные об отдельной попытке перечислить деньги. Свяжите их устойчивым идентификатором. Нельзя сопоставлять записи только по имени клиента или сумме: одинаковые заказы могут быть у разных людей, а один покупатель может сделать несколько заказов подряд.
Статус «оплачен» должен появляться после подтверждения от платёжного сервиса. Посещение страницы «Спасибо» показывает лишь, что браузер туда перешёл. Оно может произойти до завершения обработки или вовсе не произойти, если покупатель закрыл вкладку. Поэтому серверу нужен независимый способ получить и проверить итог платежа.
Вопрос к вам: какое событие сейчас переводит заказ в исполнение и можно ли доказать, что деньги к этому моменту подтверждены? Если ответ «менеджер увидел письмо», схему стоит уточнить.
У заказа могут быть собственные статусы: создан, ожидает оплаты, оплачен, в работе, выполнен, отменён. Платёжные статусы не обязаны совпадать с ними буквально. Например, деньги получены, но товар ещё не собран. Не используйте слово «выполнен» как синоним «оплачен».
Сравните ручную и автоматическую синхронизацию
Ручная проверка. Механика: сотрудник смотрит платёжный кабинет и меняет статус заказа. Плюс: подходит для небольшого количества индивидуальных сделок. Главный риск: задержка, человеческая ошибка и слабая видимость для клиента.
Автоматическое обновление. Механика: сайт получает подтверждение от провайдера, находит нужный заказ и меняет статус. Плюс: меньше ручной работы, клиент быстрее видит итог. Главный риск: если не продумать повторные уведомления и сбой связи, автоматизация создаст неверные статусы массово.
В обеих схемах назначьте ответственное лицо для исключений. Автоматизация не отменяет случаи, когда подтверждение задержалось, сумма не совпала или покупатель пожаловался на двойное списание.
Таблица показывает основные переходы.
Лайфхак: нарисуйте переходы стрелками и подпишите, какое событие запускает каждый. Если нельзя назвать источник перехода «ожидает» → «оплачен», разработчик будет вынужден выбирать его сам.
Как настроить переходы без ложного «оплачено»
Шаг 1. Создайте заказ до перехода к оплате
У заказа должны быть номер, состав и окончательная сумма, которую видит покупатель. Платёжная попытка привязывается к этому номеру. Если состав меняется, старую попытку нельзя тихо использовать для новой суммы.
Шаг 2. Получите итог платежа
Интеграция принимает подтверждённое событие от провайдера или запрашивает текущий статус. При повторной доставке одного события статус не должен переходить снова и порождать вторую задачу на исполнение.
Шаг 3. Обновите заказ и связанные системы
После подтверждения оплаты сайт меняет заказ на «оплачен», уведомляет команду и, если требуется, передаёт статус в CRM или учётную систему. Если один из каналов временно недоступен, событие не должно исчезать без следа: нужна запись для повторной обработки.
Шаг 4. Покажите клиенту правдивый результат
Страница успеха и письмо должны опираться на действительный статус заказа. При ожидании пишите «проверяем оплату» и давайте номер заказа. При отмене предлагайте повторить действие только после проверки первой попытки.
Вопрос к вам: сколько систем получают статус «оплачен» сейчас и кто заметит, если одна из них не обновится? Даже небольшому магазину нужна точка сверки.
Проверьте всю цепочку перед продажами
Используйте тестовый режим платёжного сервиса для успеха, отмены, ожидания и повторной попытки. На каждом сценарии сравните сумму, идентификатор и статус в сервисе, на сайте и в CRM. Проверьте обновление страницы покупателем и повторную доставку уведомления. Отдельно протестируйте заказ, который оплачен, но письмо не дошло.
Пример расчёта (условные цифры): сайт получает 80 заказов в месяц. Если хотя бы два из них требуют ручной сверки, у команды должен быть порядок, как найти платёж и связать его с заказом. Пример не оценивает частоту проблем на рынке; он показывает необходимость ответственного за исключения даже при небольшом потоке.
В A3 Studio критерии приёмки формулируют через совпадение данных: после подтверждённой оплаты заказ один раз переходит в верный статус, а команда получает его в работу. Красивый экран успеха без этой проверки не завершает интеграцию.
Платёж, интерфейс, аналитика, уведомления и CRM должны говорить об одном заказе. Ошибка связи отражается и на клиенте, и на отчётности. A3 Studio выстраивает цепочку так, чтобы команда видела действительное состояние покупки.
Что ещё связано
После связи статусов проверьте поведение при неуспешной оплате и отсутствие подтверждения у клиента. В A3 Studio эти исключения включают в схему до запуска. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
Оплаченный заказ определяется подтверждённым платёжным событием, а не сообщением браузера. Заказ, платёжная попытка и этап исполнения должны быть связаны, но оставаться разными сущностями. Это помогает исключать дубли, искать сбои и показывать клиенту правдивый статус.
На каком подтверждении ваш сайт сегодня меняет статус заказа на «оплачен»?
Напишите, на каком этапе ваш сайт: A3 Studio