Оформлення замовлення WooCommerce не працює: діагностика SSL, платежів і конфліктів плагінів

Швидкий план діагностики

Якщо ви зараз на чергуванні, почніть тут. Це послідовність з найвищим відношенням сигнал/шум, щоб швидко знайти вузьке місце.

1) Підтвердіть, що проблема реальна і визначте межі

• Спробуйте оформлення в інкогніто з дешевим товаром. Зафіксуйте точний симптом: індикатор, редирект, помилка шлюзу, порожня сторінка або створене замовлення з невдалим платежем.
• Спробуйте іншу мережу (мобільний хотспот). Якщо там працює — підозрюйте дивні DNS/WAF/кешування в першій мережі.
• Перевірте інший браузер. Якщо тільки Safari не працює, швидше за все це пов’язано з правилами крос-сайт cookie, iframe-платежами або агресивним блокуванням трекінгу.

2) Подивіться консоль браузера та мережеві запити перед тим, як торкатися сервера

• Відкрийте DevTools → Console для JS-помилок.
• DevTools → Network → фільтруйте за ?wc-ajax=checkout, admin-ajax.php та кінцевими точками шлюзів. Слідкуйте за кодами статусу та тілом відповіді.

3) Перевірте логи WooCommerce (вони нудні, тому працюють)

• WooCommerce → Status → Logs. Шукайте логи шлюзів, фатальні помилки, збої вебхуків.
• WordPress debug log та PHP-FPM error log, якщо ви керуєте сервером.

4) Визначте, в якій «смузі» ви працюєте

Більшість відмов оформлення потрапляють в одну з цих зон:

1. SSL/HTTPS або кукі: петлі редиректів, змішаний вміст, «nonce invalid», нескінченний індикатор.
2. Шлюз/API: Stripe/PayPal відмовляють, вебхуки не доходять, проблеми з 3DS.
3. Плагін/тема/кешування: зламаний JS, блокований AJAX, кешовані сторінки оформлення.
4. Обмеження сервера: таймаути, помилки пам’яті, повільна БД, диск заповнений, завантаження CPU.

5) Застосуйте найменш ризикові швидкі пом’якшення

• Вимкніть кешування повних сторінок для /cart/, /checkout/, /my-account/ та всіх кінцевих точок ?wc-ajax=.
• Тимчасово переключіться на дефолтну тему та вимкніть неважливі плагіни на копії staging (або використайте підхід «вимкнути тільки на оформленні», якщо доводиться робити в live).
• Відкотіть останню зміну: оновлення плагіна, оновлення теми, правило CDN/WAF, оновлення PHP. Ламаються оформлення саме після свіжих змін.

Мапа відмов оформлення: де ламається і як виглядає

Браузерний і JavaScript шар

Симптоми: кнопка Оформити замовлення нічого не робить, індикатор крутиться вічно, поля не валідуються, елемент оплати не завантажується.

Типові причини: некоректна мінімізація JS, блокування через змішаний вміст, тема перезаписує шаблони оформлення, застарілі скрипти шлюзу, правила CSP або скрипти, які вставляються плагінами і викликають синтаксичні помилки.

WooCommerce AJAX / REST шар

Симптоми: 400 або 403 на ?wc-ajax=checkout, «nonce invalid», втрата сесії, кошик очищується при оновленні.

Типові причини: кешування, блокування cookie, правило WAF на боці сервера, Cloudflare/edge кешування або некоректно сконфігурований site URL / HTTPS.

WordPress / PHP шар

Симптоми: HTTP 500, порожня сторінка, «critical error», випадкові збої під навантаженням.

Типові причини: фатальні помилки PHP, замалий ліміт пам’яті, проблеми з opcode cache, несумісні версії плагінів або вичерпання воркерів PHP-FPM.

Шар бази даних та зберігання

Симптоми: оформлення іноді працює, але повільно; замовлення створюються без частини метаданих; дедлоки; періодична «помилка бази даних».

Типові причини: повільні запити MySQL, насичений I/O, повний диск, відсутні індекси або важкі фонові завдання, що конкурують за записи під час оформлення.

Шар шлюзів і вебхуків

Симптоми: замовлення застрягли в статусі «очікує оплати», платіж стягнуто, але замовлення не позначено як оплачене, клієнт стягнуто, але лист не надіслано, повернення не проходять.

Типові причини: проблеми з доставкою вебхуків, неправильний секрет вебхука, блокування вхідних запитів, API-ключі для іншого середовища, 3DS-потоки блокуються або зсув годинника сервера ламає підписи.

Цікаві факти та коротка історія (так, це важливо)

