---
title: Магазин работает, а заказов нет — 5 тихих поломок чекаута, которые не видит обычный мониторинг
description: Интернет-магазин открывается, товары на месте, а заказы не приходят. Разбираем 5 тихих поломок приёма заказов в WooCommerce и 1С-Битрикс — платёжный шлюз в тест-режиме, рост несостоявшихся заказов, сломанное оформление — и как ловить их автоматически изнутри CMS.
source: https://pingvera.ru/blog/magazin-rabotaet-a-zakazov-net.html
---
# Магазин работает, а заказов нет: 5 тихих поломок чекаута, которые не видит обычный мониторинг

У интернет-магазина есть режим отказа страшнее падения. Когда сайт лежит — это все видят, чинят, извиняются. А когда витрина открывается, товары на месте, корзина складывает суммы, **но заказы не проходят** — магазин может «работать» так днями. Реклама крутится, посетители приходят, добавляют товар, жмут «Оформить» — и уходят. Каждый час такого «работающего» магазина стоит денег, и никто не знает, что счётчик уже тикает.

## Пять поломок, при которых магазин выглядит здоровым

### 1. Платёжный шлюз остался в тестовом режиме

Классика после любых работ с оплатой: подрядчик переключил Stripe, ЮKassa или PayPal в тестовый режим, проверил и забыл вернуть. Витрина идеальна, оформление проходит, но реальные карты не списываются — либо оплаты «проходят» в песочнице и не приносят ни рубля. Снаружи это не видно вообще никак: страница оплаты открывается, форма рисуется.

### 2. Обновление сломало оформление заказа

Обновили плагин корзины, тему или саму CMS — и страница оформления начала отдавать ошибку или потеряла форму. Главная при этом живее всех живых: проверка доступности смотрит на неё, получает 200 OK и ставит зелёную галочку. До страницы «/checkout/» обычный мониторинг просто не доходит.

### 3. Выросла доля несостоявшихся заказов

Заказы создаются, но всё большая их часть обрывается на оплате: у шлюза проблемы, банк отклоняет, сертификат платёжного модуля протух. По одному такому заказу ничего не скажешь — они бывают всегда. Сигнал — в динамике: если несостоявшихся заказов за сутки стало в разы больше нормы, что-то сломалось в оплате.

### 4. Сломался серверный конвейер заказа

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

### 5. Заказы просто перестали приходить

Самый коварный случай: технически всё вроде цело, но поток заказов оборвался. Причина может быть любой из четырёх выше — или вообще внешней (сломалась реклама, домен попал под фильтр). Если магазин стабильно делал заказы каждый день, а сегодня — ноль, это повод для тревоги сам по себе, независимо от того, что показывают проверки.

## Почему «зелёный» мониторинг всего этого не видит

Обычная проверка доступности отвечает на один вопрос: «открылась ли страница». Все пять поломок выше устроены так, что страница открывается. Код ответа 200, сертификат валиден, скорость нормальная — а деньги не проходят. Проверять магазин нужно как бизнес-процесс: не «жива ли витрина», а «принимает ли магазин заказы и проходят ли оплаты».

Часть этого процесса видна снаружи: доступность, SSL и домен, [формы и доставка заявок до почты](https://pingvera.ru/blog/ne-prihodyat-zayavki-s-sayta.html). Но платёжный шлюз в тест-режиме, рост несостоявшихся оплат и сломанный конвейер заказа снаружи не видны в принципе — это видно только изнутри CMS.

## Что именно проверяет Pingvera изнутри

Модуль Pingvera ставится в саму CMS штатным способом — как обычный плагин WordPress или модуль 1С-Битрикс — и работает строго в одну сторону: сам проверяет и отправляет результаты в мониторинг. Никакого удалённого управления магазином.

- **Поток заказов.** Каждый час модуль сверяет заказы за сутки с нормой магазина за две недели. Ноль заказов при стабильном потоке — предупреждение в отчёте. Пороги консервативные: магазин с парой заказов в день ложных тревог не получит.
- **Несостоявшиеся заказы.** Доля сорвавшихся оплат за сутки сравнивается с нормой самого магазина. Резкий всплеск — критичное событие: почти всегда это лежащий платёжный шлюз.
- **Платёжный шлюз в тест-режиме.** Если боевой шлюз (Stripe, PayPal, ЮKassa) включён, но работает в песочнице — критичное событие в течение часа. Ключи и секреты при этом не покидают сайт: наружу уходит только вердикт.
- **Страница оформления.** Модуль сам открывает страницу чекаута и убеждается, что она отвечает без ошибок и форма на месте — с обходом кэша, чтобы не смотреть на красивую закэшированную копию.
- **Тестовый прогон конвейера (WooCommerce).** Раз в сутки модуль создаёт служебный заказ со скрытым виртуальным товаром, проводит его по статусам и удаляет. Без писем, без следов в отчётности, без изменения остатков и без реальных платежей. Если любой шаг падает — критичное событие с указанием, где именно сломалось.

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

## Куда это попадает

Критичные события — сломанное оформление, тест-режим шлюза, всплеск несостоявшихся оплат — становятся обычными событиями мониторинга: алерт в Telegram, email или Max в момент обнаружения. Предупреждения — «засуха» заказов, не настроенные платёжные системы — попадают в панель здоровья сайта и в [клиентский отчёт студии](https://pingvera.ru/blog/kak-sledit-za-saytami-klientov.html): в раздел «Требует внимания» с человеческой формулировкой, что случилось и что сделать.

Для студии это готовый ответ на вопрос «а за что мы платим поддержку?»: не «мы следили за аптаймом», а «мы заметили, что у вас сломалась оплата, за 40 минут — вот событие, вот когда починили».

## Честно о границах

Контроль изнутри видит серверную часть магазина и статистику заказов — и не видит того, что происходит только в браузере покупателя: упавший скрипт корзины, конфликт JS-плагинов на витрине, проблему у CDN. Этот слой закрывается браузерным сценарием «пройти путь покупателя» — он в наших планах как отдельный уровень проверок. А падение самого сайта или хостинга ловит внешний слой Pingvera, который работает независимо от модуля в CMS. Снаружи и изнутри — два слоя, которые прикрывают слепые зоны друг друга.

## Частые вопросы

**Почему в интернет-магазине перестали приходить заказы, хотя сайт работает?**

Чаще всего ломается не витрина, а невидимая часть приёма заказа: платёжный шлюз остался в тестовом режиме после работ, обновление плагина сломало оформление заказа, выросла доля несостоявшихся оплат, письма о заказах перестали уходить. Сайт при этом открывается и выглядит здоровым, поэтому обычная проверка доступности ничего не замечает — она смотрит, открылась ли страница, а не проходят ли деньги.

**Как автоматически проверять, что магазин принимает заказы?**

Снаружи — следить за доступностью, формами и страницей оформления. Изнутри — через модуль в самой CMS: Pingvera ежечасно сверяет поток заказов с нормой магазина, ловит всплеск несостоявшихся заказов, замечает платёжный шлюз в тестовом режиме, проверяет страницу оформления и раз в сутки прогоняет тестовый заказ через серверный конвейер WooCommerce — без писем, без следов в отчётности и без реальных платежей.

**Работает ли контроль заказов для 1С-Битрикс?**

Да. Модуль Pingvera для 1С-Битрикс в режиме «только чтение» следит за потоком заказов и долей неоплаченных, проверяет страницу оформления и наличие активных платёжных систем. Пороги привязаны к норме конкретного магазина, поэтому магазин с оплатой при получении не получает ложных тревог.