Как проверить, что ваш онлайн-платёж прошёл проверку 3-D Secure в режиме «тестовой карты»

Как проверить, что ваш онлайн-платёж прошёл проверку 3-D Secure в режиме «тестовой карты»

Вы настраиваете платёжную систему — Stripe, PayPal, Яндекс.Касса, или что-то своё — и хотите убедиться, что 3-D Secure работает. Не просто «вроде работает», а действительно: проверка прошла, система увидела ответ от банка, и платёж засчитан как защищённый. Но вы не можете использовать реальную карту. Или боитесь, что случайно спишете деньги. Или просто не хотите рисковать. Поэтому вы используете тестовую карту. И тут возникает вопрос: как понять, что 3-D Secure фактически сработал, а не просто пропустил платёж мимо проверки?

Это не про то, как настроить тестовые ключи. Это про то, как убедиться, что проверка прошла реально, как если бы это была живая карта. И да — это реально можно проверить. Без риска, без денег, без лишних звонков в поддержку.

Почему это важно?

Если 3-D Secure не срабатывает — вы теряете защиту от споров. Платёж может быть признан неподтверждённым, и вы рискуете потерять деньги по спору. Банк клиента может отказать в компенсации, потому что не было подтверждения через 3-D Secure. Это не теория — это реальные потери. Особенно если вы продаете цифровые товары, подписки или услуги, где нет физического возврата.

Но если вы просто вводите тестовую карту и видите «Success» — это не значит, что 3-D Secure сработал. Это значит, что платёж прошёл. Без проверки. И вы об этом даже не узнаете.

Как работает 3-D Secure в тестовом режиме

Тестовые карты — это не просто номера, которые «не снимают деньги». Они эмулируют поведение реальных карт. У каждой платёжной системы есть свои наборы тестовых карт, и каждая из них имитирует определённый сценарий:

• Успешная аутентификация
• Отказ в аутентификации
• Требуется дополнительная верификация (например, SMS-код)
• Платёж отклонён банком
• 3-D Secure не поддерживается

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

Пошагово: как проверить, что 3-D Secure сработал

1. Выберите правильную тестовую карту
   У каждой платёжной системы — свои карты. Например:
   — Stripe: 4000002500003155 — успешный 3-D Secure
   — Stripe: 4000002760003184 — требует аутентификации (имитирует SMS)
   — Adyen: 4111111111111111 — сработает как 3-D Secure, если включён в настройках
   — PayPal: тестовые карты не используются напрямую — вместо этого используется Sandbox с виртуальными аккаунтами

   Важно: не используйте карты из старых гайдов. Номера меняются. Всегда сверяйтесь с официальной документацией вашей платёжной системы.

2. Запустите платёж в тестовом режиме
   Убедитесь, что вы не в продакшене. В Stripe — это флаг live_mode=false. В PayPal — вы в Sandbox. В Яндекс.Кассе — тестовый ключ и режим test. Если вы не уверены — проверьте URL: если там api.stripe.com — это продакшен. Если api.stripe.com/v1/test — это тест. Уточните у своей системы.
3. Следите за поведением
   После ввода номера тестовой карты вы должны увидеть окно 3-D Secure — всплывающее окно, фрейм, или перенаправление на сайт банка (даже если это фейковый банк). Если его нет — 3-D Secure не запущен. Это уже тревожный знак.
4. Пройдите проверку
   Если система требует ввести код — введите любой (например, 123456). В тестовом режиме код не проверяется. Важно — вы должны его ввести. Не закрыть окно. Не пропустить. Это симулирует реальный процесс.
5. Проверьте ответ от платёжной системы
   После завершения платёжа — зайдите в панель администратора вашей платёжной системы (Stripe Dashboard, Adyen Customer Area и т.д.). Найдите этот платёж. Откройте его детали. Ищите поле:
   — three_d_secure
   — authentication_result
   — status

   Если вы видите что-то вроде:
   "three_d_secure": { "status": "authenticated" }
   — значит, проверка прошла. Если там "status": "not_enrolled" или "status": "failed" — значит, 3-D Secure не сработал, или карта не поддерживает его.

6. Сравните с ожидаемым результатом
   Вернитесь к таблице тестовых карт. Вы использовали 4000002500003155 — она должна дать authenticated. Если вы получили failed — значит, что-то не так с вашей интеграцией. Возможно, вы не включили 3-D Secure в настройках, или не передаёте нужные параметры (например, payment_method_data[card][three_d_secure]).

Таблица: тестовые карты и их поведение в 3-D Secure

Платёжная система	Тестовая карта	Ожидаемый результат 3-D Secure	Что проверять в панели
Stripe	4000002500003155	Успешная аутентификация	three_d_secure.status == "authenticated"
Stripe	4000002760003184	Требуется аутентификация (имитация SMS)	three_d_secure.status == "authenticated" (после ввода кода)
Stripe	4000008260003178	Отказ в аутентификации	three_d_secure.status == "failed"
Adyen	4111111111111111	Успешная аутентификация (если 3DS включён)	Проверьте authResult в paymentDetails
PayPal	Не используются	Используйте тестовый аккаунт покупателя в Sandbox	Проверьте payment_status и auth_status в вебхуке
Яндекс.Касса	4000000000000002	Успешная аутентификация	В ответе API: "three_d_secure": true

