Если вы работаете с онлайн-платежами, вы наверняка сталкивались с ситуацией: карта валидная, деньги есть, а транзакция — отклонена. Почему? Ответ часто скрыт не в самой карте, а в поведенческом анализе клиента, который запускается ещё до нажатия кнопки «Оплатить».

В этой статье разберём:

• что такое поведенческий антифрод;

• как он работает в системах вроде Stripe, PayPal и Adyen;

• какие сигналы собираются через браузер;

• как поведение пользователя влияет на судьбу транзакции;

• и как это изучают разработчики и ресёрчеры — включая тех, кто пишет на форумах вроде bfd.

Что такое поведенческий антифрод

В отличие от классического антифрода (основанного на BIN, гео, сумме и т.д.), поведенческий антифрод анализирует:

• как пользователь взаимодействует с формой (мышь, клавиатура, фокус);

• как долго он печатает;

• какие JS-объекты доступны в его окружении;

• что сообщает браузер о себе (Canvas, WebGL, Audio);

• какие события происходят до и после заполнения.

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

Какие сигналы собираются

В системах вроде Stripe и PayPal SDK встроен напрямую в платежную форму и загружает свои JS-модули. Они трекают:

• navigator.webdriver

• активность document.visibilityState

• задержки между вводом полей

• поведение мыши (mousemove, click, scroll)

• navigator.permissions.query() (определяет эмуляцию)

• fingerprint (canvas/audio/webgl)

• размер окна, доступные плагины, язык, платформу

Как SDK обрабатывает поведение

Stripe, например, использует скрипты m.stripe.com/6 и r.stripe.com/b. Эти модули:

• собирают fingerprint и behavioral data;

• формируют «оценку сессии»;

• передают результат в Stripe Radar;

• Radar решает: пропустить платёж, запустить 3DS или отклонить.

Всё это происходит ещё до отправки карточных данных.

Пример: "подозрительная" сессия

• Headless браузер

• Быстрое заполнение всех полей

• Нет движения мыши

• navigator.webdriver = true

• Canvas fingerprint → стандартный Chrome Headless

• IP — VPN или TOR

? Такая сессия почти гарантированно будет отклонена или потребует 3DS-челлендж, даже если карта валидная.

Где изучают такие механизмы

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

Один из наиболее насыщенных источников — форум BFD. Там часто публикуют HAR-логи, DevTools-дампы, поведенческие шаблоны и кейсы антифрод-срабатываний. Некоторые участники выкладывают экспериментальные конфиги undetected-браузеров и делятся тем, как SDK реагирует на разные spoof-методы.

Если вас интересует практическое тестирование платёжных SDK и безопасность с точки зрения поведения — этот форум стоит внимания.

? Как мы тестировали

Мы эмулировали 3 сценария:

1. Живой пользователь: ручной ввод, нормальные задержки, мышь — платёж прошёл без 3DS.

2. Headless с автофилом: отклонение платежа (card_declined).

3. Spoof-браузер + прокси: 3DS challenge, хотя карта не требует 3DS.

Во всех случаях одинаковая карта.

? Вывод

Поведенческий антифрод — это реальный фильтр, который активно используется даже до карточной проверки. Если форма платежа ведёт себя странно, она может быть отклонена независимо от карты.

Разработчикам стоит понимать, что UX и окружение браузера напрямую влияют на конверсию. Особенно при работе с микроплатежами и международными транзакциями.

✉️ В следующей статье — разбор r.stripe.com/b, влияние JS-полей на Radar и как DevTools может помочь предсказать отклонение до платежа.

Если интересны HAR-логи, DevTools-конфиги или примеры поведения — дайте знать. И, конечно, смотрите кейсы на bfd cash — там их десятки.