Виправлення помилок у WooCommerce-оформленні замовлення - дублі оплат, розсинхронність статусів та падіння на high-load

Після оновлення WordPress та частини плагінів на бойовому інтернет-магазині (предметна область - продаж автозапчастин, ~8-12 тис SKU, 300-600 замовлень/добу, піки до 30 замовлень/хв) з'явилися критичні помилки в оформленні замовлення та обробці оплат.

Вихідна ситуація та середа
- WordPress 6.5.x, WooCommerce 8.x
- PHP 8.2, Nginx + PHP-FPM, MariaDB 10.6
- Redis object cache, Cloudflare, WP-Cron вимкнено - використовується system cron
- Платежі: Stripe та локальний еквайринг через окремий плагін (webhook + callback)
- Доставка: кастомний модуль розрахунку тарифів + інтеграція із зовнішнім API (таймаути у піку)
- Є самописний must-use плагін, який додає доп.поля замовлення та синхронізує статуси з 1С через REST

Симптоми
- Іноді створюються дублі замовлень при оплаті карткою - один у статусі processing, другий pending
- Вебхукі Stripe періодично не змінюють статус замовлення, хоча в Stripe подія доставлена
- На піку навантажень частина користувачів бачить 500 на /checkout/ та у логах зустрічаються fatal error та deadlock/lock wait timeout при записі замовлення
- В адмінці WooCommerce іноді не відкривається картка замовлення – білий екран через JS-помилки на сторінці редагування

Що потрібно зробити
- Відтворити проблеми у staging, зібрати трасування, виявити першопричини та виправити без відключення ключових інтеграцій
- Розібрати конфлікт версій/хуків WooCommerce з самописними плагінами та платіжними модулями, усунути подвійну обробку подій оплати та гонки під час створення замовлення
- Починати обробку webhooks/callback так, щоб статуси та метадані замовлення оновлювалися рівно один раз, навіть при повторній доставці подій та мережевих ретраях
- Усунути 500-помилки на checkout, включаючи проблеми з таймаутами зовнішнього API доставки та блокуваннями в БД
- Виправити JS-помилку на сторінці замовлення в адмінці (конфлікт скриптів/залежностей після оновлення), не ламаючи кастомні метабокси

Обмеження
- Роботи виконуються з мінімальними змінами теми - всі правки через child theme та/або окремий плагін, без правки ядра WooCommerce/WordPress
- Не можна відключати Redis, Cloudflare та системний cron у проді – перевірка тільки через staging та акуратний реліз
- Доступи: staging + read-only доступ до логів продакшена, зміни в проді через PR в Git та деплой через існуючий pipeline

Очікуваний результат
- Виправлення у вигляді коммітів/PR зі зрозумілим описом причин та рішень
- Набір діагностичних логів/метрик (в рамках доступних засобів WP/Woo) для контролю повторних помилок
- Коротка інструкція, що моніторити та як безпечно відкочуватися

Критерії приймання (вимірні)
1) За 48 годин тестової експлуатації на staging при прогоні навантаження не виникає дублів замовлень - 0 дублів на 1000 тестових оплат
2) Stripe webhook/callback ідемпотентен - повторна доставка однієї і тієї ж події не змінює замовлення більше 1 разу і не створює нового
3) При тесті навантаження на checkout (мінімум 20 rps протягом 30 хвилин) частка 5xx - не більше 0.2%, середній TTFB сторінки checkout - до 800 мс на staging
4) Помилка адмінки WooCommerce Orders, що відтворювала білий екран, усунена - картка замовлення відкривається і зберігається без JS-помилок в консолі

Додатково
- Дам логі Nginx/PHP-FPM, WooCommerce logs, доступ до Git-репозиторію, список останніх оновлень та 3-5 прикладів проблемних замовлень/платежів.