Не проходит оплата на сайте интернет-магазина: как найти причину и что проверить

13 октября 2026 · 10 мин чтения

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

Ниже порядок проверки, который владелец магазина или подрядчик может пройти сегодня. Он не зависит от платформы: шаги одинаковы для WooCommerce, 1С-Битрикс, InSales, Tilda и самописного сайта, отличаются только названия статусов и меню.

Коротко

• Начните с кабинета платёжного провайдера: там видно, доходят ли платежи до банка и с какой причиной их отклоняют.
• Если в кабинете платежи успешные, а в заказах «Ожидает оплаты», сломалась доставка уведомлений (вебхуков) на сайт.
• Если в кабинете платежей нет вовсе, проблема на сайте: кнопка, редирект на платёжную страницу, ключи или настройки модуля.
• Массовые отказы с причиной вроде «3-D Secure не пройден» или «банк недоступен» чаще связаны с банками покупателей, а не с магазином. Дайте покупателю другой способ оплаты.
• Перед 11.11 и «Чёрной пятницей» (27 ноября 2026 года) проверьте всю цепочку оплаты тестовым заказом после каждого обновления сайта.

Почему проверить оплату стоит сейчас

На октябрь 2026 года до сезонных пиков осталось несколько недель: 11 ноября и 27 ноября («Чёрная пятница»). В эти дни поломка оплаты стоит дороже всего, а подрядчики чаще всего обновляют модули и темы именно в октябре, чтобы успеть к акциям. Любое обновление платёжного модуля, PHP, SSL-сертификата или правил файрвола способно тихо сломать приём уведомлений от провайдера.

Второй повод: с 1 сентября 2026 года по Федеральному закону № 248-ФЗ продавцы с выручкой за год больше 120 млн рублей обязаны дать покупателям возможность платить цифровыми рублями. Для продавцов с выручкой от 30 до 120 млн рублей обязанность начнёт действовать с 1 сентября 2027 года, от 5 до 30 млн рублей — с 1 сентября 2028 года (buh.ru). Новый способ оплаты добавляет в цепочку ещё одну интеграцию, и её тоже нужно проверять наравне с картами и СБП. Подробности обязанности уточните у банка и юриста: здесь только практическая сторона.

Пошаговая проверка: от кабинета провайдера к сайту

Шаг 1. Откройте кабинет платёжного провайдера

Посмотрите платежи за последние 2–3 часа и сравните с обычным днём. Возможны три картины:

1. Платежей нет совсем. Покупатель не доходит до платёжной страницы. Переходите к шагу 2.
2. Платежи есть, но почти все отменены. Смотрите причину отмены (шаг 3).
3. Платежи успешные, а заказы на сайте не оплачены. Сломалась обратная связь провайдера с сайтом (шаг 4).

Шаг 2. Платёжная страница не открывается

Сделайте тестовый заказ сами, с компьютера и с телефона, и дойдите до формы ввода карты. Типичные причины:

• после обновления модуля слетели ключи магазина или включился тестовый режим;
• истёк или неверно выпущен SSL-сертификат сайта, и браузер блокирует переход;
• JavaScript-ошибка на странице оформления заказа: кнопка «Оплатить» нажимается, но ничего не происходит (откройте консоль браузера, клавиша F12);
• способ оплаты скрыт условиями: суммой заказа, регионом доставки, группой покупателей;
• кеширующий плагин или CDN закешировал страницу оформления заказа с чужой сессией.

Шаг 3. Платежи доходят до банка, но отклоняются

У провайдера у каждого отменённого платежа есть причина. В документации ЮKassa, например, указаны инициатор отмены (сам магазин, ЮKassa или участник платёжной цепочки, то есть банк-эмитент) и причина: 3d_secure_failed (не пройдена аутентификация 3-D Secure), insufficient_funds (не хватает денег), card_expired (истёк срок карты), fraud_suspected (подозрение в мошенничестве), expired_on_confirmation (покупатель не завершил оплату вовремя), issuer_unavailable (банк недоступен), general_decline (причина не детализирована) (ЮKassa).

Как читать эти причины:

• Единичные insufficient_funds и card_expired в норме, их видно каждый день.
• Резкий рост 3d_secure_failed или issuer_unavailable часто означает проблему у конкретного банка покупателей. Проверьте, совпадают ли отказы по банку-эмитенту, и напишите в поддержку провайдера.
• Много expired_on_confirmation: покупатели уходят со страницы подтверждения. Проверьте, открывается ли страница 3-D Secure на мобильных и не мешает ли ей встроенный браузер мессенджера.
• Если инициатор отмены «магазин», платёж отменяет ваша система: чаще всего автоотмена неоплаченных заказов (шаг 5).

Шаг 4. Деньги списались, а заказ «ожидает оплаты»