• WooCommerce починався як плагін WooThemes і пізніше був придбаний Automattic; тому конвенції WordPress пронизують усе, на краще і на гірше.
• Оформлення використовує змішання classic admin-ajax та WooCommerce AJAX кінцевих точок; до кожного маршруту застосовуються різні припущення безпеки і кешування.
• «Nonce» у WordPress — це не криптографічний nonce; це токени з часовим вікном, прив’язані до сесій. Якщо кеши або проксі повторно віддають сторінки, nonces псуються.
• Тиск вимог PCI — причина, чому багато шлюзів перенесли введення карт в hosted fields (iframes/elements). Це робить сучасні оформлення чутливими до CSP, змішаного вмісту та правил сторонніх кукі.
• 3-D Secure (3DS) потоки стали значно поширенішими після правил SCA в Європі; шлюзи тепер вимагають додаткові кроки в браузері, які легко ламаються при порушенні JS або редиректів.
• HSTS може зробити «в мене працює» неправдою; як тільки браузер кешує HSTS, він буде примушувати HTTPS навіть якщо ви пізніше зламаєте HTTPS.
• Багато «проблем з оформленням» — це фактично баги кешування: кешувати персоналізовану сторінку — це як ксерокопіювати паспорт і передавати його наступному клієнту.
• Повторні спроби вебхуків не безкінечні. Якщо ваш сервер блокує callback шлюзу кілька годин, потім ви ручно узгоджуватимете платежі.
• Cloud WAF дедалі частіше за замовчуванням блокує «підозрілі» POST-запити; форми оформлення — це просто буфет полів, що можуть спровокувати правила.

SSL та HTTPS: змішаний вміст, HSTS і петлі редиректів

Як SSL конкретно ламає оформлення

Проблеми зі SSL рідко з’являються у вигляді дружнього банера «SSL не працює». Натомість ви отримуєте побічні ефекти:

• Віджети оплати не завантажуються, бо один скрипт подається по HTTP (змішаний вміст блокується).
• Кукі не встановлюються, бо ви скакаєте між HTTP і HTTPS або між www і безwww доменом.
• Валідація nonce не проходить, бо кешований контент віддається між схемами.
• Петлі редиректів, бо WordPress вважає, що site URL — HTTP, а проксі завершує TLS, або навпаки.

Змішаний вміст: мовчазний вбивця оформлення

Сучасні браузери блокують небезпечні ресурси на захищених сторінках. Ви побачите в консолі повідомлення «Mixed Content: The page was loaded over HTTPS, but requested an insecure resource.» Коли таким незахищеним ресурсом є JS платіжного шлюзу або скрипт валідації оформлення, оформлення стає інтерпретативним танцем.

Зворотні проксі і «is_ssl()», які брешуть

Якщо ви за load balancer або CDN, що завершує TLS, то origin-сервер може бачити лише HTTP. Тоді WordPress генерує HTTP-URL, некоректно встановлює кукі і покладається на хибний сигнал для безпечної поведінки.

Зазвичай виправлення — переконатися, що проксі ставить X-Forwarded-Proto: https, і WordPress налаштований довіряти цьому (зазвичай через стек хостингу). Не «виправляйте» це жорстким прописуванням редиректів у п’яти файлах. Це створює петлі, які трапляються лише вівторками.

Два точні правила

• Правило 1: сторінки оформлення та облікового запису повинні бути послідовно HTTPS з одним канонічним іменем хоста.
• Правило 2: ніколи не кешуйте сторінки, що містять nonces, кошики, сесії або персоналізовані фрагменти.

Платежі: шлюзи, вебхуки, 3DS і «замовлення вічно в очікуванні»

Дві складові «платіж завершено»

Успішний платіж зазвичай — це два події:

1. Клієнт завершує на-сторінці потік (токенізація/авторизація/захоплення).
2. Шлюз надсилає серверний вебхук, що підтверджує фінальний стан.

Якщо #1 працює, але #2 не доходить, ви отримуєте кошмар: клієнтів стягують, але замовлення стоять у статусі «очікує оплати» або «on-hold». Це не «проблема шлюзу». Це проблема надійності інтеграції, і її потрібно вирішувати вам.

Stripe: типові точки зламу

• Невідповідність секрету вебхука: події приходять, але підписи не проходять валідацію.
• Неправильні API-ключі: live-сайт використовує тестові ключі або навпаки; іноді лише деякі клієнти спричиняють збої через різні методи оплати.
• Модаль 3DS блокується: агресивний CSP, зламаний JS або втручання плагінів оптимізації.

PayPal: типові точки зламу

• Проблеми з Return URL: невідповідність схеми/хоста призводить до невдалого повернення із PayPal або петлі до кошика.
• IPN/webhook блокується: вхідні callback-и блокує фаєрвол, WAF або невірна маршрутизація DNS.

Жарт №1: Інтеграція платіжного шлюзу схожа на дружбу: все добре, поки хтось не припинить вам відповідати, а потім усе «в очікуванні».

Зсув годинника: несподівано реальна причина відмов оформлення