Важно: в Adyen и PayPal поведение может зависеть от настроек терминала. Если вы используете их — убедитесь, что в настройках платёжного аккаунта включён 3-D Secure v2. Без этого даже правильная карта не запустит проверку.

Что выбрать в зависимости от ситуации

• Если вы тестируете интеграцию впервые — начните с 4000002500003155 (Stripe) или 4000000000000002 (Яндекс.Касса). Это самый простой сценарий: «всё прошло успешно». Если он не работает — проблема в базовой настройке.
• Если вы проверяете обработку отказов — используйте карту с failed результатом. Убедитесь, что ваша система не просто «падает», а показывает пользователю понятное сообщение: «Платёж не подтверждён банком. Попробуйте другую карту».
• Если вы делаете мобильное приложение — проверьте, что 3-D Secure открывается в встроенном браузере, а не в отдельном приложении банка. В iOS и Android это критично: если приложение перекидывает в Safari или Chrome — это может сломать возврат в ваше приложение. Тестовые карты помогут проверить этот сценарий.
• Если вы продаете в ЕС — вам обязательно нужен 3-D Secure v2. Проверьте, что в ответе от платёжной системы есть поле eci_flag со значением 05 или 06 — это означает, что используется именно v2. Старый v1 уже не соответствует PSD2.

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

• Проверяете только статус «Success». Платёж может быть успешен, а 3-D Secure — не запущен. В Stripe это выглядит как status: "succeeded" и three_d_secure: null. Это опасно.
• Используете одну и ту же карту для всех тестов. Если вы всегда используете 4000002500003155, вы никогда не узнаете, как ваша система ведёт себя при отказе или требовании кода.
• Забываете включить 3-D Secure в настройках. В Stripe это не включено по умолчанию. Нужно зайти в Dashboard → Payments → 3D Secure → включить. Без этого даже правильная карта не запустит проверку.
• Проверяете только в браузере. На мобильном устройстве может быть другое поведение. Проверяйте на iPhone и Android. Особенно если вы используете WebView.
• Думаете, что «тестовая карта» = «без проверки». Нет. Тестовая карта эмулирует проверку. Если вы её не проходите — вы не тестируете 3-D Secure. Вы тестируете обход проверки.

Как лучше сделать

• Создайте чек-лист для тестирования. Заведите таблицу в Google Sheets: карта → ожидаемый результат → что проверили → дата. Это спасёт вас, когда вы будете добавлять новые платежные методы.
• Настройте вебхуки. Не полагайтесь только на панель. Подключите вебхук на событие payment_intent.succeeded и проверяйте, что в теле приходит three_d_secure.status == "authenticated". Это ваша «автоматическая проверка».
• Тестируйте не только «да», но и «нет». Запустите платёж с картой, которая должна отклониться. Убедитесь, что пользователь не видит «Ошибка 500», а видит понятное сообщение. Это критично для конверсии.
• Проверяйте логи сервера. Если вы видите, что платёж прошёл, но в логах нет вызова API к /v1/payment_intents/{id}/confirm с параметром use_stripe_sdk=true — значит, вы не запускаете 3-D Secure. Это частая ошибка в кастомных интеграциях.

Сценарии: что делать, если что-то пошло не так

• Ситуация: Вы ввели тестовую карту, но окно 3-D Secure не появилось.
  Что делать: Проверьте, включён ли 3-D Secure в настройках платёжной системы. Проверьте, передаёте ли вы payment_method_data[card][three_d_secure] или use_stripe_sdk=true. Проверьте, что вы используете новую версию SDK. Старые версии могут не поддерживать v2.
• Ситуация: В панели вы видите three_d_secure.status == "not_enrolled".
  Что делать: Это значит, что карта не зарегистрирована в системе 3-D Secure. Это нормально для некоторых тестовых карт. Попробуйте другую — например, 4000002760003184. Если и она даёт not_enrolled — возможно, вы не используете правильный тип карты (например, дебетовую вместо кредитной). Или ваша платёжная система не поддерживает 3-D Secure для этого типа карты.
• Ситуация: Платёж прошёл, но в логах вы не видите вебхук с подтверждением аутентификации.
  Что делать: Убедитесь, что ваш вебхук настроен на правильный URL и имеет статус «Active». Проверьте, что он не блокируется фаерволом. Используйте инструмент вроде webhook.site для временного тестирования.

Итог: что делать прямо сейчас

Вот что вам нужно сделать сегодня:

1. Зайдите в панель вашей платёжной системы (Stripe, Яндекс.Касса и т.д.).
2. Найдите раздел «Тестовые карты» в документации.
3. Возьмите одну тестовую карту, которая должна пройти 3-D Secure (например, 4000002500003155 для Stripe).
4. Запустите платёж в тестовом режиме. Пройдите все шаги — включая ввод кода, если он запрашивается.
5. Зайдите в панель администратора. Найдите этот платёж. Проверьте поле three_d_secure.status.
6. Если там authenticated — вы сделали всё правильно. Если нет — ищите ошибку в настройках.
7. Повторите с картой, которая должна отказать. Убедитесь, что ваша система не ломается.

Если вы это сделаете — вы не просто «проверили». Вы подтвердили, что ваша система защищает платёж. Это значит, что если клиент в будущем спорит с банком — вы будете в безопасности. И не потеряете деньги.

Информация в этой статье носит ознакомительный характер. Настройка платёжных систем требует понимания юридических и технических рисков. Перед внедрением в продакшен проконсультируйтесь с техническим специалистом или платёжным провайдером.