Как проверить прохождение 3-D Secure при оплате тестовой картой

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

Разберёмся, как реально проверить, что ваш онлайн-платёж прошёл через 3-D Secure в тестовой среде — по шагам, без воды и с пониманием, на что смотреть.

Что такое 3-D Secure и зачем это проверять

3-D Secure (3DS) — это дополнительный уровень безопасности для онлайн-платежей. Вы его знаете как «подтверждение по SMS» или «код из push-уведомления банка». Формально это протокол, который перекладывает ответственность за мошеннический платёж на банк-эмитент (банк клиента), а не на вас-мерчанта.

Зачем проверять именно в тестовом режиме? Потому что:

• Тестовые карты имитируют разные сценарии — успешная аутентификация, неудачная, отказ от подтверждения.
• Вы можете отловить баги до того, как реальные клиенты начнут терять деньги.
• Провайдеры тестовых сред по-разному реализуют 3DS — где-то это полноценная эмуляция, где-то заглушка.
• От результата зависит, как вы настроите логику обработки платежей на своей стороне.

Какие бывают версии 3-D Secure

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

Параметр	3DS 1.0	3DS 2.0 (EMVCo)	3DS 2.1+
Как выглядит для клиента	Перенаправление на страницу банка, ввод кода из SMS	Всплывающее окно или встроенный фрейм, push/биометрия	Аналогично 2.0, но с поддержкой расширенных сценариев
Объём передаваемых данных	Минимум	До 100+ полей: адрес, история устройст email	Расширенный набор полей, поддержка decoupled flow
Frictionless (без шага подтверждения)	Нет	Да, если банк и мерчант прошли risk assessment	Да, более гибкие правила
Тестовые сценарии у провайдеров	Базовые: успех / отказ	Широкие: frictionless, challenge, отказ, таймаут	Максимально широкие
Поддержка провайдерами	Повсеместно	Повсеместно	Зависит от конкретного провайдера

Большинство современных интеграций работают с 3DS 2.x. Именно её мы и будем проверять.

Что понадобится для проверки

Прежде чем начинать, убедитесь, что у вас есть:

1. Доступ к тестовой среде — тестовый мерчант-аккаунт у вашего платёжного провайдера (или эмулятор, если интегрируетесь напрямую).
2. Тестовые карты с поддержкой 3DS — у каждого провайдера свой набор. Обычно они есть в документации или в личном кабинете.
3. Доступ к логам — вам нужно видеть полный запрос и ответ по транзакции, включая параметры 3DS.
4. Инструмент для отправки запросов — если вы на этапе разработки, подойдёт Postman или curl. Если тестируете через сайт — консоль разработчика (вкладка Network).

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

Шаг 1. Совершите тестовый платёж

Возьмите тестовую карту, которая требует прохождения 3DS (challenge flow). Например, у многих провайдеров это карта с номером, содержащим определённый префикс, или специально указанная в документации как «3DS 2.0 Challenge».

Проведите оплату на тестовом стенде — через ваш сайт, мобильное приложение или напрямую через API.

Шаг 2. Дождитесь появления шага аутентификации

В зависимости от реализации вы должны увидеть:

• Всплывающее окно (challenge window) с полем для ввода кода.
• Перенаправление на страницу банка-эмитента.
• Push-уведомление в приложении банка (в полноценных тестовых средах крупных провайдеров).

Если этого шага нет и платёж сразу прошёл — скорее всего, сработал frictionless flow (бесшовный проход), либо 3DS вообще не был инициирован. Это отдельный сценарий, который мы разберём ниже.

Шаг 3. Пройдите аутентификацию

Введите тестовый код подтверждения. У каждого провайдера свои правила:

• Часто подходит любой код из 6 цифр.
• Иногда есть специальный код, который имитирует неудачную попытку (например, «000000» или «123456»).
• В некоторых эмуляторах код отправляется на тестовый email или отображается прямо в интерфейсе.

Шаг 4. Проверьте ответ сервера (самое важное)

