Дублікати замовлень у WooCommerce можуть з’являтися як під час оформлення покупки, так і після переходу до платіжної сторінки. Для власника магазину це означає плутанину в обліку, повторні повідомлення клієнту, неправильні залишки товарів і ризик подвійного списання коштів.
Важливо спочатку визначити, де саме виникає дублювання: у браузері, під час створення замовлення, у callback платіжної системи чи під час повторної обробки вебхука. Не варто одразу видаляти записи з бази даних або змінювати код на робочому сайті. Перед діагностикою зробіть резервну копію файлів і бази даних, оскільки необережне виправлення може призвести до втрати замовлень або порушення зв’язків між ними.
Для товарного бізнесу важливий не лише каталог, а й надійний облік кожного звернення. Наприклад, відвідувач сайту Phytoria очікує зрозумілого шляху від вибору продукції до контакту з продавцем. Це приклад клієнтського сценарію, а не твердження про платформу чи технічні проблеми цього сайту.
Як підтвердити дублювання замовлень
Спочатку потрібно відрізнити справжні дублікати від схожих, але незалежних замовлень. Перевірте в адмінпанелі WooCommerce:
- час створення замовлень;
- ідентифікатор клієнта або адресу електронної пошти;
- склад кошика, кількість товарів і суму;
- спосіб оплати та статус кожного замовлення;
- IP-адресу, якщо вона зберігається в метаданих або журналах;
- примітки до замовлення та записи платіжного шлюзу.
Якщо два замовлення мають однаковий склад, суму й були створені майже одночасно, це може свідчити про повторну відправку запиту. Однак однакові дані ще не доводять, що причиною є саме WooCommerce: клієнт міг двічі натиснути кнопку, оновити сторінку подяки або повторити оплату після затримки відповіді.
Перевірте журнали WooCommerce у розділі WooCommerce > Статус > Журнали, а також журнали вебсервера, PHP і платіжного модуля. У них можна побачити послідовність подій: створення замовлення, виклик платіжного API, отримання відповіді та зміну статусу.
Перевірка callback платіжної системи
Одна з найпоширеніших причин дублювання — неправильна обробка callback або webhook від платіжної системи. Після успішної оплати платіжний сервіс надсилає повідомлення на сайт. Якщо сервер відповідає із затримкою, повертає помилку або не підтверджує отримання даних, платіжна система може повторити запит.
Проблема виникає, коли обробник кожного такого запиту створює нове замовлення замість того, щоб знайти вже наявне. Надійна логіка має:
- перевіряти унікальний ідентифікатор платежу;
- знаходити пов’язане замовлення перед створенням нового;
- повторно обробляти статус без створення дубліката;
- перевіряти суму, валюту та підпис запиту;
- відповідати платіжній системі після коректної перевірки даних;
- записувати в журнал повторні callback і причину їх відхилення.
Окремо перевірте, чи не створюється замовлення одночасно стандартним процесом WooCommerce та власним кодом платіжного плагіна. Таке трапляється після встановлення додаткових модулів, інтеграції CRM або внесення змін у тему. Якщо один компонент створює замовлення під час checkout, а інший — після callback, результатом можуть стати два записи для однієї покупки.
Під час аналізу не змінюйте callback на робочому сайті без резервної копії та тестування. Помилка в перевірці підпису або статусу може не лише створювати дублікати, а й дозволити підроблені повідомлення про оплату.
Вплив повторних запитів і кешування
Дублювання може виникати через повторну відправку форми оформлення. Покупець натискає кнопку «Підтвердити замовлення», але сторінка довго завантажується. Він натискає кнопку ще раз, а сервер приймає обидва запити. Схожа ситуація можлива при нестабільному інтернет-з’єднанні або зависанні браузера.
Перевірте, чи:
- кнопка оформлення блокується після першого натискання;
- на фронтенді коректно працює AJAX-запит checkout;
- сервер не обриває запит через малий тайм-аут;
- плагін кешування не кешує кошик, checkout або сторінку подяки;
- CDN і проксі не повторюють POST-запити;
- захисний або оптимізаційний плагін не змінює JavaScript WooCommerce;
- після оплати користувача не повертає на сторінку, яка повторно запускає обробку.
Сторінки кошика, оформлення замовлення, оплати та підтвердження зазвичай повинні бути виключені з повносторінкового кешування. Також потрібно перевірити кеш об’єктів, Redis або Memcached, якщо через нього різні процеси отримують застарілі дані про сесію й кошик.
Для підтвердження причини корисно провести контрольний тест у безпечному середовищі: вимкнути кешування лише для checkout, увімкнути журнали та повторити оформлення з тестовим способом оплати. Якщо дублікати зникають, далі слід перевіряти налаштування кешу, оптимізацію скриптів і правила проксі.
Як виправити логіку без втрати даних
Перед будь-якими змінами створіть повну резервну копію бази даних і файлів. Якщо дублікати вже накопичилися, не видаляйте їх масово SQL-запитом: серед них можуть бути оплачені замовлення, записи з різними статусами або замовлення, які вже передані в CRM чи службу доставки.
Безпечна послідовність ремонту може бути такою:
- Зупинити автоматичну передачу підозрілих замовлень у CRM, склад або службу доставки, якщо це можливо.
- Зафіксувати приклади дублювання та зберегти журнали до внесення змін.
- Визначити, який саме компонент створює другий запис: checkout, callback, webhook, cron-завдання чи інтеграція.
- Додати перевірку унікальності платежу або зовнішнього ідентифікатора замовлення.
- Зробити обробку callback і повторних запитів ідемпотентною — повторний однаковий запит має оновлювати наявний запис, а не створювати новий.
- Перевірити блокування кнопки оформлення та виключення checkout із кешування.
- Провести тестові замовлення в копії сайту або на staging-середовищі.
Під час очищення вже створених дублікатів спочатку порівнюють платіжні транзакції, статуси, час створення та факт передачі замовлення в зовнішні системи. Об’єднання або видалення записів виконується лише після визначення правильного замовлення. Іноді безпечніше залишити запис у базі, змінити його статус на скасований і додати внутрішню примітку, ніж фізично видаляти дані.
Якщо проблема пов’язана з кастомним кодом, краще перевірити хуки WooCommerce, AJAX-обробники, REST API та функції, які викликають створення замовлення. Для складних випадків, коли дублікати пов’язані з оплатами або інтеграціями, може знадобитися ремонт оформлення замовлень WooCommerce із попередньою діагностикою сайту.
Спеціаліст потрібен, якщо дублікати виникають нерегулярно, журнали містять помилки PHP або сервера, платіжний шлюз повторює callback, а також коли магазин підключений до CRM, ERP, служб доставки чи кількох платіжних систем. У таких ситуаціях локальна зміна кнопки або видалення зайвих замовлень може приховати симптом, але не усунути причину.
Що тестувати після ремонту магазину
Після внесення змін потрібно перевірити не лише створення одного замовлення, а й поведінку системи за нестандартних умов. Мінімальний набір тестів включає:
- одне оформлення з оплатою карткою та одним натисканням кнопки;
- повторне натискання кнопки під час повільного завантаження;
- оновлення сторінки checkout і сторінки подяки;
- повторний callback із тим самим ідентифікатором платежу;
- повторний callback зі зміненим або некоректним підписом;
- невдалу оплату з подальшою повторною спробою;
- скасування платежу та повернення коштів;
- оформлення замовлення з мобільного пристрою;
- роботу магазину з увімкненим кешем і CDN;
- передачу даних у CRM, склад та службу доставки.
Після кожного тесту звіряйте кількість замовлень, платіжних транзакцій, списань і записів у зовнішніх системах. Перевірте, чи правильно змінюються статуси та чи не створюються дублікати після запуску запланованих завдань cron.
Також варто залишити моніторинг журналів на кілька днів і налаштувати сповіщення про повторні callback, помилки сервера та незвичне збільшення кількості замовлень. Остаточний висновок про причину можна робити лише після аналізу конкретної конфігурації WooCommerce, платіжного модуля, кешування та інтеграцій.
Щоб перевірки не закінчилися разовим ремонтом, заздалегідь погодьте перелік робіт із технічної підтримки сайту: контроль журналів, резервні копії та перевірку інтеграцій після оновлень. Якщо збій уже порушив роботу магазину, окремо узгодьте порядок відновлення сайту зі збереженням актуальних замовлень і перевіркою результату.