При перезапуске старого сайта онлайн-оплата перестала работать из-за расхождения настроек чеков — разбираем, как мы нашли конфликт между ЮKassa и АТОЛ, почему тестовое окружение не показало ошибку и как восстановили приём платежей без потери заказов.
- Контекст задачи: восстановление магазина на старой платформе
- Как проявлялась ошибка: тестовый платёж и первые симптомы
- Диагностика: два источника печати чеков и поиск конфликта
- Как отключение фискализации в ЮKassa привело к временным простоям
- Практические выводы для бизнеса и разработки
- Часто задаваемые вопросы
Контекст задачи: восстановление магазина на старой платформе
К нам обратился клиент, владелец интернет-магазина на старой платформе. Сайт работал несколько лет на связке ЮKassa и внешней кассы АТОЛ для фискализации. Затем магазин был выведен из эксплуатации, а спустя время клиент решил его перезапустить — с тем же функционалом, но на обновлённой инфраструктуре.
Казалось, что задача тривиальная: восстановить код, обновить окружение, развернуть базу. Однако при первой же тестовой оплате картой платёж не прошёл. Вместо подтверждения заказа клиент увидел ошибку выбранного способа оплаты. В логах платёжного шлюза значилось: «Receipt is missing or illegal».
Ситуация стандартная для проектов, где долгое время не обновлялись настройки платёжных интеграций. Проблема была не в коде, а в расхождении настроек фискализации на стороне ЮKassa и внешней кассы. Такие конфликты возникают, когда при восстановлении «как было» не учитывают, что за время простоя могли измениться политики сервиса или просто забыли, какая именно сторона отвечала за печать чеков.
Ключевой бизнес-риск — каждый час простоя онлайн-оплаты означает прямые потери выручки. Поэтому нам нужно было не просто найти ошибку, а устранить её без длительной остановки магазина.
Как проявлялась ошибка: тестовый платёж и первые симптомы
Первая же тестовая оплата картой на восстановленном магазине завершилась неудачей. Клиент увидел сообщение: «Ошибка выбранного способа оплаты» — стандартную ошибку, которая могла означать что угодно: от проблем с картой до неработающего платёжного шлюза.
В логах платёжного шлюза обнаружилась более конкретная запись: «Receipt is missing or illegal». ЮKassa отклонила платёж из-за проблем с чеком. Логи зафиксировали факт отказа, метку времени, ID платежа и текст ошибки, но не показали источник конфликта — а именно, что одновременно активны два провайдера фискализации, и не раскрыли разницу между настройками тестового и боевого окружения.
Если бы мы ограничились анализом логов, то начали бы проверять код интеграции, который на самом деле работал корректно. Истинная причина выяснилась после просмотра статуса чека в личном кабинете ЮKassa: там была включена опция «Фискализация средствами ЮKassa», в то время как сайт не отправлял чек вовсе. Вывод: логи API — лишь первый слой диагностики; всегда параллельно проверяйте настройки фискализации в личном кабинете платёжного сервиса.
Диагностика: два источника печати чеков и поиск конфликта
Когда логи показали только факт отказа, мы начали последовательно исключать возможные причины. Первым делом проверили код интеграции — он не менялся, все запросы к API ЮKassa формировались корректно. Затем переключились на личный кабинет ЮKassa. Там обнаружилась деталь, которая всё объяснила: в разделе настроек фискализации была включена печать чеков силами ЮKassa, хотя на стороне сайта фискализация не настраивалась и не передавалась.
Провели ревизию архитектуры:
- ЮKassa — требовала отправки чека (в ЛК была активна опция «печать чеков»);
- АТОЛ — по проектной документации именно он должен был формировать чеки и отправлять в ОФД;
- Сайт — не отправлял данные для чека ни в ЮKassa, ни в АТОЛ, так как старая интеграция подразумевала, что фискализация идёт только через внешнюю кассу.
Конфликт оказался классическим для проектов, где за время простоя накопились расхождения между боевыми настройками ЛК и кодом. Ситуация усугублялась тем, что тестовое окружение использовало другой, «чистый» личный кабинет ЮKassa, где фискализация была отключена — поэтому на тестах ошибка не проявлялась.
Почему тестовое окружение пропустило ошибку
В тестовом режиме мы использовали тестовые карты ЮKassa, которые эмулируют успешные сценарии оплаты, но не проверяют сквозную фискализацию. В боевом же ЛК опция печати чеков была включена — и при реальном платеже система требовала чек, который сайт не отправлял. Именно поэтому ошибка возникла только при боевой оплате, а тестовые прогоны прошли без проблем.
Это ключевой урок: никакое тестовое окружение не гарантирует корректной работы фискализации, если настройки в боевом ЛК отличаются. Единственный надёжный способ — проверять статус чека в личном кабинете ЮKassa и в ОФД после каждого реального платежа.
Как отключение фискализации в ЮKassa привело к временным простоям
После того как мы нашли причину — конфликт двух источников печати чеков — логичным решением было отключить фискализацию в личном кабинете ЮKassa. Однако здесь нас ждал неприятный сюрприз: изменение настроек в ЛК ЮKassa не вступает в силу мгновенно. Опция отключается с задержкой до нескольких дней.
Для бизнеса это означало, что приём платежей оставался заблокированным на весь переходный период. Каждый час простоя — прямая потеря выручки. Мы не могли просто ждать и надеяться, что клиенты не заметят проблему.
Чтобы минимизировать ущерб, мы подготовили и согласовали с владельцем магазина план действий:
- Предупредить клиентов — на сайте разместили уведомление о возможных временных сбоях при оплате картой.
- Предложить альтернативы — активировали дополнительные способы оплаты: наличные при получении и перевод на расчётный счёт.
- Установить ежедневный мониторинг — каждое утро проверяли статус отключения опции в ЛК ЮKassa и тестировали оплату реальной картой.
- Уведомить владельца — о каждом изменении статуса и ожидаемых сроках полного восстановления.
Этот опыт показал: любые изменения настроек фискализации в платёжном сервисе требуют закладывать временной буфер в план проекта и заранее готовить сценарий коммуникации с клиентами бизнеса.
Практические выводы для бизнеса и разработки
Описанный инцидент — не единичный случай. Чтобы избежать повторения, достаточно закрепить в рабочих процессах несколько правил:
- Явно назначьте ответственного за фискализацию. В архитектурном решении должно быть чётко указано, какая сторона (ЮKassa или внешняя касса) формирует чеки. Совместная работа двух источников недопустима.
- Проверяйте не только тестовое, но и боевое окружение. Тестовые карты не эмулируют сквозную фискализацию. Перед запуском выполните хотя бы один реальный платёж и убедитесь, что чек появился в ОФД.
- Закладывайте временной буфер на изменение настроек ЛК. Отключение или включение фискализации в ЮKassa может занимать до нескольких дней. Планируйте этот период и заранее готовьте запасные способы оплаты.
- Настройте мониторинг статуса чеков. Для каждого платежа проверяйте, что чек сформирован и отправлен в ОФД. Это позволит быстро заметить расхождение и не допустить массовых сбоев.
Если вы восстанавливаете старый сайт или меняете платёжный модуль — проведите предварительный аудит настроек фискализации. Это сэкономит часы диагностики и убережёт от потери выручки.
Часто задаваемые вопросы
Если вы восстанавливаете старый магазин или планируете смену платёжной интеграции, свяжитесь с нами — поможем с аудитом настроек и тестированием фискализации.