Вот тут начинается реальная работа. Вам нужно посмотреть, что вернулось в ответе на транзакцию. Именно здесь видно, прошёл ли 3-D Secure корректно.

Откройте логи транзакции — в личном кабинете провайдера, в вашей системе логирования или через инструмент перехвата запросов. Ищите следующие параметры:

• transStatus (или threeDSStatus, status) — статус аутентификации. Значение Y означает успешную верификацию, N — отказ, A — попытка аутентификации (attempted), U — невозможно проверить.
• cavv (Cardholder Authentication Verification Value) или authenticationValue — криптографический токен, подтверждающий, что банк-эмитент действительно провёл проверку. Если это поле пустое — 3-D Secure не сработал.
• eci (Electronic Commerce Indicator) — индикатор, показывающий результат аутентификации. Для успешного 3DS значение обычно 05 (полностью аутентифицирован) или 06 (attempted). Для frictionless — 07 или 05 в зависимости от схемы.
• threeDSServerTransID — уникальный идентификатор транзакции 3DS. Должен быть заполнен.
• acsTransID — идентификатор транзакции от стороны ACS (Access Control Server, сервер банка-эмитента).

Если все эти поля заполнены корректно и transStatus = Y — поздравляю, 3-D Secure прошёл успешно.

Шаг 5. Проверьте статус финального платежа

Успешное прохождение 3DS не гарантирует, что платёж в итоге будет успешным. Проверьте:

• Статус авторизации (authorized / declined).
• Наличие суммы на холде (если используется холдирование).
• Корректность callback-уведомления от провайдера (webhook).

Сценарии для проверки: что именно тестировать

Не достаточно проверить один сценарий. 3-D Secure — это набор веток, и каждая должна работать. Вот минимальный набор сценариев, который стоит прогнать:

Сценарий	Что проверять	Ожидаемый результат
Успешная аутентификация (challenge)	Ввод правильного кода в challenge window	transStatus=Y, cavv заполнен, eci=05, платёж authorized
Отказ от аутентификации	Закрытие challenge window или нажатие «Отмена»	transStatus=N, платёж declined или отменён
Неправильный код	Ввод неверного кода подтверждения	transStatus=N или A, повторный запрос или отказ
Frictionless (бесшовный проход)	Платёж по карте, которая проходит без challenge	Challenge window не появляется, transStatus=Y, cavv заполнен
Таймаут аутентификации	Не вводить код в течение таймаута (обычно 5-10 минут)	transStatus=U, платёж declined
Карта без поддержки 3DS	Оплата по тестовой карте, не участвующей в 3DS	3DS не инициируется, платёж проходит без проверки

Как проверить через API (если вы разработчик)

Если вы интегрируетесь напрямую и хотите видеть всё «в железе», вот примерный алгоритм проверки через API:

1. Отправьте запрос на авторизацию с тестовой картой.
2. В ответе ищите поле threeDSMethodURL (если используется 3DS 2.0 с методом) и acsURL — адрес, куда нужно отправить клиента для аутентификации.
3. После прохождения аутентификации отправьте запрос с параметрами threeDSCompInd (индикатор завершения 3DS) и полученными от ACS данными.
4. Проверьте финальный ответ — именно он содержит transStatus, cavv, eci.

Пример того, что вы должны увидеть в ответе (упрощённо):

{
  "transaction_id": "txn_abc123",
  "status": "authorized",
  "three_ds": {
    "transStatus": "Y",
    "cavv": "AAABCAYJAAAAAAAACBExmBqEoWA==",
    "eci": "05",
    "threeDSServerTransID": "def-456-ghi",
    "acsTransID": "jkl-789-mno"
  }
}

Если transStatus равен Y и cavv не пустой — 3-D Secure прошёл корректно. Если transStatus равен N — аутентификация не удалась. Если transStatus отсутствует — 3-D Secure вообще не был инициирован.

Частые ошибки при проверке

Вот реальные проблемы, с которыми сталкиваются при тестировании 3-D Secure:

