WooCommerce, МойСклад и ЮKassa: как связать магазин, оплату и остатки

Почему подключить три модуля недостаточно

Интеграция WooCommerce с МойСклад и ЮKassa нужна не ради галочек в настройках. Ее задача — сделать так, чтобы покупатель видел доступный товар, оплата относилась к нужному заказу, а сотрудники понимали, что собирать и отправлять.

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

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

Определите, какая система отвечает за каждое поле

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

Для многих магазинов разумно рассмотреть такую схему: учетная система отвечает за номенклатуру, цены и склад; WooCommerce — за оформление заказа и контент карточки; платежный сервис — за фактическое состояние платежа. Это не универсальное требование, а отправная точка для обсуждения.

Составьте перечень сущностей и назначьте владельца каждой:

• товар и его вариант;
• розничная цена и акции;
• физический остаток и доступное к продаже количество;
• резерв и его срок;
• заказ, платеж, возврат и отгрузка;
• описание, фотографии и SEO-поля карточки.

Особенно важно разделить платеж и заказ. Один заказ может иметь несколько попыток оплаты. Ошибочно привязывать бизнес-логику только к последней открытой покупателем странице.

Приведите каталог в порядок до синхронизации

Для обмена нужен стабильный идентификатор. Название «Футболка белая» не подходит: его можно поменять, а у товара бывают размеры. Заранее согласуйте соответствие идентификаторов и артикулов между системами, включая варианты.

На небольшой выборке проверьте обычный товар, товар с вариантами, позицию без остатка и товар с измененной ценой. Если магазин продает комплекты или использует несколько складов, добавьте эти сценарии отдельно.

Не запускайте первую полную синхронизацию поверх рабочего каталога без резервной копии и плана сопоставления. Иначе вместо обновления существующих карточек можно получить дубли. Еще один риск — перезаписать подготовленные описания короткими учетными названиями.

Результат этого этапа — не просто импорт, а понятное правило: какие поля обновляются, какие сохраняются и что происходит при удалении товара в исходной системе.

Продумайте резервирование и отмену

Физический остаток на складе и количество, доступное для новой продажи, могут различаться. Часть товара уже заказана, но еще не отгружена. Нужно договориться, в какой момент создается резерв и когда он снимается.

Разберите ситуацию: два покупателя почти одновременно заказывают последнюю единицу. Какая система принимает окончательное решение о доступности? Что увидит второй покупатель? Можно ли оформить предзаказ? Кто получает уведомление о конфликте?

Сюда же относятся неоплаченные заказы. Если резерв остается навсегда, каталог постепенно показывает отсутствие товара, который физически есть. Если снимается слишком рано, можно продать позицию до завершения оплаты. Правило должно учитывать процесс магазина и платежный сценарий, а не случайное значение по умолчанию.

Подтверждайте оплату по данным сервиса

Возврат пользователя на страницу «Спасибо за заказ» — не надежное подтверждение оплаты. Покупатель может закрыть вкладку, потерять соединение или не вернуться на сайт. Обработчик должен получать достоверный статус платежа и связывать его с правильным заказом.

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

Повторная доставка события не должна повторно создавать отгрузку или отправлять одну и ту же команду на склад. Для исходящих запросов ЮKassa описывает механизм идемпотентности: повтор операции с соответствующим ключом защищает от ее дублирования. Для входящих событий интеграции нужна собственная защита от повторной обработки. Формат взаимодействия с API ЮKassa.

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

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

Подключайте доставку после проверки заказа

Интеграцию СДЭК или 5Post оценивайте по реальному сценарию: выбор пункта выдачи, расчет, сохранение данных, создание отправления и получение статуса. Наличие логотипа службы в оформлении заказа еще ничего не говорит о полноте обмена.

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

Не создавайте отправление на каждом обновлении заказа. Для этого нужна отдельная бизнес-команда с защитой от повторов и правилом обработки отмены. Доступность конкретных возможностей зависит от договора, API и выбранного модуля доставки.

Проверка перед запуском: десять сценариев

1. Обычный заказ успешно оплачен и появился в нужных системах.
2. Покупатель отменил платеж — заказ не стал оплаченным.
3. Покупатель закрыл вкладку после оплаты — подтверждение все равно обработано.
4. Повторное уведомление не создало дубль заказа или отгрузки.
5. Два клиента попробовали купить последнюю единицу — конфликт обработан по согласованному правилу.
6. Выбран конкретный размер — списывается правильный вариант.
7. Изменился город доставки — стоимость и пункт выдачи пересчитаны.
8. Выполнен полный или частичный возврат — связанные данные согласованы.
9. Один сервис временно недоступен — ошибку видно, повтор безопасен.
10. После восстановления связи проверена сверка заказов, а не только отсутствие новых ошибок.

Первые проверки проводите в тестовой среде и тестовом режиме оплаты. Контрольный реальный платеж, если он нужен, согласуйте отдельно. Не используйте настоящие персональные данные клиентов в тестовых копиях без необходимого основания и защиты.

Кто заметит сбой после запуска

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

Заранее определите безопасное ручное восстановление: как сотрудник повторит конкретную операцию, не запуская весь обмен заново. Отдельно зафиксируйте, кто проверяет совместимость после обновления WooCommerce или интеграционного модуля.

Можно обойтись готовыми модулями?

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

Сколько стоит такая интеграция?

Оценка зависит от качества каталога, количества систем, правил резервирования, возвратов и доработок оформления заказа. Для расчета полезнее предоставить примеры сложных заказов, чем только список названий сервисов.

Начните с карты обмена

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

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