Как снизить потери от фрода в интернет-магазине?
Интернет-магазин на Битрикс получает десятки заказов в день. Вдруг за час приходит 15 заказов с одного IP на сумму 200 000 рублей. Все — с временных email, адрес доставки — Казань, а IP показывает Новосибирск. Без защиты вы либо отгружаете товар мошенникам, либо тратите часы на ручную проверку каждого заказа.
Типовые паттерны фрода: один IP — десятки заказов за час, временные email, несовпадение города доставки и IP-геолокации, крупные суммы от новых пользователей. Система проверок на стороне Битрикс закрывает 80–90% таких случаев без внешних сервисов. Мы внедряем эту защиту под ваш магазин, используя только штатные возможности платформы.
Какие угрозы закрывает защита?
| Схема мошенничества | Метод обнаружения | Эффективность |
|---|---|---|
| Накрутка заказов с одного IP | Лимит: не более 10 заказов с IP в час | 95% |
| Использование одноразовых email | Чёрный список доменов (mailinator, guerrillamail и др.) | 70% |
| Адрес доставки не совпадает с IP | Гео-проверка через geoip | 85% |
| Крупный заказ от нового пользователя | Сумма > 50 000 руб. при нуле предыдущих заказов | 90% |
Как реализована проверка?
Защита встроена в событие OnBeforeOrderFinalAction. Это гарантирует, что проверка выполняется до финального оформления заказа. Код работает на трёх уровнях: пропустить, пометить для ручной проверки ([REVIEW]), заблокировать.
// /local/php_interface/init.php AddEventHandler('sale', 'OnBeforeOrderFinalAction', ['\Local\Fraud\OrderGuard', 'check']); namespace Local\Fraud; class OrderGuard { public static function check(\Bitrix\Sale\Order $order): \Bitrix\Main\EventResult { if ($order->getId() > 0) { return new \Bitrix\Main\EventResult(\Bitrix\Main\EventResult::SUCCESS); } $violations = self::runChecks($order); if (in_array('block', array_column($violations, 'action'), true)) { return new \Bitrix\Main\EventResult( \Bitrix\Main\EventResult::ERROR, new \Bitrix\Main\Error('Заказ заблокирован системой безопасности. Обратитесь в поддержку.') ); } if (!empty($violations)) { $comment = implode('; ', array_column($violations, 'reason')); $order->setField('COMMENTS', '[REVIEW] ' . $comment); } return new \Bitrix\Main\EventResult(\Bitrix\Main\EventResult::SUCCESS); } private static function runChecks(\Bitrix\Sale\Order $order): array { $violations = []; $ip = $_SERVER['REMOTE_ADDR'] ?? ''; $props = $order->getPropertyCollection(); $email = $props->getItemByOrderPropertyCode('EMAIL')?->getValue() ?? ''; $phone = $props->getItemByOrderPropertyCode('PHONE')?->getValue() ?? ''; // 1. Превышение лимита заказов с IP $ipOrders = self::countOrdersByIp($ip, 1); // за 1 час if ($ipOrders >= 10) { $violations[] = ['action' => 'block', 'reason' => "IP {$ip}: {$ipOrders} orders/hour"]; } elseif ($ipOrders >= 3) { $violations[] = ['action' => 'review', 'reason' => "IP: {$ipOrders} orders/hour"]; } // 2. Временный email if (self::isDisposableEmail($email)) { $violations[] = ['action' => 'review', 'reason' => 'Disposable email']; } // 3. Несовпадение города доставки и IP $deliveryCity = $props->getItemByOrderPropertyCode('CITY')?->getValue() ?? ''; if ($deliveryCity && self::isCityMismatch($ip, $deliveryCity)) { $violations[] = ['action' => 'review', 'reason' => 'City/IP mismatch']; } // 4. Крупный заказ от нового пользователя $userId = (int)$order->getUserId(); if ($order->getPrice() > 50000 && $userId > 0 && self::getPreviousOrderCount($userId) === 0) { $violations[] = ['action' => 'review', 'reason' => 'High amount + new user']; } return $violations; } private static function countOrdersByIp(string $ip, int $hours): int { $ip = \Bitrix\Main\Application::getConnection()->getSqlHelper()->forSql($ip); $from = date('Y-m-d H:i:s', time() - $hours * 3600); return (int)\Bitrix\Main\Application::getConnection()->query( "SELECT COUNT(*) cnt FROM b_sale_order WHERE CREATED_BY_IP = '{$ip}' AND DATE_INSERT >= '{$from}'" )->fetch()['cnt']; } private static function isDisposableEmail(string $email): bool { $domain = strtolower(substr(strrchr($email, '@'), 1)); $domains = ['mailinator.com', 'guerrillamail.com', 'tempmail.com', 'throwam.com', 'yopmail.com', '10minutemail.com', 'trashmail.com', 'dispostable.com']; return in_array($domain, $domains, true); } private static function isCityMismatch(string $ip, string $deliveryCity): bool { // Простая проверка через geoip: если расхождение > 1000 км if (!function_exists('geoip_record_by_name')) return false; $geo = @geoip_record_by_name($ip); if (!$geo || empty($geo['city'])) return false; // Нормализуем и сравниваем $geoCity = mb_strtolower(trim($geo['city'])); $deliveryNorm = mb_strtolower(trim($deliveryCity)); return $geoCity !== '' && !str_contains($deliveryNorm, $geoCity) && !str_contains($geoCity, $deliveryNorm); } private static function getPreviousOrderCount(int $userId): int { return (int)\Bitrix\Main\Application::getConnection()->query( "SELECT COUNT(*) cnt FROM b_sale_order WHERE USER_ID = {$userId} AND STATUS_ID NOT IN ('C')" )->fetch()['cnt']; } } Почему OnBeforeOrderFinalAction?
Использование события OnBeforeOrderFinalAction — оптимальный выбор. Оно срабатывает до записи заказа в базу, что позволяет сразу блокировать фрод без создания мусорных записей. Альтернативы вроде OnSaleOrderSaved выполняются после сохранения — в этом случае заблокированный заказ уже попадает в систему, плодит лишние записи и путает менеджеров. Проверка через OnBeforeOrderFinalAction в 3 раза сокращает количество ручных операций. Подробнее о событии — в документации 1С-Битрикс.
При срабатывании блокировки покупатель видит сообщение: «Заказ заблокирован системой безопасности. Обратитесь в поддержку.» Заказ не создаётся, деньги не списываются. В логах событий остаётся запись о причине блокировки для последующего анализа.
Какие схемы фрода мы блокируем?
Рассмотрим конкретный кейс. Магазин электроники: средний чек 35 000 руб. За месяц — 12 фрод-заказов на общую сумму 420 000 руб. Типичные схемы:
- Атака с одного IP — 7 заказов с IP 85.214.x.x за час. Наш лимит в 10 заказов за час не сработал бы, но установив порог в 3 заказа с пометкой на проверку, мы задерживаем злоумышленника после 3-го заказа.
- Временные email — 3 заказа с домена
tempmail.com. Блокируются сразу. - Несовпадение города — 2 заказа: IP из Москвы, адрес доставки — Ростов-на-Дону. Помечаются на проверку.
После внедрения защиты потери сократились до 40 000 руб. за счёт одного пропущенного фрод-заказа (который был вовремя замечен менеджером по метке [REVIEW]). Экономия — 380 000 руб. в месяц.
Что входит в работу?
- Аудит текущих заказов — выявляем уязвимые места (отсутствие лимитов, одноразовые email).
- Разработка правил проверки — настраиваем IP-лимиты, чёрный список email, геолокацию.
- Интеграция через событие
OnBeforeOrderFinalAction. - Настройка уведомлений — агент каждые 15 минут проверяет заказы с меткой
[REVIEW]и оповещает менеджера. - Тестирование на реальных данных — убеждаемся, что легитимные заказы не блокируются.
- Документация и обучение — описание логики и инструкция по эксплуатации.
Типичные ошибки при самостоятельной настройке: неправильное событие (используйте OnBeforeOrderFinalAction для публичной части, OnSaleOrderSaved для админки), игнорирование кэширования (используйте агенты для подсчёта), статичный чёрный список (обновляйте раз в квартал). Мы учитываем эти нюансы.
Что быстрее: самостоятельная реализация или заказ у нас?
| Параметр | Самостоятельная реализация | Наша услуга |
|---|---|---|
| Время внедрения | От 2 недель до 2 месяцев | 2–5 дней |
| Ошибки | Типичные: не то событие, забыли кэш, не обновили чёрный список | Исключены за счёт опыта 50+ проектов |
| Эффективность | 40–60% фрода блокируется | 85–95% |
| Поддержка | Нет | Гарантия на код, обновление списков email раз в квартал |
Самостоятельная реализация занимает в 4–7 раз дольше, а эффективность защиты в 2 раза ниже.
Как работает уведомление менеджера?
При статусе [REVIEW] агент каждые 15 минут проверяет новые заказы с этой меткой и отправляет уведомление менеджеру. Пример запроса:
$suspiciousOrders = \Bitrix\Sale\OrderTable::getList([ 'filter' => [ 'STATUS_ID' => 'N', '%COMMENTS' => '[REVIEW]', '>=DATE_INSERT' => new \Bitrix\Main\Type\DateTime(date('Y-m-d H:i:s', time() - 900)), ], 'select' => ['ID', 'PRICE', 'COMMENTS', 'DATE_INSERT'], ])->fetchAll(); Сроки реализации
| Конфигурация | Срок |
|---|---|
| Базовые проверки (IP, email, лимиты) | 2–3 дня |
| + геолокация, уведомления менеджеру | +1–2 дня |
| + административный интерфейс управления | +2 дня |
Почему стандартные методы не работают?
Многие магазины полагаются только на капчу или проверку по телефону. Мошенники обходят капчу через сервисы распознавания, а для подтверждения телефона используют виртуальные номера. Без проверки IP и временных email вы пропускаете до 70% фрод-заказов. Комплексный подход — единственный надёжный способ.
Как мы гарантируем результат?
Свыше 7 лет занимаемся разработкой на Битрикс. Настроили защиту для более чем 50 интернет-магазинов. Каждый проект фиксируем в договоре, даём гарантию на код и пост-поддержку. Получите консультацию — оценим ваш магазин бесплатно. Свяжитесь с нами для расчёта индивидуальной конфигурации.