Підписані payload’и вебхуків та аутентифікація API можуть упасти, якщо годинник сервера йде не в ногу. Якщо NTP не працює, ваш конвеєр замовлень стає квантовим: оплачено і не оплачено одночасно.

Конфлікти плагінів і тем: мовчазні вбивці

Чому оформлення притягує конфлікти

Сторінки оформлення — це місце, де кожен плагін хоче мати свій момент на сцені: аналітика, пікселі, апселли, мультивалюта, валідація адрес, кешування, безпека, згода на кукі, «покращити конверсію», «покращити продуктивність», «підвищити щастя». Більшість роблять це, вставляючи скрипти та фільтруючи вивід. Достатньо одного «поганого актора», щоб зламати весь runtime.

Як думати про конфлікти

• JS-конфлікти: один скрипт кидає виключення, і решта JS оформлення перестає виконуватись.
• Перезапис шаблонів: теми, що перезаписують шаблони WooCommerce, можуть бути застарілими щодо вашої версії WooCommerce.
• Хуки валідації: плагіни додають кастомні поля оформлення, але не обробляють крайні випадки, що викликає помилки валідації.
• Плагіни безпеки: блокують AJAX-ендпоінти, REST-запити або тіла POST.

Перестаньте «оптимізувати» оформлення за методом мінімізації/об’єднання

Плагіни мінімізації, що конкатенують скрипти, можуть зламати hosted fields шлюзів і фрагменти оформлення. Якщо ви не можете пояснити граф залежностей — не дозволяйте плагіну «автооптимізувати» його.

Кешування, CDN і правила WAF, які саботують оформлення

Що ніколи не слід кешувати

• /cart/, /checkout/, /my-account/
• Будь-який URL з add-to-cart=, wc-ajax= або параметрами сесії
• Відповіді, які встановлюють кукі, наприклад woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_*

Підводні камені CDN

CDN чудові, поки вони не вирішать, що ваше оформлення — «статичне». Тоді клієнти діляться сесіями, ніби це суспільний город. Також: керовані правила WAF іноді позначають POST оформлення як SQL injection, бо адреси та імена виглядають як користувацький ввід (бо такими й є).

Заголовки безпеки: добрі наміри, зламані платежі

Content Security Policy (CSP) і налаштування SameSite кукі можуть зламати сторонні платіжні потоки. CSP можна використовувати; просто не робіть цього наосліп. Почніть з режиму report-only, зберіть порушення, а потім посилюйте.

Жарт №2: Єдина річ більш впевнена, ніж WAF, — це маркетинговий плагін, який «гарантує» кращі конверсії.

Проблеми на боці сервера: PHP, БД, диск і таймаути

Оформлення — це write-heavy запит: воно створює замовлення, оновлює запаси, зберігає метадані, можливо звертається до шлюзу, можливо викликає API для податків/доставки, а потім відправляє листи. Це багато рухомих частин в одному HTTP-запиті.

PHP-FPM і вичерпання воркерів

Коли PHP-FPM закінчуються воркери, запити чекають у черзі. Оформлення таймаутить, браузери повторюють спроби, і ви створюєте дублікати замовлень. Ось чому ви прокидаєтесь з питанням «чому у нас 200 очікуваних замовлень?»

Продуктивність бази даних і блокування

WooCommerce зберігає багато даних у таблицях постів і метаданих. Під навантаженням, погано індексовані запити та конкуренція за блокування можуть зробити оформлення повільним і нестабільним. Якщо ви бачите сплески CPU бази або логів повільних запитів, вам потрібне не «більше кешу», а виправлення навантаження на БД.

Диск заповнений: найсоромніший відкат

Якщо диск заповнений, PHP не може записувати сесії, логи або тимчасові файли; MySQL не може флашити; і WordPress починає падати в креативні способи. Збої зі сховищем рідко попереджають ввічливо.

Одна цитата про надійність (перефразована ідея)

«Надія — це не стратегія.» — перефразована ідея, яку часто приписують досвідченим операційним лідерам. В лендінгу оформлення ви перевіряєте логи й трасування, або просто пливете за відчуттями.

Практичні діагностичні завдання (команди + вивід + рішення)

Це реальні завдання, які ви можете виконати на типовому Linux-host з Nginx/Apache, PHP-FPM та MySQL/MariaDB. Використайте їх, щоб перейти від «оформлення зламалося» до «цей конкретний компонент відмовляє». Кожне завдання включає: команду, приклад виводу і рішення.

Завдання 1: Підтвердити DNS і TLS з сервера

cr0x@server:~$ dig +short A example-shop.com
203.0.113.10
cr0x@server:~$ echo | openssl s_client -servername example-shop.com -connect example-shop.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = example-shop.com
issuer=CN = R3, O = Let's Encrypt, C = US
notBefore=Nov  1 00:00:00 2025 GMT
notAfter=Jan 30 23:59:59 2026 GMT

Що це означає: DNS вказує куди очікується і сертифікат відповідає hostname з дійсними датами.

