Как спроектировать интеграции интернет-магазина с 1С, CRM, складом, оплатой и доставкой: источник данных, статусы, очереди, защита от дублей и тестирование.
Интеграции в интернет-магазине начинаются не с выбора API и не с фразы «подключите 1С». Сначала нужно договориться, где живут данные, кто имеет право их менять и как система ведёт себя, когда один из сервисов временно недоступен.
В работе над интернет-магазинами я не раз видел красивый каталог с проблемами в операционке: на сайте один остаток, на складе другой, менеджер получает два одинаковых заказа, а клиент узнаёт об отмене после оплаты. Такие сбои редко возникают из-за одной ошибки в коде. Чаще причина — интеграции проектировали по частям, без единой схемы.
Ниже — мой практический подход к архитектуре связки интернет-магазина, 1С, CRM, склада, платежей и доставки. Он подходит для запуска нового магазина и для аудита уже работающего проекта.
У одного поля должен быть один главный источник. Если цену одновременно меняют в админке магазина, 1С и CRM, расхождения неизбежны. В начале проекта я составляю таблицу владения данными.
Источник правды не обязан быть одной программой для всего. Важно, чтобы у каждого объекта был хозяин. Магазин не должен перезаписывать остатки, если их ведёт 1С, а CRM не должна «догадываться» о факте оплаты без подтверждения от платёжного сервиса.
Обычно достаточно выделить пять независимых потоков:
1. Товары и категории: названия, фото, характеристики, варианты, документы.
2. Цена и наличие: обычные и акционные цены, резерв, доступность по складам.
3. Заказ: корзина, клиент, состав, доставка, скидка, комментарий.
4. Статусы: создан, оплачен, передан в сборку, отгружен, отменён, возвращён.
5. Сервисные события: ошибка синхронизации, повторная отправка, ручная корректировка.
У каждого потока должен быть формат, направление, периодичность, допустимая задержка и ответственный. Это звучит формально, но именно в этих пяти пунктах определяется жизнеспособность магазина после запуска.
Не все данные нужно получать в момент действия пользователя. Я разделяю операции на две группы.
Пользователь ждёт ответ сразу: проверка цены, доступности способа доставки, создание платежа, подтверждение купона. Если такой запрос занимает слишком много времени, магазин должен показать понятную альтернативу, а не зависнуть.
Пользователь не обязан ждать: передача заказа в CRM, обновление трек-номера, выгрузка полного каталога, отправка уведомлений, пересчёт рекомендаций. Эти операции безопаснее ставить в очередь и повторять при временной ошибке.
Практическое правило: не заставлять страницу оформления ждать ответа от каждой внешней системы. Сначала магазин надёжно фиксирует заказ у себя, присваивает уникальный идентификатор и только затем передаёт его дальше. Так клиент не нажмёт кнопку второй раз, если CRM или 1С ответят с задержкой.
Дубли появляются по вполне обычным причинам: двойной клик, нестабильная сеть, повторный callback от оплаты, повторная задача в очереди. Поэтому для заказа нужны:
Я не советую подтверждать заказ только по возврату браузера со страницы оплаты. Надёжным источником статуса должен быть серверный callback или проверка у платёжного провайдера. Также нельзя хранить реквизиты карт в самом магазине: это зона платёжного сервиса и его защищённого интерфейса.
Самые типичные конфликты выглядят так:
Связка с 1С не сводится к «выгрузить XML ночью». Платформа поддерживает веб-сервисы и может быть поставщиком или потребителем сервисов; конкретный способ зависит от конфигурации, нагрузки и политики доступа. Сначала описывается бизнес-процесс, затем выбирается обмен.
Платёж, отгрузка и фискализация имеют разные статусы. Успешная авторизация платежа не всегда означает, что товар уже отгружен; создание накладной не означает, что клиент получил посылку.
В ТЗ интеграции нужно явно зафиксировать:
Для мультискладского бизнеса полезно сразу определить правило выбора склада: ближайший, приоритетный, с полным остатком или вручную назначаемый. Иначе эта логика появится стихийно в нескольких системах.
«Интеграция работает» — недостаточный статус. Мне важно видеть:
В логе не должно быть паролей, токенов и платёжных данных. Для расследования достаточно идентификатора заказа, времени, направления обмена, кода ответа и безопасного текста ошибки. Без такого журнала любая ошибка превращается в ручной поиск между несколькими кабинетами.
Безопасность API тоже должна быть частью проекта: разграничение прав, ограничение запросов, проверка входящих webhook, ротация ключей и отказ от передачи секретов в URL. Для базовой оценки рисков можно опираться на рекомендации OWASP по безопасности API.
Я провожу тестирование не только «по счастливому пути». В минимальный набор включаю:
1. Заказ одного товара с успешной оплатой.
2. Заказ с несколькими вариантами, скидкой и доставкой.
3. Повторную отправку одного события.
4. Недоступность CRM, 1С или службы доставки.
5. Отмену и возврат.
6. Обновление цены и остатка.
7. Одновременное оформление нескольких заказов на последний остаток.
8. Ручную корректировку заказа менеджером.
Для каждого сценария заранее определяется ожидаемый результат: где появится заказ, какой статус увидит клиент, кто получит уведомление и что останется в журнале. Такой подход резко снижает риск «тихих» потерь данных после запуска.
Интеграции напрямую влияют на качество каталога: цена, наличие, варианты, характеристики и доставка должны совпадать на карточке, в фиде и в учётной системе. Когда данные расходятся, страдает не только конверсия — поисковые сервисы и рекламные площадки тоже могут видеть противоречивую информацию.
Чтобы каталог оставался технически понятным для поиска, рекомендую отдельно пройти SEO-структуру каталога, а для требований к запуску использовать материал «Техническое задание на интернет-магазин». Это соседние, но разные задачи: первая статья — про видимость и архитектуру страниц, вторая — про состав проекта, а эта — про надёжный обмен данными.
Если в проекте есть 1С, CRM, несколько складов, персональные цены или нестандартная логистика, архитектуру стоит обсудить до дизайна и разработки. Это заметно дешевле, чем исправлять потерянные заказы и расхождения после запуска.
Обсудить разработку интернет-магазина
1С:Предприятие — веб-сервисы и интеграция