3D-Secure 2.0: почему конверсия падает, а фрод всё равно пролезает

3D-Secure 2.0: почему конверсия падает, а фрод всё равно пролезает

3DS2 продавали как магию: меньше трения, больше frictionless, фрод сам сдохнет. В реальности он просто переложил грязь из одного места в другое. Если эмитент не видит нормального risk-data, он уходит в challenge. Если видит мусор — тоже уходит в challenge. И конверсия сгорает не на оплате, а на тупой передаче кривых полей.

Главные косяки на интеграции:
— device data не собирается или отправляется обрезанным;
— browser_info заполнен «на отвали»;
— billing/shipping не бьются между собой;
— recurring и MIT/CIT размечены как попало;
— fallback на 3DS1 живёт отдельной жизнью.
Итог предсказуем: банк не верит в сценарий, а вы платите за лишний challenge.

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

Проверяйте не «включен ли 3DS», а качество payload, логи вызовов и долю challenge по сегментам. Если challenge растёт, а фрод не падает — проблема не в протоколе, а в вашей кривой интеграции. Документация — это ложь, логи — истина.