3D-Secure 2.0 не лечит фрод: он режет конверсию и любит глючить

3D-Secure 2.0 не лечит фрод: он режет конверсию и любит глючить

3DS2 продают как магию: меньше фрода, больше одобрений, довольный риск-менеджер. На практике вы получаете дополнительный редирект, кривой challenge flow и пачку «непонятно, кто виноват» между PSP, эмитентом и вашим фронтом. Идемпотентность или смерть.

Падает конверсия обычно не из-за самого 3DS, а из-за вашей интеграции:
— не ловите frictionless/challenge как разные сценарии;
— ломаете возврат в сессию после ACS;
— теряете статус транзакции между вебхуком и ответом клиента;
— не умеете корректно обрабатывать таймауты и повторные попытки.

Фрод при этом остается на месте, потому что 3DS — это не щит, а один сигнал в риск-движке. Если вы не режете поведенческие аномалии, не ставите velocity-лимиты и не связываете device fingerprint с историей платежа, мошенник просто обходит ваш красивый костыль на костыле и финтехом погоняет.

Документация — это ложь, логи — истина. Смотрите, где именно отваливается цепочка: before challenge, after challenge, on webhook, on settlement. И отдельно проверяйте, не дублируете ли вы авторизацию при ретраях — там обычно прячется половина «мистических» потерь.

Не пытайтесь «включить 3DS и забыть». Сначала сделайте нормальную маршрутизацию статусов, потом отладьте возврат пользователя и только потом измеряйте конверсию.