Рішення: Якщо CN/SAN не відповідає, виправте сертифікат/віртуальний хост. Якщо DNS вказує на іншу IP, ніж origin, конфіг CDN/load balancer може бути невірною.

Завдання 2: Виявити петлі редиректів або плутанину HTTP→HTTPS

cr0x@server:~$ curl -I -L -s -o /dev/null -w '%{url_effective} %{http_code} %{num_redirects}\n' http://example-shop.com/checkout/
https://example-shop.com/checkout/ 200 1
cr0x@server:~$ curl -I -s https://example-shop.com/checkout/ | egrep -i 'location:|set-cookie:|strict-transport-security'
strict-transport-security: max-age=31536000; includeSubDomains; preload
set-cookie: wp_woocommerce_session_123abc=...; path=/; secure; HttpOnly

Що це означає: Один редирект на HTTPS — нормально. Наявність Secure cookie на checkout — добре.

Рішення: Якщо num_redirects великий або статус 301/302 зациклюється, виправте WordPress Site URL/Home URL та заголовки проксі перед тим, як чіпати плагіни.

Завдання 3: Знайти кандидати на змішаний вміст у згенерованому HTML

cr0x@server:~$ curl -s https://example-shop.com/checkout/ | egrep -o 'http://[^"]+' | head
http://example-shop.com/wp-content/plugins/some-plugin/js/tracker.js
http://fonts.example.net/somefont.woff2

Що це означає: HTML оформлення посилається на HTTP-ресурси; браузери можуть їх блокувати.

Рішення: Виправте жорстко закодовані HTTP URL у налаштуваннях теми/плагіна, або скоригуйте налаштування WordPress URL і виконайте правильну заміну контенту (обережно), якщо потрібно.

Завдання 4: Дивитися логи Nginx/Apache для запитів оформлення в реальному часі

cr0x@server:~$ sudo tail -f /var/log/nginx/access.log | egrep 'checkout|wc-ajax=checkout|admin-ajax.php'
203.0.113.55 - - [27/Dec/2025:11:02:13 +0000] "POST /?wc-ajax=checkout HTTP/2.0" 400 182 "-" "Mozilla/5.0"
203.0.113.55 - - [27/Dec/2025:11:02:13 +0000] "GET /checkout/ HTTP/2.0" 200 98234 "-" "Mozilla/5.0"

Що це означає: AJAX-ендпоінт оформлення повертає 400. Це не «питання теми», поки не доведено інше.

Рішення: Перейдіть до PHP/Woo логів, щоб побачити точну помилку (nonce, валідація, відповідь шлюзу).

Завдання 5: Проінспектувати стан PHP-FPM та навантаження на воркери

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Active: active (running) since Sat 2025-12-27 09:10:02 UTC; 1h 52min ago
cr0x@server:~$ sudo grep -i 'server reached pm.max_children' /var/log/php8.2-fpm.log | tail -3
[27-Dec-2025 10:59:01] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it

Що це означає: PHP-FPM насичується. Під навантаженням оформлення стоятиме в черзі або таймаутитиме.

Рішення: Збільшуйте pm.max_children лише якщо CPU/RAM дозволяють; інакше зменшіть навантаження плагінів, додайте кешування для неоформлювальних сторінок і виправте повільні запити.

Завдання 6: Знайти фатальні помилки PHP, що тригеряться під час оформлення

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:02:13] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_order() in /var/www/html/wp-content/plugins/custom-checkout/hooks.php:41
Stack trace:
#0 /var/www/html/wp-includes/class-wp-hook.php(324): custom_checkout_validate()

Що це означає: Плагін викликає функції WooCommerce неправильно або надто рано, спричиняючи фатальну помилку під час оформлення.

Рішення: Вимкніть або виправте плагін. Фатальна помилка — це не «можливо». Це критичний дефект.

Завдання 7: Підтвердити, що WordPress може писати сесії та диск не заповнений

cr0x@server:~$ df -h / /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  0.9G  98% /
cr0x@server:~$ sudo du -sh /var/log | tail -1
6.2G	/var/log

Що це означає: Майже закінчився диск. Бази даних і PHP будуть падати дивними помилками при 99–100% заповнення.

Рішення: Негайно звільніть місце (ротація/сжаття логів, видалення старих бекапів), потім налаштуйте моніторинг/алерти. Заповнений диск — це політична помилка, а не таємниця.

Завдання 8: Перевірити доступність MySQL і поточне навантаження

cr0x@server:~$ mysqladmin -uroot -p ping
mysqld is alive
cr0x@server:~$ mysql -uroot -p -e "SHOW GLOBAL STATUS LIKE 'Threads_running';"
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Threads_running | 58    |
+-----------------+-------+

Що це означає: MySQL працює, але 58 running threads часто означає «нам важко» на маленькій інстанції.