• Платёж проходит без challenge, но вы ожидаете его. Это нормально — значит, сработал frictionless flow. Проверьте, что в ответе заполнен cavv и eci. Если они пустые — проблема.
• Challenge window появляется, но после ввода кода ничего не происходит. Скорее всего, проблема на стороне ACS или в обработке ответа. Проверьте логи — возможно, запрос на ACS таймаутился.
• transStatus = A (attempted). Это означает, что банк попытался провести аутентификацию, но не смог завершить. В боевом режиме такие платежи обычно отклоняются. Проверьте, обрабатываете ли вы этот статус корректно.
• cavv пустой при transStatus = Y. Это противоречие. Если аутентификация успешна, cavv должен быть. Проверьте маппинг полей — возможно, вы смотрите не туда.
• Тестовая среда не поддерживает 3DS 2.0. Некоторые провайдеры в тестовом режиме эмулируют только 3DS 1.0. Уточните у них документацию — какие версии поддерживаются в тестовой среде.
• Вы проверяете только успешный сценарий. Обязательно прогоняйте и неуспешные — отказ, таймаут, неверный код. Именно на этих сценариях чаще всего вылезают баги.

Что делать в зависимости от вашей ситуации

Если вы на этапе разработки

Используйте Postman или curl для отправки запросов напрямую. Так вы видите все параметры и можете контролировать каждый шаг. Заведите коллекцию запросов для каждого сценария — это сэкономит время при регрессе.

Если вы тестируете через готовый сайт

Откройте консоль разработчика (F12 → Network), проведите платёж и найдите запросы к платёжному шлюзу. Фильтруйте по ключевым словам: three, 3ds, acs, auth. Проверьте и запрос, и ответ.

Если вы приёмщик платежей (не разработчик)

Зайдите в личный кабинет платёжного провайдера, найдите тестовую транзакцию и откройте детали. У большинства провайдеров в деталях транзакции отображается статус 3DS. Если не видите — обратитесь в поддержку провайдера с просьбой показать, где в интерфейсе отображается результат аутентификации.

Если 3-D Secure не работает вообще

Проверьте по цепочке:

1. Включён ли 3DS в настройках вашего мерчант-аккаунта (тестового).
2. Поддерживает ли выбранная тестовая карта 3DS (сверьтесь с документацией).
3. Передаёте ли вы в запросе все необходимые поля для инициации 3DS (например, threeDSRequestorURL, notificationURL).
4. Не блокируется ли challenge window браузером (всплывающие окна часто блокируются).

На что смотреть в логах: краткий чек-лист

Когда открываете логи транзакции, проверьте наличие и значения следующих полей:

• transStatus — Y (успех), N (отказ), A (attempted), U (unavailable).
• cavv / authenticationValue — не пустой при успешной аутентификации.
• eci — 05 или 06 для полного прохождения 3DS.
• threeDSServerTransID — заполнен.
• acsTransID — заполнен.
• authenticationType — тип аутентификации (01 — по паролю, 02 — по SMS, 03 — по push и т.д.).
• challengeCompletionInd — признак завершения challenge (true/false).

Если все эти поля на месте и заполнены корректно — 3-D Secure прошёл как надо.

Итог: что делать дальше

Проверка 3-D Secure в тестовом режиме — это не разовое действие, а систематическая работа. Вот что рекомендую:

1. Прогоните все сценарии из таблицы выше — успех, отказ, таймаут, frictionless.
2. Проверяйте не только факт прохождения, но и корректность заполнения полей в ответе (cavv, eci, transStatus).
3. Автоматизируйте проверку — если у вас CI/CD, добавьте тесты на 3DS в пайплайн.
4. Не забывайте про негативные сценарии — именно они спасают в бою.
5. Фиксируйте результаты — для каждого сценария запишите, что вы ожидаете и что получили. Это пригодится при аудите и при общении с платёжным провайдером.

Если после всех проверок вы видите, что transStatus = Y, cavv заполнен, eci = 05 и платёж авторизован — значит, 3-D Secure работает корректно. Можно выкатывать в бой.

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