Після перенесення магазину на інший хостинг, домен або сервер WooCommerce може продовжувати приймати замовлення, але перестати передавати дані до CRM, служб доставки, платіжних систем чи складських сервісів. Часто проблема проявляється не одразу: покупець оформлює замовлення, воно з’являється в адмінці, але менеджер не бачить його в CRM або перевізник не отримує інформацію для створення накладної.
Причина може бути як у змінених URL та налаштуваннях, так і в помилках сервера, бази даних, SSL-сертифіката, cron-завдань чи фонової черги WooCommerce. Перед будь-якими ризикованими змінами варто зробити резервну копію файлів і бази даних. Якщо магазин приймає нові замовлення, особливо важливо зберегти їх окремо або тимчасово контролювати вручну, щоб не втратити дані під час діагностики.
Чому інтеграції ламаються після переїзду
Вебхук — це автоматичний HTTP-запит, який WooCommerce надсилає на адресу зовнішнього сервісу після певної події: створення замовлення, зміни його статусу, оплати або оновлення товару. Після міграції сайт може залишатися доступним для користувачів, але такі запити починають повертати помилки або взагалі не запускаються.
- Змінився домен або протокол. У налаштуваннях CRM, служб доставки чи платіжного сервісу могла залишитися стара адреса сайту. Якщо сайт перейшов із HTTP на HTTPS, старий URL також може бути недоступним.
- Вебхуки містять застарілі ключі. Під час перенесення могли змінитися API-ключі, секрети підпису, користувачі або права доступу.
- Не працює SSL-сертифікат. Зовнішній сервіс може відхиляти запити, якщо сертифікат прострочений, неправильно встановлений або ланцюжок сертифікації неповний.
- Заблоковані вихідні або вхідні з’єднання. Фаєрвол, WAF, CDN, хостингова політика чи плагін безпеки можуть блокувати IP-адреси або REST API.
- Пошкоджені постійні посилання. Неправильні правила сервера Apache або Nginx можуть заважати роботі REST API та окремих endpoint-ів WooCommerce.
- Не запускаються cron або Action Scheduler. Частина подій WooCommerce виконується у фоновому режимі. Якщо черга зависла, замовлення можуть не передаватися одразу або накопичуватися.
- Неповна міграція бази даних. У таблицях можуть залишитися старі URL, некоректні серіалізовані налаштування, відсутні записи черги або дані інтеграцій.
Для складного переїзду важливо заздалегідь підготувати план перевірки. Окремо варто врахувати відновлення інтеграцій WooCommerce, якщо магазин уже працює, але частина подій не доходить до зовнішніх систем.
Перевірка URL ключів і журналів вебхуків
Почніть із розділу WooCommerce, де зберігаються вебхуки. Для кожного запису перевірте тему події, статус, URL доставки, активність і дату останньої спроби. Адреса повинна вести на актуальний endpoint зовнішнього сервісу, а не на старий домен або тестове середовище.
Далі перевірте ключі API та секрети. Не варто просто копіювати їх у листування чи публічні чати. Якщо є підозра, що ключі стали відомі стороннім, безпечніше відкликати старі та створити нові. Перед заміною потрібно уточнити, де саме вони використовуються: у WooCommerce, плагіні, CRM, серверних змінних або окремому middleware-сервісі.
У журналі вебхука зверніть увагу на HTTP-код відповіді та текст помилки:
200або2xxзазвичай означає, що запит прийнято, але це ще не гарантує коректного створення запису в CRM;301або302можуть свідчити про редирект зі старого домену, HTTP на HTTPS або між різними варіантами URL;401чи403часто пов’язані з неправильними ключами, правами доступу, WAF або блокуванням запиту;404вказує на відсутній або змінений endpoint;408,429і5xxможуть бути пов’язані з тайм-аутами, лімітами, перевантаженням або помилками сервера.
Перегляньте також системний журнал WooCommerce, журнал помилок PHP, логи вебсервера та записи плагіна інтеграції. Якщо використовується Action Scheduler, перевірте кількість очікуваних, невдалих і прострочених завдань. Не очищайте журнали до завершення діагностики: вони можуть містити єдині докази того, на якому етапі зупиняється обмін.
Як відновити обмін із CRM та доставкою
Відновлення краще виконувати поетапно, починаючи з найменш ризикових перевірок. Спочатку переконайтеся, що сайт відкривається за основним HTTPS-доменом, сертифікат дійсний, а сторінки оформлення замовлення і кабінету клієнта працюють без помилок.
- Зробіть резервну копію файлів, бази даних і поточних налаштувань інтеграцій.
- Порівняйте URL сайту в налаштуваннях WordPress і WooCommerce з фактичним доменом.
- Оновіть URL вебхуків у CRM, службі доставки та інших зовнішніх системах.
- Перевірте API-ключі, секрети, права користувача та дозволені IP-адреси.
- Перевірте REST API, правила permalink і конфігурацію Apache або Nginx.
- Переконайтеся, що cron запускається, а фонова черга WooCommerce обробляє завдання.
- Повторіть невдалу подію лише після збереження її початкового стану та перевірки, чи не створить повторна відправка дубль.
Якщо інтеграція працює через плагін, не поспішайте перевстановлювати його. Видалення може стерти налаштування, журнали або чергу подій. Спершу зафіксуйте конфігурацію, версію плагіна та помилки. Після цього можна перевірити сумісність версій PHP, WordPress, WooCommerce і самого модуля.
Для CRM важливо встановити, чи проблема виникає під час відправлення запиту, чи вже після його прийняття. У першому випадку потрібно перевіряти сайт і мережеве з’єднання. У другому — формат JSON, відповідність полів, ідентифікатори товарів, статуси замовлення та правила дублювання в CRM. Для доставки додатково перевіряють адресу, телефон, місто, тип відділення, післяплату й обов’язкові поля конкретного API.
Тестування замовлення від початку до кінця
Після внесення змін не обмежуйтеся перевіркою кнопки «Створити вебхук» або успішним HTTP-відгуком. Потрібен повний контрольований тестовий сценарій від оформлення замовлення до появи коректних даних у CRM і службі доставки.
- Створіть тестове замовлення з унікальним номером або поміткою, щоб не переплутати його з реальною покупкою.
- Перевірте, чи замовлення створилося в WooCommerce та чи записалися всі товари, суми, контакти й спосіб оплати.
- Перегляньте журнал вебхука і переконайтеся, що подія була відправлена саме після потрібної зміни статусу.
- Перевірте відповідь CRM: чи створено клієнта, угоду, замовлення або завдання менеджеру.
- Перевірте створення накладної або заявки в службі доставки, якщо це передбачено сценарієм.
- Змініть статус замовлення та перевірте, чи передається оновлення без створення дубля.
- Порівняйте дані в усіх системах і після завершення тесту видаліть або позначте тестові записи згідно з правилами сервісів.
Окремо перевірте сценарії оплати, скасування, повернення, часткової зміни замовлення та повторної відправки події. Інтеграція може працювати для нового замовлення, але ламатися під час зміни статусу або передачі нестандартного товару.
Як контролювати чергу невдалих подій
Якщо вебхуки надсилаються у фоновому режимі, разова помилка може залишити подію в черзі. Перевірте Action Scheduler або інший механізм, який використовує плагін інтеграції. Важливі показники — кількість очікуваних, виконаних і невдалих завдань, час останнього запуску та текст помилки.
Не запускайте масове повторення всіх невдалих подій без перевірки. Якщо CRM уже прийняла частину запитів, повтор може створити дублікати клієнтів, замовлень або накладних. Спочатку визначте, які події справді не були прийняті, а потім повторюйте їх вибірково або через передбачений інтеграцією механізм ідемпотентності.
- Налаштуйте регулярний контроль черги та журналів, а не лише перевірку після скарги клієнта.
- Слідкуйте за повідомленнями про помилки cron, PHP, API та перевищення лімітів.
- Перевіряйте, чи не накопичуються завдання через низький ліміт пам’яті або короткий тайм-аут.
- Зберігайте резервні копії перед очищенням черги, видаленням плагінів або змінами бази даних.
- Фіксуйте дату, номер замовлення, подію, відповідь сервера та виконану дію для кожної проблемної операції.
Спеціаліст потрібен, якщо після міграції одночасно зникли вебхуки, не працює REST API, накопичуються сотні невдалих завдань, є помилки бази даних або незрозуміло, чи були створені дублікати. У таких випадках самостійні зміни в базі, масове повторення подій або перевстановлення інтеграцій можуть погіршити ситуацію. Безпечна діагностика має починатися з копії даних, аналізу логів і точного визначення етапу, на якому переривається обмін.