Рішення: Проаналізуйте повільні запити та lock waits; розгляньте масштабування БД або оптимізацію запитів/плагінів, що генерують важкі meta-запити.

Завдання 9: Виявити повільні запити під час вікна оформлення

cr0x@server:~$ sudo tail -n 20 /var/log/mysql/slow.log
# Time: 2025-12-27T11:02:13.123456Z
# Query_time: 3.812  Lock_time: 0.002 Rows_sent: 1  Rows_examined: 250000
SELECT post_id FROM wp_postmeta WHERE meta_key='_billing_email' AND meta_value='user@example.com';

Що це означає: Meta-запит сканує забагато рядків. Оформлення часто тригерить такі пошуки через плагіни (CRM, fraud, збігання акаунтів).

Рішення: Зменшіть або вимкніть функцію плагіна, додайте відповідні індекси (обережно) або переробіть шлях запиту. Кидати кеш на write-шляхи рідко має хороший ефект.

Завдання 10: Підтвердити, що endpoint вебхуків доступний зовнішньо

cr0x@server:~$ curl -s -o /dev/null -w "%{http_code}\n" https://example-shop.com/?wc-api=wc_stripe
200
cr0x@server:~$ sudo tail -n 50 /var/log/nginx/access.log | egrep 'wc-api=wc_stripe|webhook'
198.51.100.22 - - [27/Dec/2025:11:01:44 +0000] "POST /?wc-api=wc_stripe HTTP/2.0" 200 42 "-" "Stripe/1.0 (+https://stripe.com/docs/webhooks)"

Що це означає: Endpoint відповідає, і ви бачите вхідні POST-и.

Рішення: Якщо POST-ів немає — шлюз не досягає вас (DNS/firewall/WAF). Якщо є 4xx/5xx — виправте обробку в додатку або правила WAF.

Завдання 11: Виявити, чи WAF або плагін безпеки блокує тіла POST

cr0x@server:~$ sudo grep -iE 'modsecurity|access denied|waf|forbidden' /var/log/nginx/error.log | tail -10
2025/12/27 11:02:13 [error] 1234#1234: *8890 ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Rx' with parameter `(?i:select.+from)'" against variable `ARGS:billing_address_1'

Що це означає: Правило WAF помилково відмічає поля оформлення як SQLi.

Рішення: Додайте таргетований виняток для endpoint-ів оформлення, а не загальне відключення. Зберігайте безпеку, але навчіть її манерам.

Завдання 12: Перевірити site URL і налаштування HTTPS через WP-CLI

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get home
https://example-shop.com
cr0x@server:~$ wp option get siteurl
https://example-shop.com

Що це означає: WordPress вважає, що працює на HTTPS з правильним хостом.

Рішення: Якщо ці значення HTTP або неправильний домен — виправте їх. Невідповідність URL створює петлі редиректів і проблеми з областю cookie.

Завдання 13: Швидко перевірити активні плагіни (і помітити ризикові)

cr0x@server:~$ wp plugin list --status=active
+---------------------------+--------+-----------+---------+
| name                      | status | update    | version |
+---------------------------+--------+-----------+---------+
| woocommerce               | active | available | 9.3.2   |
| woocommerce-gateway-stripe| active | none      | 8.7.0   |
| wp-rocket                 | active | none      | 3.16.0  |
| wordfence                 | active | none      | 7.11.0  |
| some-minify-plugin        | active | none      | 2.4.1   |
+---------------------------+--------+-----------+---------+

Що це означає: Ви бачите кешуючі/захисні/мінімізуючі плагіни, які часто заважають оформленню.

Рішення: Якщо оформлення зламалося після оновлення — відкотіть саме цей плагін першим. Якщо треба тестувати, вимкніть оптимізації/мінімізацію на URL оформлення.

Завдання 14: Перевірити, чи cron не заважає завершенню замовлень і оновленням складу

cr0x@server:~$ wp cron event list | head
+-------------------+---------------------+---------------------+------------+
| hook              | next_run_gmt        | next_run_relative   | recurrence |
+-------------------+---------------------+---------------------+------------+
| wc_cleanup_sessions | 2025-12-27 11:05:00 | in 2 minutes        | hourly     |
| woocommerce_scheduled_sales | 2025-12-27 12:00:00 | in 57 minutes | hourly     |
+-------------------+---------------------+---------------------+------------+
cr0x@server:~$ wp cron test
Success: WP-Cron spawning is working as expected.

Що це означає: WP-Cron працює. Якщо він не працює — відкладені завдання (наприклад фіналізація захоплення платежу в деяких налаштуваннях) можуть затримуватись.

Рішення: Якщо WP-Cron падає — налаштуйте реальний системний cron, який викликає wp-cron.php, і переконайтесь, що вихідні HTTP-запити дозволені.

Три корпоративні міні-історії з поля бою

Міні-історія 1: Аутейдж через неправильне припущення

