3D-Secure 2.0 режет конверсию не потому, что он плохой, а потому что его часто внедряют как костыль

3D-Secure 2.0 режет конверсию не потому, что он плохой, а потому что его часто внедряют как костыль

Половина команд втыкает challenge на всё подряд, а потом удивляется просадке авторизации. Банк видит «подозрительно» — и вы отправляете нормального клиента в лишний фрикцион. Документация обещает frictionless, а в логах у вас один и тот же цирк: лишние редиректы, кривые return_url, потерянные session_id.

Что обычно ломает воронку:
— не прокинуты device data, и скоринг слепой;
— 3DS вызывают до проверки риска, а не после;
— нет нормальной идемпотентности на повторный submit;
— фронт не умеет переживать обрыв между challenge и callback.

И да, фрод это не убивает магически. Мошенник просто адаптируется: ворует токены, бьёт в low-risk сегменты, давит на слабые места в аутентификации и уходит туда, где у вас старый маршрут без 3DS. Идемпотентность или смерть. Без неё вы ещё и получите двойные попытки, двойные холды и прекрасный вечер с поддержкой.

Нормальная схема простая: риск-движок решает, когда звать 3DS, логируете все статусы, умеете восстанавливать сессию и отдельно меряете approve rate по frictionless/challenge. Если этого нет, вы не «подключили 3DS 2.0», а просто добавили ещё один слой боли.