Тестовый режим ЮKassa я включаю в каждом проекте с приёмом онлайн-оплаты, будь то интернет-магазин на Tilda, сайт на WooCommerce или собственный бэкенд с интеграцией по API. Ошибка в обработке статуса платежа или в проверке подписи вебхука, которая вылезет на реальных деньгах клиента, обходится дороже, чем пара часов на тестирование до запуска. Ниже разберу, как включить тестовый режим ЮKassa, какими картами и данными гонять тестовые платежи и что проверить перед переключением магазина на боевые расчёты.
Что такое тестовый режим ЮKassa и когда он нужен
Тестовый режим ЮKassa это отдельная пара учётных данных для того же магазина: свой shop_id и свой secret_key, с которыми API работает по тем же правилам, что и в боевом режиме, но деньги никуда не списываются. Запрос уходит на тот же адрес api.yookassa.ru/v3, статусы платежей приходят такие же (pending, waiting_for_capture, succeeded, canceled), только вместо реальной карты клиента используются тестовые номера из документации ЮKassa.
На практике я прогоняю через тестовый режим каждый сценарий: успешную оплату, отказ по недостатку средств, отмену пользователем на странице оплаты, двухстадийную оплату с холдированием и возврат. Если на сайте настроен только один сценарий из пяти и в проверке участвовала лишь одна успешная оплата, при первом реальном отказе клиента магазин чаще всего просто зависает в неопределённом статусе заказа.
Как включить тестовый режим в личном кабинете ЮKassa
После регистрации магазина в личном кабинете ЮKassa наверху страницы есть переключатель между рабочим и тестовым режимом. При активации тестового режима система выдаёт отдельные shop_id и secret_key, которые не пересекаются с боевыми: их нужно подставить в код, в настройки плагина CMS или в переменные окружения тестового стенда.
Важный момент, о который спотыкаются чаще всего: тестовые и боевые ключи хранятся в разных разделах кабинета одновременно, и после запуска магазина тестовый раздел никуда не пропадает. Я обычно держу оба набора ключей в .env файле проекта под разными именами (YOOKASSA_SHOP_ID_TEST и YOOKASSA_SHOP_ID_LIVE), чтобы при доработках можно было быстро переключиться обратно в тест, не трогая боевую конфигурацию.
| Параметр | Тестовый режим | Боевой режим |
|---|---|---|
| shop_id и secret_key | отдельная тестовая пара | отдельная боевая пара |
| Списание денег | не происходит | реальное списание |
| Чек по 54-ФЗ | не формируется | формируется и уходит в ОФД |
| Вебхуки | работают на тестовый notification_url | работают на боевой notification_url |
| Способы оплаты | эмулируются тестовыми картами | реальные карты, СБП, кошельки |
Тестовые карты и данные для проверки оплаты
ЮKassa публикует набор тестовых номеров карт, каждый из которых имитирует конкретный результат оплаты. Срок действия карты можно указывать любой в будущем, CVC любой трёхзначный код, а для подтверждения 3‑D Secure используется код 12345.
- 5555 5555 5555 4444 - успешная оплата
- 5555 5555 5555 4477 - отказ банка по недостатку средств
- отмена на форме оплаты - просто закрыть окно оплаты, не вводя данные
Я прогоняю по очереди все три сценария и смотрю, что происходит с заказом в CRM и на сайте: меняется ли статус заказа, приходит ли клиенту письмо или сообщение в Telegram-бот, не остаётся ли товар зарезервированным на складе после отказа. Если магазин работает по двухстадийной оплате (сначала холдирование suммы, потом списание capture), отдельно проверяю статус waiting_for_capture и то, что списание происходит только после подтверждения отгрузки.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Проверка интеграции на Tilda и WooCommerce
На Tilda оплата через ЮKassa подключается через встроенный блок Tilda Payments, куда достаточно вставить тестовые shop_id и secret_key, чтобы форма заказа начала уходить в тестовый режим. Стандартная форма закрывает 80% задач, но как только нужен нестандартный сценарий, например ограничить способ оплаты только картой без СБП или сделать кастомный редирект после успешной оплаты с передачей номера заказа в CRM, приходится дописывать логику отдельным скриптом в Zero Block. Для таких доработок я обычно оформляю разработку и настройку интеграции эквайринга под конкретный магазин, потому что типовые блоки конструктора такие сценарии не закрывают.
На WooCommerce всё завязано на официальном плагине ЮKassa: в его настройках есть отдельная галочка тестового режима и два поля под тестовые и боевые ключи. После включения теста делаю полный прогон чекаута с разными способами доставки и разными тестовыми картами, потому что часть плагинов некорректно обрабатывает статус waiting_for_capture и оставляет заказ в подвешенном статусе processing вместо on-hold.
Тестирование уведомлений и вебхуков ЮKassa
Платёж считается обработанным только после того, как сервер магазина получил вебхук на notification_url и ответил кодом 200. В тестовом режиме указывается отдельный адрес для уведомлений, и если сайт ещё не выложен на боевой сервер, для локальной разработки я поднимаю туннель через ngrok, чтобы ЮKassa могла достучаться до localhost.
Вот так выглядит тело вебхука о успешной оплате, которое приходит на notification_url:
{
"type": "notification",
"event": "payment.succeeded",
"object": {
"id": "22d6d597-000f-5000-9000-145f6df21d6f",
"status": "succeeded",
"amount": { "value": "2500.00", "currency": "RUB" },
"metadata": { "order_id": "10452" }
}
}Перед тем как писать бэкенд-обработчик, я закидываю этот вебхук в n8n на отдельный тестовый workflow и смотрю, какие поля реально приходят, потому что структура metadata зависит от того, что было передано при создании платежа. Уже потом на основе этого собираю рабочую цепочку: получение вебхука, проверка статуса, обновление заказа в CRM или отправка уведомления в Telegram-бот на aiogram. Если оплата встроена прямо в бота, тестовый инвойс обязательно проверяю до того, как бот уйдёт в публичный запуск, иначе первый же реальный платёж рискует остаться без подтверждения у продавца.
Типичные ошибки при переходе из тестового режима в боевой
Перечислю то, на чём сам ловил заказчиков и себя за последние проекты.
- Забыли заменить тестовые shop_id и secret_key на боевые в коде или в плагине, магазин выглядит рабочим, но принимает только тестовые карты.
- Notification_url остался тестовым, вебхуки боевых платежей уходят в никуда, заказы не подтверждаются.
- Не протестирован возврат (refund): в боевом режиме первый же спор с клиентом превращается в ручное разбирательство через поддержку банка.
- Тестовые карты случайно остаются в документации на сайте или в письме клиенту.
- Не проверена работа сценария при таймауте: ЮKassa ждёт ответ от сервера до 10 секунд и повторяет отправку вебхука, если обработчик не успел ответить или упал с ошибкой 500.
Перед переключением в боевой режим я прогоняю тот же список тестов, что и в самом начале, только уже на боевых данных с суммой в 1 рубль, чтобы убедиться, что деньги реально доходят на расчётный счёт и чек формируется корректно.
Интернет-магазин под ключ
Интернет-магазин
от 80 000 ₽
Подробнее →Частые вопросы
Можно ли случайно списать реальные деньги в тестовом режиме ЮKassa
Нет, тестовый режим работает с отдельной парой ключей и эмулирует ответ банка по номеру карты, реальное движение денег между счетами не происходит, поэтому даже указав случайно настоящую карту, вы не спишете с неё средства.
Сколько действует тестовый магазин ЮKassa
Ограничения по сроку нет, тестовый раздел кабинета остаётся доступным и после того, как магазин переключили на боевые платежи, поэтому им удобно пользоваться при каждой новой доработке сайта.
Нужна ли онлайн касса для тестового режима
Нет, требования 54-ФЗ распространяются только на боевые платежи с реальным движением денег, в тестовом режиме чек не формируется и не передаётся в ОФД.
Что делать если тестовый платёж завис в статусе pending
Чаще всего дело в вебхуке: обработчик на сайте либо не отвечает кодом 200, либо превышает таймаут в 10 секунд, либо notification_url указывает не на тот адрес. Проверьте логи сервера и убедитесь, что тестовый и боевой notification_url не перепутаны местами.