Компанія перейшла на новий load balancer. TLS завершувався на edge, трафік до origin ішов по HTTP, і всі погоджувалися, що це нормально. Вітрина виглядала добре. Сторінки товарів відкривалися. Додавання в кошик працювало. Тому команда вважала міграцію успішною.

Оформлення, однак, почало відмовляти періодично. Не у всіх і не завжди. Симптом — індикатор, а потім загальна помилка. Консоль браузера не показувала очевидного. Тикети підтримки надходили з однаковими скриншотами: «Щось пішло не так.» Класика.

Нарешті хтось помітив закономірність: користувачі з збереженими методами оплати падали частіше. Це був ключ. Збережені методи сильніше опираються на сесії і nonces, які пов’язані з кукі. Кукі у свою чергу встановлювалися непослідовно, бо WordPress не міг надійно визначити HTTPS на origin.

Неправильне припущення було просте: «Якщо сайт завантажується по HTTPS, WordPress знає, що він на HTTPS.» За проксі це не гарантується. Фікс теж був простий: виправити forwarded headers, налаштувати origin довіряти їм і узгодити канонічні URL. Оформлення одразу стабілізувалося, ніби за магією. Це була не магія — це математика плюс HTTP.

Міні-історія 2: Оптимізація, що відбилась боком

Ініціатива з продуктивності мала благу мету: покращити Core Web Vitals. Команда включила агресивну оптимізацію JS: мінімізацію, об’єднання, defer, delay і «видалити невикористане». Головна сторінка стала швидшою. Графіки виглядали чудово. У чаті були святкові повідомлення.

Потім конверсії впали. Не катастрофічно, але достатньо, щоб запалити фазу «нам здається». Підтримка згадувала про збої платежів, але не послідовно. Деякі клієнти завершували замовлення; інші не могли завантажити поле вводу картки або 3DS-виклик. Логи мали поодинокі таймаути шлюзу, але нічого остаточного.

Кулі були в оптимізаторі, який затримував скрипти, які він вважав «некритичними», включно з hosted payment fields. На деяких пристроях клієнт натискав Оформити замовлення до ініціалізації елемента оплати, тому запит оформлення йшов без токена платежу. WooCommerce зробив, що міг: створив замовлення, потім платіж зазнав невдачі.

Виправлення полягало не в тому, щоб відмовитись від роботи над продуктивністю. Потрібно було припинити ставитись до оформлення як до маркетингової сторінки. Вони виключили checkout, cart і account зі склеювання/відкладення JS і додали моніторинг помилок токенізації. Продуктивність лишилася там, де потрібно, а оформлення перестало тихо губити дохід.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Інша команда щотижня проводила «чумні вправи» оформлення. Не драматичні. Вони просто проходили одну реальну транзакцію через кожен метод оплати в staging, що віддзеркалював production: правила CDN/WAF, заголовки — усе. Вони також перевіряли доставку вебхуків і переходи статусів замовлень.

Ця практика здавалася нудною. Вона не давала блискучих дашбордів. За неї не плескали в долоні. Але вона виробила м’язову пам’ять: де лежать логи, як виглядає «нормально» і які панелі постачальників важливі під час інциденту.

Одної п’ятниці оновлення керованого правила WAF почало блокувати POST-и, що містили певні шаблони адрес. Перший симптом — невелике зростання відмов оформлення. Завдяки наявності бази та знанню, куди дивитися, вони знайшли 403-блокування за хвилини, додали таргетоване виняток для endpoint’у оформлення і продовжили жити далі.

Спасіння було не в героїзмі. Воно було в неефектній звичці тестувати весь платіжний ланцюжок, включно з вебхуками, як частину операцій — а не як паніку раз на рік.

Типові помилки: симптом → причина → виправлення

1) Індикатор крутиться вічно після «Оформити замовлення»

Симптом: кнопка оформлення крутиться; замовлення не створюється; мережа показує ?wc-ajax=checkout в очікуванні або з помилкою.

Причина: помилка JavaScript, заблокований AJAX-ендпоінт або черга/таймаути PHP-FPM.

Виправлення: Перевірте DevTools console, потім логи доступу/помилок сервера. Виключіть оформлення з JS-оптимізації. Збільшуйте потужність PHP-FPM тільки після виявлення повільних запитів.

2) «Nonce verification failed» / втрата сесії

Симптом: спорадичні збої; часто після довгого часу на сторінці; іноді лише на мобільних.

Причина: кешування сторінки з nonces; кукі блокуються; невідповідність HTTP/HTTPS; декілька доменів.

Виправлення: вимкніть кешування на checkout/cart/account, забезпечте один HTTPS-хост, підтвердіть secure кукі і узгоджені siteurl/home.

3) Петля редиректів між HTTP і HTTPS

Симптом: браузер каже «занадто багато редиректів»; curl показує повторювані 301/302.