Провайдер сообщает сайту об оплате HTTP-уведомлением (вебхуком) на адрес, который указан в его кабинете. У ЮKassa требования такие: адрес только HTTPS на порту 443 или 8443, TLS 1.2 или выше, сайт должен ответить кодом HTTP 200, иначе ЮKassa повторяет доставку в течение 24 часов с момента события (ЮKassa). У других провайдеров требования к ответу свои, сверьтесь с их документацией.

Что ломает приём уведомлений:

• сменился домен, протокол или путь к обработчику, а в кабинете провайдера остался старый адрес;
• файрвол, защита от ботов или плагин безопасности блокирует запросы с IP-адресов провайдера (ЮKassa публикует свои диапазоны в той же документации);
• обработчик отвечает ошибкой 500 после обновления PHP или модуля;
• сайт в режиме обслуживания или закрыт паролем на время работ;
• сертификат на сервере не поддерживает нужную версию TLS.

Проверьте журнал уведомлений в кабинете провайдера (если он есть) и журнал ошибок сервера за то же время. Пока уведомления повторяются, у вас есть окно, чтобы починить обработчик и получить их заново. После этого сверьте оплаты и заказы вручную, порядок разобран в статье «Сверка оплат и заказов».

Шаг 5. Заказ отменился сам

В WooCommerce настройка «Удерживать товар (минут)» отменяет заказы со статусом «Ожидает оплаты», когда лимит истекает, и возвращает товар на склад (WooCommerce). Если уведомление от провайдера опоздало или не дошло, оплаченный заказ может отмениться. В документации WooCommerce отдельно сказано, что при отложенном подтверждении оплаты статус «Не удался» появляется не сразу: сначала заказ бывает «На удержании» (WooCommerce). В других платформах похожие механизмы называются иначе, но логика та же: проверьте, через сколько минут система отменяет неоплаченные заказы и не короче ли это время, чем 3-D Secure и повторы уведомлений.

Шаг 6. Сообщите покупателям и временно включите запасной способ

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

Таблица: где ломается оплата и кто проверяет

Риск	Ответственный	Как проверить	Частота
Кнопка оплаты не ведёт на платёжную страницу	Разработчик или студия	Тестовый заказ с ПК и телефона	После каждого обновления сайта и модулей
Ключи или режим модуля сбились	Разработчик	Сверить настройки модуля с кабинетом провайдера	После обновления платёжного модуля
Вебхуки не доходят до сайта	Разработчик, хостинг	Журнал уведомлений провайдера, логи сервера	Ежедневно в сезон, еженедельно в обычное время
Рост отказов банков	Менеджер магазина	Причины отмен в кабинете провайдера	Ежедневно
Автоотмена оплаченных заказов	Менеджер магазина	Отменённые заказы со списанием у провайдера	Ежедневно
Истёк SSL-сертификат	Студия или хостинг	Срок сертификата, проверка в браузере	Автоматически, напоминание за 2–3 недели
Поток заказов упал без видимых ошибок	Владелец, менеджер	Сравнение заказов с тем же часом прошлой недели	Каждый час в пики

Готовый артефакт: чек-лист проверки оплаты перед распродажей

Скопируйте и пройдите перед 11.11 и после каждого обновления сайта:

ПРОВЕРКА ОПЛАТЫ — дата: ____  кто проверял: ____

[ ] Тестовый заказ с ПК: дошёл до формы оплаты
[ ] Тестовый заказ с телефона (мобильный браузер): дошёл до формы оплаты
[ ] Тестовый заказ из встроенного браузера мессенджера: дошёл до 3-D Secure
[ ] Реальная оплата на небольшую сумму прошла, статус заказа сменился на «оплачен»
[ ] Покупатель получил письмо о заказе и чек
[ ] Оплата через СБП: QR открылся, статус обновился
[ ] Цифровой рубль (если обязаны принимать): тестовая оплата прошла
[ ] Возврат тестовой оплаты прошёл, статус в магазине обновился
[ ] Адрес уведомлений в кабинете провайдера совпадает с текущим доменом и путём
[ ] Файрвол / защита от ботов не блокирует IP-адреса провайдера
[ ] Время автоотмены неоплаченных заказов: ___ минут (не короче окна оплаты)
[ ] SSL-сертификат действует до: ____
[ ] Запасной способ оплаты включён и проверен
[ ] Контакты поддержки провайдера и ответственного разработчика под рукой

Шаблон письма покупателю, если оплата не проходила:

Здравствуйте!

Сегодня с __:__ до __:__ у нас на сайте не проходила оплата картой.
Ваш заказ № ____ сохранён, товар зарезервирован до ____.

Оплатить можно по ссылке: ____
Если деньги уже списались, ответьте на это письмо: мы проверим платёж
и подтвердим заказ без повторной оплаты.

Извините за неудобство.

Пример разбора (условная ситуация)

Пример составлен для иллюстрации, это не случай конкретного клиента.

