Если оплата прошла, а заказ не меняет статус, сервис не смог сообщить сайту о платеже или сайт неверно обработал уведомление. Проверьте статус платежа, событие, адрес без редиректа и ответ сервера: ЮKassa ждёт код 200, Т-Банк код 200 и текст OK.
Оплата прошла, а заказ не оплачен: значит, банк считает платёж успешным, а сайт об этом не узнал или не смог записать. Деньги покупателя в порядке, оборвалась связка между сервисом и заказом. Обычно дело в вебхуке: уведомление не дошло, сервер ответил не тем кодом или обработчик упал уже после получения.
Ниже порядок проверки для ЮKassa и Т-Банка и случаи с моих проектов. Идите сверху вниз, так быстрее всего находится место обрыва.
Где обрывается связка между оплатой и заказом
После оплаты должны сработать пять звеньев:
- Сервис переводит платёж в успешный статус.
- Сервис отправляет POST-запрос на адрес уведомлений.
- Запрос доходит до вашего сайта без редиректов и блокировок.
- Сайт отвечает так, как ждёт сервис.
- Обработчик находит заказ и меняет статус.
Быстрый способ разделить проблему: попросите разработчика записывать в файл всё, что приходит на адрес, до любой логики. Записей нет: обрыв в звеньях 1–3. Записи есть: обрыв в звеньях 4–5.
Как проверить, что платёж действительно прошёл
Сначала откройте платёж в кабинете. Статусы значат разное:
| Сервис | Статус | Что значит |
|---|---|---|
| ЮKassa | succeeded |
оплата завершена, статус финальный |
| ЮKassa | waiting_for_capture |
деньги заморожены, ждут вашего решения, от 2 часов до 7 дней |
| ЮKassa | canceled |
платёж отменён, причина указана в платеже |
| Т-Банк | CONFIRMED |
деньги списаны |
| Т-Банк | AUTHORIZED |
деньги заморожены, ждут подтверждения |
Если сайт ждёт succeeded, а платёж стоит в waiting_for_capture, уведомления тут ни при чём: включена двухстадийная оплата, и платёж надо подтвердить.
Статус можно запросить и напрямую. Подставьте данные своего магазина, команду запускайте у себя в терминале и никому не присылайте ключ:
curl -u НОМЕР_МАГАЗИНА:СЕКРЕТНЫЙ_КЛЮЧ https://api.yookassa.ru/v3/payments/НОМЕР_ПЛАТЕЖАБывает и обратная картина. На курсе по монтажу заказчик написал, что покупатель считает заказ оплаченным, а доступа нет. Логи показали: все попытки отменены, причины general_decline и expired_on_confirmation, деньги не списаны. Судя по всему, покупателя убедила страница «Спасибо»: она открывалась после возврата с ЮKassa при любом исходе. Я сделал отдельную страницу ошибки. Вывод простой: доказательство оплаты это статус платежа, а страница возврата ничего не доказывает.
Почему вебхук ЮKassa не приходит
Не включено событие
В разделе HTTP-уведомлений должно быть отмечено payment.succeeded. После смены магазина настройку часто забывают перенести.
Указан адрес другого магазина
На курсе по монтажу в октябре заменили оба магазина. Оплата пришла, а бот промолчал. Я сверил платёж через API: он прошёл в новом магазине для Беларуси, а уведомление уходило на адрес российского. Бот берёт магазин из адреса, спрашивает у него про платёж, тот отвечает, что такого нет, и бот не верит уведомлению. ЮKassa повторила отправку три раза за пять минут. Лечится правкой адреса в кабинете нового магазина.
Если магазинов несколько, сверяйте пары: адрес, номер магазина, ключ.
Перепутаны тестовый и боевой магазин
У тестового магазина свои ключи и свои настройки. Проверка в тесте не доказывает, что заработает бой. Я встречал и случай наоборот: тест работал идеально, а бой нет из-за настроек магазина на стороне сервиса.
Редирект съедает запрос
Самая коварная причина: адрес живой, а тела запроса нет. На ViVaDa я ловил это в интеграции с Яндекс Едой, оплата там ни при чём, механика та же. Запрос уходил POST на адрес без www, хостинг перенаправлял его на адрес с www, и по дороге он превращался в GET без тела. В дампе окружения было видно:
REQUEST_METHOD: GET
HTTP_HOST: www.vivada.ruКод проверял метод, ни одна ветка не срабатывала, и Яндекс получал 401. Искал я это два дня: дамп, копия сайта на другом хостинге, логи по заявке. Решение: все запросы шли на адрес с www. Проверяйте адрес после смены домена, перехода на HTTPS и правок в .htaccess.
Адрес не подходит под требования
ЮKassa принимает только HTTPS на портах 443 или 8443 с TLS 1.2 и выше. Подойдёт любой сертификат, даже самоподписанный. Адрес на HTTP или нестандартном порту не сработает.
Запрос режет защита
Защита от ботов, капча, пароль на папку, кеш. Адрес уведомлений надо исключить из них. Если нужен белый список, адреса отправителей есть в документации ЮKassa.
Как проверить адрес уведомлений
Отправьте запрос так, как его отправит сервис:
curl -i -X POST https://ваш-сайт.ru/адрес-уведомлений -H "Content-Type: application/json" -d "{}"Смотрите первую строку ответа:
| Код | Что значит | Что делать |
|---|---|---|
| 200 | адрес доступен | искать дальше, в обработчике |
| 301, 302 | редирект | указать конечный адрес |
| 401, 403 | защита или пароль | исключить адрес из защиты |
| 404 | адрес не существует | сверить адрес в кабинете и на сайте |
| 500 | обработчик упал | смотреть лог PHP на это время |
| 502, 504 | сервер не дождался кода | смотреть таймауты сервера |
На пустой запрос обработчик может ответить ошибкой, это нормально. Главное, чтобы не было редиректа и блокировки.
Что должен ответить сервер: ЮKassa и Т-Банк
| ЮKassa | Т-Банк | |
|---|---|---|
| Успешный ответ | код 200, тело не важно | код 200 и тело OK, заглавными латинскими, без тегов |
| Если ответ другой | повторы 24 часа с момента события | раз в час сутки, затем раз в сутки месяц |
| Где настроить | HTTP-уведомления в кабинете | «Нотификация по http(s)» в настройках терминала |
| Как проверить подлинность | запросить статус через API, сверить IP | проверить Token: SHA-256 от параметров и пароля терминала |
Отвечать надо быстро. Сколько ЮKassa ждёт ответа, на странице уведомлений не сказано, поэтому сначала запишите событие и ответьте, а тяжёлую работу делайте после.
В Т-Банке легко ошибиться: ok маленькими буквами или JSON для банка неуспех, и он шлёт уведомление снова. Правило взято из документации Т-Банка. Недоставленные уведомления банк хранит в архиве 90 дней, их можно запросить повторно.
Уведомление пришло, а заказ не обновился
Заказ не находится. В уведомлении приходит номер платежа, а обработчик ищет заказ по другому полю. Передавайте номер заказа при создании платежа: в ЮKassa в metadata, в Т-Банке в OrderId.
Обработчик реагирует не на то событие. На курсе по монтажу уведомление владельцу сначала уходило при создании платежа, когда покупатель только нажал «Оплатить», и в бот попадали неудавшиеся оплаты. Ошибка была моя. Теперь оно идёт только после payment.succeeded. В Т-Банке отличайте AUTHORIZED от CONFIRMED.
Обработчик не готов к повторам. Одно уведомление может прийти несколько раз, это нормально. Если заказ уже оплачен, ответьте успехом и ничего больше не делайте. Иначе покупатель получит два письма, а склад два списания.
Обработчик верит телу запроса. Перед выдачей товара запросите статус платежа через API. В случае с двумя магазинами именно эта перепроверка не дала боту поверить чужому уведомлению.
Внутри вебхука лежит лишняя работа. На IZILAB PDF с направлением и гарантийным письмом создавались в обработчике вебхука. На сервере файлы не появлялись, а проверить можно было только реальным платежом. Лог показал причину:
YooKassa webhook received {"event":"payment.succeeded"}
PDF generation failed ... PHP GD extension is required,
but is not installed.Библиотеке для PNG-логотипа нужно было расширение PHP GD, а на сервере его не было. Лог нашёл руководитель агентства, расширение поставил я. Вывод: отметку об оплате ставьте сразу, а письма и файлы выносите в очередь, чтобы их сбой не трогал оплату и чтобы их можно было запустить заново без платежа.
Заказ не меняет статус в WooCommerce и на Tilda
WooCommerce с модулем ЮKassa. Ссылка для уведомлений лежит на вкладке «Уведомления» в настройках модуля. После переезда или смены домена скопируйте её заново и вставьте в кабинет. При отложенной оплате оплаченный заказ стоит в статусе «На удержании», пока вы его не подтвердите: переведите в «Обработка» и нажмите «Обновить». Это штатное поведение, а не сбой.
Tilda. Адрес уведомлений принадлежит самой Tilda. Для Т-Банка это https://forms.tildacdn.com/payment/tinkoff/, он указывается в настройках терминала вместе с включённой нотификацией. Если заказы не появляются, начните с этого адреса.
Что делать, если адрес уведомлений нельзя изменить
На SaveAPP бот работает на конструкторе Salebot, а уведомление Т-Банка уходит на адрес Salebot. Сначала я написал свой вебхук. В тот же день автоматизатор ответил, что они уже пробовали: подмена адреса не срабатывает, уведомление всё равно приходит туда же, формат номера заказа тоже не поменять. Похоже, адрес зашит при настройке магазина, это наблюдение, а не документированный факт.
Я снял зависимость от уведомлений совсем. Кнопка в боте ведёт на мою ссылку, отдельный сервис создаёт платёж и раз в 30 секунд спрашивает у банка статус. Подтверждение уходит в Salebot. Цена решения: задержка до 30 секунд. Менять терминал и лезть в настройки Salebot не пришлось.
Как застраховаться от потерянных уведомлений
Уведомление может потеряться: сервер перезагружался, сертификат истёк, хостинг лёг. Поэтому полезна фоновая задача, которая раз в несколько минут спрашивает у сервиса статус незавершённых заказов. В ЮKassa это запрос платежа через API, в Т-Банке метод GetState. Такой опрос страхует от потерь, даже если вебхук обычно работает.
Второе правило: внешняя проверка. Если заказ оплачен, а письмо или доступ не ушли за несколько минут, сообщение должно прийти вам, а не покупателю.
Что делать с покупателями, пока чините
- Выгрузите из кабинета успешные платежи за период сбоя.
- Сверьте их с заказами на сайте и отметьте расхождения.
- Выдайте товар или доступ вручную и напишите покупателям.
- После исправления проверьте, что повторные уведомления не создают дублей.
В ЮKassa есть запас: если починить адрес в течение 24 часов, недоставленные уведомления могут дойти сами.
Когда звать специалиста
Сами вы проверите статус, событие, адрес и ответ сервера. На готовом модуле этого часто хватает.
Звать разработчика стоит, если покупатели уже платят и не получают заказ, если интеграция своя или если уведомления приходят, а заказ не меняется. Разбор настроенной связки стоит 3 000 ₽ и идёт в зачёт работы, подключение оплаты с проверкой на реальном платеже от 7 000 ₽. Что входит, написано на странице услуги. Для первого взгляда пришлите симптом на бесплатный разбор, только без ключей и паролей.
Частые вопросы
Почему вебхук ЮKassa не приходит?
Чаще всего не включено событие payment.succeeded, указан адрес другого магазина или запрос теряется на редиректе. Ещё адрес может резать защита от ботов. ЮKassa принимает только HTTPS на портах 443 и 8443 с TLS 1.2 и выше.
Что должен ответить сервер на уведомление Т-Банка?
Код 200 и текст OK: заглавные латинские буквы, без тегов. Другой ответ банк считает неуспешным и повторяет уведомление раз в час в течение суток, затем раз в сутки в течение месяца.
Сколько раз ЮKassa повторяет уведомление?
ЮKassa повторяет его в течение 24 часов с момента события, пока сервер не ответит кодом 200. Число попыток и интервал в документации не указаны. Если починить адрес в этот срок, заказы могут обновиться сами.
Покупатель видел страницу «Спасибо», значит, оплата прошла?
Нет. Страница возврата открывается после редиректа и сама ничего не доказывает. Смотрите статус платежа в кабинете или через API.
Никита Митусов, веб-разработчик. Более 5 лет делаю сайты, магазины, интеграции и ботов. Статья основана на моих проектах и проверена по документации сервисов.