Сначала определите источник каждого значения
В магазине одни данные относятся к товару, другие — к продаже. Название, описание и изображения могут редактироваться на сайте, а остатки и цены поступать из учётной системы. Важно заранее решить, где находится основная версия каждого поля и кто вправе его менять.
Если две системы одновременно редактируют цену, нужен порядок разрешения конфликтов. Иначе очередная синхронизация может затереть ручное изменение. Для начала составьте таблицу: поле, источник, получатель, способ обновления и допустимая задержка.
У каждого товара и варианта должен быть устойчивый идентификатор. Совпадение названий для обмена недостаточно: одинаково названные позиции могут отличаться размером, цветом или комплектацией.
Разложите заказ на независимые состояния
Оплата и доставка — разные процессы. Заказ может быть создан, но ещё не оплачен; оплачен, но не собран; отправлен частями или отменён после резервирования. Один общий статус быстро становится неоднозначным.
Опишите, какие переходы допустимы, кто их выполняет и что должен увидеть покупатель. Например, подтверждение оплаты меняет платёжный статус, а передача посылки перевозчику — статус исполнения. Возврат денег и возврат товара также стоит рассматривать отдельно.
Ниже — две концептуальные иллюстрации: связи магазина с внешними системами и этапы обработки заказа. Это не скриншоты готового продукта.
Согласуйте поведение при повторных уведомлениях
Внешняя система может прислать событие повторно. Порядок получения сообщений тоже не всегда совпадает с порядком действий. Например, документация Stripe о webhook отдельно описывает дубликаты и отсутствие гарантированного порядка доставки. Это пример поведения конкретного API; условия выбранного платёжного сервиса нужно проверить отдельно.
Для магазина полезно заранее определить, как распознавать уже обработанное событие. Повторное сообщение не должно повторно создавать отправку или менять количество товара. Обычно интеграция сохраняет идентификатор события и результат обработки.
Письмо покупателю, подтверждение на экране и подтверждение платёжного сервиса имеют разный смысл. Закрытая вкладка не означает отмену оплаты, а переход на страницу успеха сам по себе не заменяет серверную проверку её статуса.
Сделайте ошибки видимыми для команды
При временной недоступности склада обмен должен иметь понятный следующий шаг. Это может быть повторная попытка, очередь на обработку или ручное решение сотрудника. У каждого варианта нужны ограничения и наблюдаемый статус.
Менеджеру полезно видеть время последнего успешного обмена, проблемные позиции и причину остановки заказа в понятной формулировке. Технический журнал нужен разработчику, но не должен быть единственным способом узнать о сбое.
Отдельно договоритесь, что сайт показывает покупателю при устаревших остатках. Возможны подтверждение наличия менеджером или временное ограничение оформления. Выбор зависит от процесса продаж и допустимого риска.
Проверьте весь путь до запуска
Тестовый сценарий должен проходить через все подключённые системы. Создать заказ на сайте недостаточно: нужно убедиться, что он появился у сотрудников с правильным составом и ценой.
В план проверки включите:
- обычную покупку и отказ от оплаты;
- повторное уведомление об одном платеже;
- изменение остатка между выбором товара и оформлением;
- временную недоступность внешнего API;
- отмену и согласованный сценарий возврата;
- частичную отправку, если она предусмотрена;
- восстановление обмена после сбоя.
Перед оценкой интеграции соберите документацию систем, контакты их ответственных и доступ к тестовой среде. В разделе интернет-магазинов можно посмотреть состав работ, а через форму обращения — передать схему текущего процесса.