Магазин на WooCommerce в октябре обновил плагин безопасности перед акцией. На следующий день менеджер заметил, что с утра в заказах только «Ожидает оплаты» и «Отменён», а в кабинете провайдера платежи успешные. Причина нашлась в журнале плагина: новое правило блокировало POST-запросы к адресу обработчика уведомлений. Разработчик добавил IP-диапазоны провайдера в исключения, провайдер повторил недоставленные уведомления, а заказы, которые успели отмениться автоматически, менеджер восстановил вручную по выгрузке платежей. Покупателям, которые оплатили, но получили письмо об отмене, отправили отдельное письмо с подтверждением.

Что можно было сделать заранее: пройти тестовую оплату сразу после обновления и настроить оповещение, когда за час нет ни одного оплаченного заказа.

Частые ошибки

• Проверять только «открывается ли сайт». Главная страница отвечает, а оплата сломана. Мониторинг доступности этого не видит, нужна проверка потока заказов. Подробнее в статье «Магазин работает, а заказов нет».
• Тестировать в тестовом режиме провайдера и считать проверку законченной. Тестовый режим не проверяет боевые ключи и 3-D Secure реальных банков. Нужна хотя бы одна реальная оплата на небольшую сумму с возвратом.
• Сразу менять провайдера. Если отказы идут от банков покупателей, смена провайдера не поможет, а интеграцию придётся проверять заново.
• Обновлять модули в день акции. Ставьте обновления за несколько дней до пика, чтобы успеть заметить поломку.
• Не смотреть отменённые заказы. Автоотмена прячет оплаченные заказы в статусе «Отменён», и их никто не отгружает.

Честные ограничения. Эта статья не заменяет документацию вашего провайдера и платформы: формат уведомлений, сроки повторов и названия статусов у всех разные. Отказы на стороне банков покупателей магазин исправить не может, может только дать другой способ оплаты и понятное сообщение. Вопросы 54-ФЗ и цифрового рубля решайте с банком, бухгалтером и юристом.

Если поломка случилась не с оплатой, а заказы просто упали, используйте общий алгоритм из статьи «Почему падают заказы».

Вопросы и ответы

Как понять, проблема у магазина или у банка покупателя?

Посмотрите кабинет провайдера. Если платёж туда не дошёл, проблема на сайте. Если дошёл и отклонён с причиной от банка-эмитента, проблема у банка или карты покупателя. Если отказы массовые и по разным банкам, напишите в поддержку провайдера.

Деньги у покупателя списались, а заказа нет. Что делать?

Найдите платёж в кабинете провайдера по сумме, времени или номеру заказа. Если заказ есть, но не оплачен или отменён, переведите его в оплаченный вручную и проверьте, почему не дошло уведомление. Если заказа нет вовсе, свяжитесь с покупателем и оформите заказ вручную или верните деньги.

Как часто проверять оплату тестовым заказом?

После каждого обновления сайта, платёжного модуля, PHP, сертификата и правил защиты. В сезон распродаж стоит добавить ежедневную проверку и оповещение, если за обычный по объёму час не пришло ни одного оплаченного заказа.

Как автоматизировать часть проверок

Шаги про SSL-сертификат и поток заказов можно не делать руками. Pingvera следит за сроком SSL-сертификатов и доступностью сайта, а для WooCommerce получает события заказов order.created и order.failed через WordPress-коннектор. Детектор аномалий на тарифе Business сравнивает поток заказов с почасовой нормой и присылает оповещение «сайт работает, а заказов нет» в Telegram, MAX, VK или на почту. До 5 сайтов можно подключить бесплатно. Тестовую оплату и проверку вебхуков у провайдера всё равно стоит делать по чек-листу выше.

Источники

• ЮKassa. Отклонённые платежи, причины отмены: https://yookassa.ru/developers/payment-acceptance/after-the-payment/declined-payments
• ЮKassa. HTTP-уведомления (требования к адресу, повторы, IP-адреса): https://yookassa.ru/developers/using-api/webhooks
• WooCommerce. Настройки товаров, «Удерживать товар»: https://woocommerce.com/document/configuring-woocommerce-settings/products/
• WooCommerce. Статусы заказов: https://woocommerce.com/document/managing-orders/order-statuses/
• buh.ru. С 1 сентября 2026 года продавцы обязаны принимать к оплате цифровые рубли (Федеральный закон № 248-ФЗ): https://buh.ru/news/s-1-sentyabrya-prodavtsy-obyazany-prinimat-k-oplate-tsifrovye-rubli.html

Проверено: 13 октября 2026 года.

Читайте также: Как проверить восстановление сайта из бэкапа · «У нас сайт лежит»: как проверить доступность сайта правильно · Нужен ли headless commerce интернет-магазину · Сайт взломан: что делать магазину в первые 24 часа · Бесплатно проверить сайт.