Причина: налаштування URL WordPress не погоджуються з термінацією проксі; конфліктні правила редиректів в Nginx/Apache, WordPress і CDN.

Виправлення: Виберіть один шар редиректів (краще — edge або вебсервер), встановіть правильні WordPress site URLs, передавайте X-Forwarded-Proto і приберіть дублюючі редиректи.

4) Замовлення створюються, але застрягають «очікує оплати»

Симптом: клієнт стверджує, що оплатив; дашборд шлюзу показує успіх; WooCommerce залишається у статусі pending.

Причина: вебхук не доставлено або відхилено (невідповідність підпису, 403 від WAF, таймаут), або сайт не може опрацювати асинхронні callback-и.

Виправлення: перевірте доступність endpoint’у вебхуків, внесіть у білий список IP/user-agent шлюзу за потреби, підтвердіть секрети і переконайтесь, що сервер не таймаутить під час обробки вебхука.

5) Метод оплати не з’являється на оформленні

Симптом: секція шлюзу порожня; у консолі видно блокування скриптів.

Причина: змішаний вміст, надто суворий CSP, плагін на зразок ad-blocker або плагін мінімізації, що порушує порядок скриптів.

Виправлення: усуньте HTTP-активи; налаштуйте CSP, щоб дозволити домени шлюзу; виключіть скрипти шлюзу з мінімізації/затримки; тестуйте у чистому профілі браузера.

6) Оформлення працює для адмінів, але не для клієнтів

Симптом: ви можете оформити; клієнти — ні.

Причина: різниця кешування за cookie; поведінка за роллю; правила безпеки, які звільняють залогінених користувачів; проблеми гостевого оформлення.

Виправлення: тестуйте як незалогінений користувач; вимкніть кешування оформлення; переконайтесь, що гостеве оформлення увімкнено, якщо потрібно; перевірте правила WAF щодо анонімних користувачів.

7) Випадкова «Сталася помилка при обробці вашого замовлення» під навантаженням

Симптом: періодичні збої, часто під час кампаній.

Причина: досягнуто max children PHP-FPM, конкуренція в БД, таймаути зовнішніх API або лімітування на стороні шлюзу.

Виправлення: слідкуйте за насиченням воркерів і повільними запитами; додайте черги/повторні спроби де доречно; зменшіть синхронні зовнішні виклики під час оформлення.

8) Кошик очищується при оформленні

Симптом: товари зникають; «сесія минула».

Причина: кукі не зберігаються (SameSite/secure), кешування або невідповідність між www/апекс-доменом.

Виправлення: стандартизуйте hostname, забезпечте HTTPS скрізь, не кешуйте cart/checkout і перевірте атрибути кукі.

Чеклисти / поетапний план

Поетапно: стабілізувати оформлення за наступні 30–60 хвилин

1. Зупиніть зміни: жодних оновлень плагінів, редагувань правил CDN, розгортань тем — поки оформлення не працює.
2. Відтворіть з доказами: DevTools console + мережевий HAR, точне повідомлення про помилку та відмітка часу.
3. Перевірте логи доступу/помилок навколо відмітки часу для ?wc-ajax=checkout та endpoint’ів вебхуків.
4. Перевірте логи WooCommerce для шлюзу та фатальних помилок.
5. Вимкніть кеш сторінок для checkout/cart/account на всіх рівнях: плагін кешу, сервер, CDN.
6. Тимчасово вимкніть JS-оптимізацію на оформленні: combine/minify/defer/delay.
7. Підтвердіть канонізацію HTTPS: один хост, немає петель редиректів, secure кукі.
8. Перевірте конфігурацію шлюзу: API-ключі, секрет вебхука, endpoint доступний, правильне середовище.
9. Зменшіть радіус ураження: якщо конкретний метод оплати падає — тимчасово вимкніть його і направляйте клієнтів на робочий варіант, поки ви виправляєте корінь проблеми.
10. Оголосіть статус: внутрішні зацікавлені сторони мають отримати чіткий сигнал «оформлення під впливом», а не плітки.

Поетапно: знайти корінь проблеми, не зламавши більше

1. Зробіть базову діагностику системи: CPU, пам’ять, диск, насичення PHP-FPM, потоки БД, рівні помилок.
2. Порівняйте останні зміни: оновлення плагіна, зміна теми, апгрейд PHP, оновлення правила WAF, політика кешу CDN.
3. Ізолюйте конфлікти:
   • Тестуйте з дефолтною темою на staging.
   • Вимикайте неважливі плагіни на staging.
   • Повертайте їх пакетами, доки не зламається.
4. Перевірте вебхуки повністю: подія доходить, підпис валідується, статус замовлення оновлюється, лист відправляється.
5. Напишіть постмортем: що зламалося, чому це не було виявлено, і що ви будете моніторити наступного разу.

Операційний чеклист: зробіть майбутні відмови оформлення менш драматичними

