Antifraud

Syncra V2 включает многоуровневый antifraud-стек: ограничение скорости создания платежей (velocity), блокировка недобросовестных клиентов, автоматическую сегментацию игроков по уровням доверия, device fingerprinting и маршрутизацию каскадов по типу клиента. Эти механизмы работают на стороне бэкенда и прозрачно для мерчанта — но вы можете расширить их эффективность, передавая дополнительные заголовки при создании PayIn.

Обзор

Antifraud-функционал решает четыре задачи:

1. Защита от спама платежей (velocity) — один client_id не может создать более 10 PayIn в час.
2. Блокировка мошенников — администратор может заблокировать клиента навсегда или на срок.
3. Сегментация по доверию — игроки автоматически продвигаются по уровням FTD → STD → TRUSTED по мере успешных депозитов; VIP — ручное назначение.
4. Трекинг устройств — IP, User-Agent и SHA-256 fingerprint устройства сохраняются на записи клиента.

Эти данные также питают trust-based cascade routing: правила каскада могут фильтровать команды по customer_type, направляя VIP-игроков к проверенным трейдерам.

Velocity protection

Velocity-защита предотвращает DDoS-атаки через массовое создание PayIn одним игроком. Лимит жёстко задан в домене: один client_id не может создать более 10 PayIn в течение скользящего 1-часового окна.

Как это работает

• Проверка выполняется до сохранения сделки в БД — отклонённый запрос не оставляет зомби-записей и не занимает слот трейдера.
• Лимит применяется только к известным клиентам (client_id не пустой). Анонимные PayIn проходят без проверки.
• Защита fail-open при ошибке БД: временный сбой хранилища не блокирует легитимные деньги — но инцидент логируется.

Что произойдёт при превышении

Запрос CreateMerchantPayIn вернёт ошибку (RFC 9457 problem+json):

HTTP/1.1 429 Too Many Requests

{
  "type": "about:blank",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "client rate limit exceeded: velocity ceiling of 10 PayIn/hour reached",
  "instance": "/api/v1/p2p/merchant/deals/payin"
}

Что делать мерчанту

• Не ретратьте запрос сразу — клиент уже исчерпал лимит (см. Retry-матрицу).
• Покажите игроку сообщение «слишком много попыток, попробуйте позже».
• Лимит сбрасывается по скользящему окну — через час возможность вернётся.

Customer blocking

Администратор может заблокировать клиента (IsBlocked = true) с указанием срока (BlockedUntil) или бессрочно. Заблокированный клиент не может создавать новые платежи и открывать checkout.

Логика блокировки

Клиент считается заблокированным, если выполняется условие:

IsBlocked == true
  AND (BlockedUntil == nil              // бессрочная блокировка
       OR BlockedUntil > now())         // срочная блокировка ещё активна

• BlockedUntil == nil — блокировка навсегда (только ручное снятие).
• BlockedUntil в будущем — блокировка до указанной даты.
• BlockedUntil в прошлом — блокировка истекла, клиент снова активен.

Ошибка при попытке платежа

HTTP/1.1 403 Forbidden

{
  "type": "about:blank",
  "title": "Forbidden",
  "status": 403,
  "detail": "customer is blocked",
  "instance": "/api/v1/p2p/merchant/deals/payin"
}

Управление блокировкой

Блокировка управляется только через административную панель Syncra (раздел Customers). API для мерчантов не позволяет блокировать клиентов самостоятельно — это решение принимается командой поддержки на основе antifraud-аналитики.

Сегментация клиентов (FTD / STD / TRUSTED / VIP)

Каждый клиент имеет тип (customer_type), отражающий уровень доверия. Сегментация используется для маршрутизации каскадов и аналитики.

Четыре уровня

Автоматическая сегментация

Когда PayIn-сделка достигает статуса COMPLETED, бэкенд инкрементирует счётчик депозитов клиента и проверяет порог:

FTD  → STD      при DepositCount >= 3
STD  → TRUSTED  при DepositCount >= 10
TRUSTED / VIP   — ручное управление, авто-продвижения нет

Пример: жизненный цикл клиента

Новый игрок          → FTD      (1 депозит)
                     → FTD      (2 депозита)
3-й успешный депозит → STD      (авто-промоция)
...
10-й депозит         → TRUSTED  (авто-промоция)
...
Решение админа       → VIP      (ручной оверрайд)

Device fingerprinting

Device fingerprint — это SHA-256 хэш характеристик устройства игрока, отправляемый payform-SPA. Он сохраняется в поле LastFingerprint записи клиента и используется для связывания сессий и antifraud-аналитики.

Как передать fingerprint

Payform SPA отправляет fingerprint автоматически. Если вы используете собственный фронтенд, передавайте заголовок при создании PayIn или при открытии checkout:

X-Player-Fingerprint: a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b

Заголовок читается бэкендом из gRPC metadata (x-player-fingerprint или grpcgateway-x-player-fingerprint для REST-шлюза) и передаётся в UpdatePayer провайдера, если адаптер поддерживает payer enrichment.

Player tracking (IP и User-Agent)

Помимо fingerprint, Syncra фиксирует сетевые атрибуты игрока для antifraud-аналитики:

Эти поля обновляются при каждом касании клиента (создание PayIn, открытие checkout). IP и UA используются для выявления подозрительной активности (например, смена гео, эмуляторы).

Пример запроса с полным трекингом

curl -X POST https://api.syncra.money/api/v1/p2p/merchant/deals/payin \
  -H "X-Merchant-Token: $TOKEN" \
  -H "X-Timestamp: $TS" \
  -H "X-Signature: t=$TS,v1=$SIG" \
  -H "Content-Type: application/json" \
  -H "X-Player-Fingerprint: a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b" \
  -d '{
    "amount": 150000,
    "currency": "RUB",
    "client_id": "player_9921",
    "idempotency_key": "f3b8a1c2-4d5e-4f6a-9b0c-1d2e3f4a5b6c"
  }'

Trust-based cascade routing

Правила каскада (CascadeRule) могут дополнительно фильтровать команды по типу клиента (customer_type). Это позволяет направлять VIP-игроков к проверенным командам трейдеров, а новых — к более широкой сети.

Логика матчинга

Поле customer_type в правиле каскада работает так:

• customer_type пустой/отсутствует — универсальное правило, матчит все типы клиентов. Обратно совместимо с правилами, созданными до введения сегментации.
• customer_type = "VIP" — правило применяется только к VIP-клиентам.
• Неизвестный игрок (client_id пустой, тип не определён) — матчится только с универсальными правилами.

Пример конфигурации каскада

Каскадный маршрутизатор итерирует правила по приоритету ASC и выбирает первую команду с eligible on-shift трейдерами и подходящим customer_type.

Сводка ошибок antifraud

Полный справочник кодов и retry-стратегий — в Коды ошибок.

Связанные материалы

• Коды ошибок — полный справочник, включая CLIENT_RATE_LIMITED и CUSTOMER_BLOCKED.
• Приём платежей (PayIn) — создание PayIn с заголовками трекинга.
• Hosted Checkout — payform автоматически отправляет fingerprint.
• Сделки — cascade routing и matching.