Безопасность и антифрод для интернет-магазина

Антифрод в e-commerce — это не «стена», а термостат. Вы балансируете между пропуском плохой транзакции и потерей хорошей. Любая «жёсткость» — это плата конверсией; любая «мягкость» — плата чарджбэками. Побеждает тот, кто дозирует трение: даёт свободу там, где сигнал чистый, и аккуратно усложняет путь там, где риск растёт.

Карта угроз: кто и как на нас охотится

Реальные сценарии атак выглядят так:

• Кардинг и тесты BIN: массовые микроплатежи для подбора рабочих карт и 3DS-паттернов.
• Credential stuffing: перебор логинов по утечкам и кража бонусов/адресов.
• Скрэпинг и виталинг: парсинг цен/остатков для демпинга или скупки дефицита.
• Социальные атаки: возвраты «без товара», споры «не получил».
• Интеграционные риски: перехват/подмена вебхуков, утечки секретов, отсутствие идемпотентности.

Маркеры риска: что реально сигналит

Один признак редко решает всё; работают ансамбли.

• Устройство и сеть: новый девайс для этого аккаунта, резкая смена страны/ASN, несоответствие языка браузера и валюты.
• Поведение сессии: сверхбыстрый путь к оплате, копипасты в чувствительных полях, аномально ровные тайминги, циклы «ошибка → повтор» с микропаузами.
• Состав корзины: дешёвый товар + дорогая экспресс-доставка, множественные подарочные карты, странные комбинации размеров.
• На оплате: серия неудачных попыток из одного BIN, разные карты на один адрес, несовпадение billing/shipping.
• История: «новый пользователь — дорогая покупка — просьба ускорить», частая смена адресов, правки e-mail/телефона перед оплатой.

Итог — риск-скор (0…1), который решает маршрут: пропустить, попросить допфактор, дать 3DS-challenge или отклонить.

3DS2: где спасает, а где ломает путь

3DS2 работает в двух режимах: frictionless (банк подтверждает без запроса) и challenge (код/биометрия). Чем больше контекста вы передаёте платёжному провайдеру и эмитенту, тем выше шанс frictionless.

• Передавайте «толстые» данные: адреса, user-agent, отпечаток устройства, историю аккаунта.
• Включайте challenge на пороге риска (новый девайс + дорогая корзина + рассинхрон адресов и т. п.).
• Следите за step-up rate, challenge success rate, кодами отказов эмитентов.

Главная ошибка — включить 3DS «для всех»: так вы защититесь… от собственной конверсии.

Поведенческая биометрия: «как печатает» важнее «кто он»

Это микропаттерны взаимодействия: динамика набора текста, траектории курсора, инерция свайпов, баланс тача/клавиатуры. Сильна как добавочный слой, а не замена 3DS.

Применение:

• Регистрация/логин — детект «нечеловеческих» паттернов без лишних капч.
• Checkout — отличать нового девайса реального клиента от «ровно печатающего» бота.
• Формы возвратов/саппорта — аномальные паттерны ввода.

Граница приватности: храните не «сырые треки» курсора, а агрегаты; уважайте отказ от трекинга.

Боты, rate-лимиты и мягкие капканы

• Фингерпринт устройства/сессии (Canvas/WebGL, шрифты, кодеки) — как слой, а не основа.
• Невидимые ловушки: скрытые поля-«мёд», JS-задачи сложные для headless-ботов.
• Умные лимиты: не по IP, а по связкам «IP + устройство + аккаунт + BIN + адрес».
• «Болота» для carding: накапливайте задержку ответа при частых фейлах.
• Челлендж поэтапно: вычислительные задачи → только потом капча, и лишь по риск-сегментам.

Безопасные вебхуки и секреты: мелочи, на которых всё падает

• Подписывайте вебхуки: HMAC от тела + метка времени; проверяйте по ротационным секретам и окну времени.
• Идемпотентность: повтор одного event_id безопасен.
• Не полагайтесь только на списки IP — используйте mTLS или подпись полезной нагрузки.
• Секреты храните в хранилищах с ротацией и аудитом; доступ — по принципу наименьших прав.
• Логируйте ретраи вебхуков как события первого класса.

Логи как рентген: куда смотреть

• Единый trace_id от PDP до ответа PSP и обратного вебхука.
• Слои телеметрии: решения риск-движка, ответы эмитента, поведение клиента.
• Сводки по атакам: частоты ошибок по BIN/ASN, «взрывные» попытки, тепловые карты времени.
• 3DS-метрики: доли frictionless/challenge, успех challenge, коды отказов — по стране/банку/девайсу.
• Вебхуки: доля ретраев, медиана задержки, рассинхроны с PSP.

Паник-лист дежурного: рост неуспешных попыток из одного ASN, всплеск do_not_honor, провал доли frictionless у конкретного банка, лавина повторов вебхуков.

Как не убить конверсию: дозированное трение

• Новый девайс + дорогая корзина + экспресс-доставка → step-up/3DS-challenge.
• Старая учётка + знакомый девайс → пропуск без трения.
• Повторы из одного BIN → «болото» и ограничение частоты, а не капча всем.
• Адресные поля — валидируйте по локали, повышайте одобряемость у PSP.

Каждое «трение» должно быть оправдано измеряемым снижением риска — не «так спокойнее».

Мини-практикум: первый скелет риск-движка

• Сигналы: устройство, сеть, гео, поведение, корзина, история аккаунта.
• Модель: логистическая регрессия/градиентный бустинг + правила-ограничители.
• Оркестрация: ветки allow / step-up / deny по порогам скор-кривой.
• Обратная связь: помечайте чарджбэки/споры/«не получил», храните причины решений.
• Эксперименты: держите holdout-долю трафика для честной оценки вклада мер.

Финальный разворот: что считать успехом

Цель — не «ноль фрода», а минимальная стоимость риска при заданной выручке.

• Операционные: approval rate, доля frictionless, step-up rate, успех challenge, latency checkout.
• Финансовые: fraud-rate, chargeback-rate, валовая прибыль на сессию с учётом трения.
• Детективные: время до обнаружения паттерна атаки, время до деплоя контрмер, полнота аннотаций событий.

Вывод: настройте «термостат»: ротация секретов, регулярные «учения», отчётность по инцидентам и ревизии трения — и цифры начнут ползти в нужную сторону без потерь CR.