• Налаштуйте алерти на сплески 4xx/5xx для ?wc-ajax=checkout і endpoint’ів вебхуків.
• Відстежуйте коефіцієнт успішних платежів за методом (Stripe, PayPal тощо), а не лише загальну кількість замовлень.
• Виключайте checkout/cart/account з кешування і з «автооптимізації» за політикою.
• Майтіть staging зі схожими правилами CDN/WAF, як в проді.
• Запускайте щотижневу синтетичну транзакцію, включно з підтвердженням вебхука.

Питання й відповіді

Чому оформлення WooCommerce працює для мене, але не для клієнтів?

Адміни часто обходять кешування і деякі правила безпеки, і у вас можуть бути інші cookie/сесії. Тестуйте як незалогінений у інкогніто. Якщо лише гості падають — підозрюйте кешування, область cookie або правила WAF, орієнтовані на анонімний трафік.

Який найшвидший спосіб зрозуміти, чи це конфлікт плагінів?

Помилка в консолі браузера плюс раптове зламане оформлення після оновлення — сильний сигнал. На staging переключіться на дефолтну тему і вимкніть усі неважливі плагіни. Якщо оформлення повертається — ви знайшли причину.

Чи дійсно потрібен HTTPS скрізь або тільки на оформленні?

Практично: скрізь. Змішані схеми створюють проблеми з cookie і сесіями, а сучасні браузери карають за частковий HTTPS. Також шлюзи очікують безпечне походження для багатьох потоків.

Чому замовлення застрягають у «pending payment», хоча Stripe показує оплачено?

Тому що «оплата» в інтерфейсі шлюзу — не те саме, що «замовлення позначене оплачено» в WooCommerce. Вебхуки узгоджують фінальний стан. Якщо доставка вебхука блокується або підпис не проходить валідацію, WooCommerce не оновить замовлення.

Чи можуть плагіни кешу зламати оформлення, навіть якщо вони кажуть, що виключають його?

Так. Виключення можуть бути неповними, перевизначені правилами CDN або зруйновані нормалізацією query-string. Перевіряйте заголовки (cache hit/miss) і переконайтесь, що CDN не кешує персоналізовані відповіді.

Чому оформлення падає тільки на мобільному Safari?

У Safari агресивне блокування трекінгу і обробка кукі можуть зламати сторонні вбудовані поля оплати або крос-сайт редиректи, якщо SameSite та secure атрибути некоректні. Також затримка скриптів може створювати гонки ініціалізації елементів оплати на повільніших пристроях.

Чи варто підвищувати ліміт пам’яті PHP, щоб виправити оформлення?

Тільки якщо у вас є докази вичерпання пам’яті (фатальні помилки, OOM kills). Підвищення пам’яті може сховати неефективні плагіни і погіршити щільність вузлів. Спочатку виправте повільний/збійний код.

Як зрозуміти, чи мій WAF блокує оформлення?

Шукайте 403-відповіді на ?wc-ajax=checkout і збіги правил у логах WAF або логах вебсервера. Якщо бачите ModSecurity/managed-rule хіти на поля оформлення — потрібен таргетований виняток.

Яка найпоширеніша причина «вчора було добре»?

Зміна, яку ви не пов’язали з оформленням: автопоновлення плагіна, оновлення керованого правила CDN/WAF або ввімкнення «функції оптимізації». Оформлення чутливе; ставтесь до змін як до підозрюваних, поки не перевірите.

Чи безпечно тимчасово вимкнути вебхуки як обхідний шлях?

Ні. Вебхуки — це спосіб надійної синхронізації стану платежів. Якщо вебхуки не працюють, виправте доступність/підписи/таймаути. Вимкнення просто перекладає роботу на ручну звірку, що не витримає масштабу.

Висновок: що робити далі (і що перестати робити)

Ось практичний набір наступних кроків:

1. Зберіть докази: одна невдала спроба оформлення з відміткою часу, мережевий запис DevTools для ?wc-ajax=checkout і релевантні логи WooCommerce/PHP.
2. Визначте смугу: SSL/кукі, шлюз/вебхуки, плагін/тема, кеш/WAF або обмеження сервера. Не дебажте п’ять зон одночасно.
3. Спочатку стабілізуйте: виключіть оформлення з кешування/оптимізації, приберіть останні зміни і тримайте хоча б один робочий метод оплати, якщо можливо.
4. Виправте корінь проблеми: узгодьте HTTPS/proxy заголовки, налаштуйте шлюз, приборкайте WAF або усуньте конфліктний плагін.
5. Зробіть це буденним: додайте моніторинг помилок AJAX оформлення і здоров’я вебхуків, і запускайте щотижневу синтетичну транзакцію.

Перестаньте випадково перемикати плагіни, ніби відмикаєте комбінаційний замок. Надійність оформлення — це не питання забобонів. Це питання спостережливості — слідуйте за запитом, читайте логи і вносьте по одній зміні за раз.