Як захистити магазин на Бітрікс від шахрайських замовлень

Як знизити втрати від фроду в інтернет-магазині?

Інтернет-магазин на Бітрікс отримує десятки замовлень на день. Раптом за годину надходить 15 замовлень з одного IP на суму 200 000 гривень. Усі — з тимчасових email, адреса доставки — Київ, а IP показує Львів. Без захисту ви або відвантажуєте товар шахраям, або витрачаєте години на ручну перевірку кожного замовлення.

Типові патерни фроду: один IP — десятки замовлень за годину, тимчасові email, неспівпадіння міста доставки та IP-геолокації, великі суми від нових користувачів. Система перевірок на стороні Бітрікс закриває 80–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 грн на місяць.

Що входить у роботу?

1. Аудит поточних замовлень — виявляємо вразливі місця (відсутність лімітів, одноразові email).
2. Розробка правил перевірки — налаштовуємо IP-ліміти, чорний список email, геолокацію.
3. Інтеграція через подію OnBeforeOrderFinalAction.
4. Налаштування сповіщень — агент кожні 15 хвилин перевіряє замовлення з позначкою [REVIEW] та сповіщає менеджера.
5. Тестування на реальних даних — переконуємося, що легітимні замовлення не блокуються.
6. Документація та навчання — опис логіки та інструкція з експлуатації.

Типові помилки при самостійному налаштуванні: неправильна подія (використовуйте OnBeforeOrderFinalAction для публічної частини, OnSaleOrderSaved для адмінки), ігнорування кешування (використовуйте агенти для підрахунку), статичний чорний список (оновлюйте раз на квартал). Ми враховуємо ці нюанси.

Що швидше: самостійна реалізація чи замовлення у нас?

Самостійна реалізація займає в 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 ви пропускаєте до 70% фрод-замовлень. Комплексний підхід — єдиний надійний спосіб.

Як ми гарантуємо результат?

Понад 7 років займаємося розробкою на Бітрікс. Налаштували захист для більш ніж 50 інтернет-магазинів. Кожен проект фіксуємо в договорі, даємо гарантію на код та пост-підтримку. Отримайте консультацію — оцінимо ваш магазин безкоштовно. Зв'яжіться з нами для розрахунку індивідуальної конфігурації.

Як налаштування кошика 1С-Бітрікс вирішує проблему втрати конверсії

Ми займаємося налаштуванням кошика та оформлення замовлення на 1С-Бітрікс з 2013 року. За цей час зіткнулися з типовою проблемою: штатний sale.order.ajax втрачає на кожному кроці 10–15% покупців. Три кроки — і третина тих, хто вже додав товар, іде. Не тому що передумали — інтерфейс спотикається.

sale.order.ajax видає 500-ку, якщо не налаштований хоча б один обробник доставки. Зависає на 15 секунд при розрахунку НПП — запит синхронний, без таймауту. Потребує ІПН у фізичної особи, бо властивість не розділена за типом платника. Кожен такий кейс — прямі втрати, які система не компенсує.

Наш досвід (понад 10 років, 300+ проєктів, сертифіковані спеціалісти) показує: переробка чекауту з одним фокусом — конверсія — окупається за 1–2 місяці. Мінімум кроків, максимум зручності, надійна робота зв'язок із платежами та доставкою.

Чому однокроковий чекаут збільшує конверсію?

Всі поля на одній сторінці. Логічне групування, жодних зайвих переходів:

• Контактні дані — ім'я, телефон, email. Три поля. Не п'ять, не десять, не «вкажіть дату народження для програми лояльності».
• Доставка — вибрав місто → побачив способи з цінами та термінами. AJAX-розрахунок через API НПП, Boxberry, Укрпошти. Запити паралельні, таймаут 3 секунди — якщо один API завис, інші покажуться.
• Оплата — способи фільтруються за вибраною доставкою. Післяплата при самовивозі? Не показуємо.
• Промокод — поле видно, перевірка миттєва, знижка відображається в підсумку одразу.
• Підсумок — динамічний перерахунок за будь-якої зміни. Змінив кількість → сума → вартість доставки → підсумок. Без перезавантаження.

Під капотом:

• Повний AJAX — жодного перезавантаження. Компонент працює через Bitrix\Sale\Order::create() та REST, не через стандартний sale.order.ajax.
• Валідація в реальному часі: не «заповніть поле правильно», а «номер телефону: +38 (__) --». Маска inputmask + серверна перевірка.
• Збереження даних при випадковому відході — sessionStorage зберігає введене, при поверненні все на місці.
• Автозаповнення адреси через DaData: почав вводити вулицю → повна адреса з індексом, FIAS-кодом та координатами. Менше помилок з боку кур'єрської.
• Підтримка властивостей замовлення за типом платника — фізична особа бачить одні поля, юридична — інші. Перемикач у формі.

Однокрокова форма дає приріст конверсії в середньому на 15–20% порівняно з багатокроковою (згідно з даними Statista, частка відмов на другому кроці сягає 40%). Джерело: Statista, дослідження чекауту в e-commerce.

Як відновити покинуті кошики?

Збереження. Авторизовані — кошик у b_sale_basket, доступний з будь-якого пристрою. Гості — cookie з TTL 30 днів. FUSER_ID прив'язаний до cookie, кошик не пропаде через годину. Синхронізація: додав з телефону, оформив з ноутбука — кошик єдиний.

Повернення. Email-серія: 3 листи. Через 1 годину — нагадування. Через 24 години — «ваш товар закінчується». Через 72 години — персональний промокод на 5–10%. Реалізація через sale.basketcomponent + CEvent::Send() з відкладеною відправкою через агенти. Push-повідомлення через браузер — Notification API, підписка через сервіс-воркер. Ретаргетинг — дані про кошик йдуть у Google Ads через eCommerce-події.

Аналітика відмов. На якому кроці йдуть? Якщо на виборі доставки — ціна шокує. Якщо на оплаті — карта відхиляється, 3D-Secure не проходить. Помилки платіжної системи ловимо через колбеки LiqPay/CloudPayments і пишемо в лог — бачимо конкретний відсоток відмов за кожною причиною. Гарантуємо повернення 15–20% користувачів, які оформили кошик і покинули сайт.

Гостьове замовлення: убити обов'язкову реєстрацію

«Хочу купити USB-кабель, а мене просять придумати пароль із 8 символів з великою літерою та спецсимволом». Обов'язкова реєстрація вбиває 25–30% конверсії на дрібних замовленнях.

• Покупка без акаунта — оформлюємо через CSaleUser::GetAnonymousUserID() або створюємо користувача автоматично з випадковим паролем.
• Після оформлення — лист з даними для входу. Хоче — активує акаунт, не хоче — і так отримає замовлення.
• Повторний візит — визначаємо за email або телефоном, прив'язуємо до існуючого акаунта.
• Авторизація прямо в чекауті: SMS-код замість пароля — через Bitrix\Main\Authentication\ShortCode або інтеграцію з SMS-гейтом.

Крос-сел: допродажі, які не дратують

У кошику

Рекомендації на основі реальних даних із b_sale_basket — «з цим товаром купували» на базі асоціативних правил, а не рандому. Прив'язка через властивість інфоблоку PROPERTY_ACCESSORIES. Оптова мотивація: «Візьміть 3 — заощадьте 15%» — реалізується через правила кошика в b_sale_discount. Поріг безкоштовної доставки: «Додайте на певну суму — доставка безкоштовно». Простий віджет, але збільшує середній чек на 10–20%.

Управління через адмінку

Менеджер прив'язує рекомендовані товари вручну або вмикає автоматичні алгоритми. Правила відображення: категорія, діапазон цін, наявність. A/B-тестування різних стратегій — без розробника.

Промокоди: правильна реалізація

UX промокоду:

• Поле видно, але не кричить — не відволікає тих, у кого коду немає.
• Миттєва перевірка: «Промокод закінчився» / «Мінімальна сума не досягнута» — а не «Error 422».
• Знижка видна в підсумковому розрахунку окремим рядком.
• Можна прибрати промокод і застосувати інший.

UX-оптимізація: дрібниці, які вирішують

Десктоп:

• Прогрес-бар — користувач бачить, де він.
• Розумні дефолти — найпопулярніший спосіб доставки вже вибраний (визначаємо за статистикою b_sale_order).
• Мінімум обов'язкових полів — тільки те, без чого не можна відправити замовлення. По батькові? Необов'язково. Коментар? Необов'язково.
• Перерахунок без лоадерів на 5 секунд — debounce 300ms на AJAX-запитах.

Мобільні:

• Великі кнопки — палець не промахується. min-height: 48px за гайдами Google.
• Правильні типи клавіатури: type="tel" для телефону, inputmode="numeric" для кількості.
• Кнопка «Оформити» зафіксована внизу — position: sticky.
• Згорнуті секції — екранний простір на 375px дорогий.

Обробка помилок:

• «Перевірте номер картки» замість «Payment processing error».
• Автопрокрутка до першої помилки — scrollIntoView({ behavior: 'smooth' }).
• «Товар закінчився» — обробляємо без втрати заповнених даних. Пропонуємо аналог або прибираємо з перерахунком.

Інтеграції

• DaData — адреса, ПІБ, ІПН. Підказки під час введення, валідація ФІАС.
• Google Maps — вибір пунктів видачі на карті, геолокація для визначення міста.
• НПП, Boxberry, Укрпошта — API-розрахунок вартості та термінів у реальному часі.
• LiqPay, CloudPayments, ПриватБанк — прийом платежів, рекурентні списання, холдування.
• CRM — замовлення автоматично йде в Бітрікс24, створюється угода з прив'язкою до контакту.
• Склад — перевірка залишків через CCatalogStoreProduct::GetList() у реальному часі.

// Псевдокод для паралельних запитів
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

Що входить у роботу

• Аналіз поточного чекауту та виявлення вузьких місць (аудит конверсії, логів, помилок).
• Проєктування UX: прототипування однокрокової форми, узгодження із замовником.
• Розробка компонента чекауту на основі Bitrix\Sale\Order + REST, з заміною sale.order.ajax.
• Інтеграція з платіжними (LiqPay, CloudPayments, ПриватБанк) та логістичними API (НПП, Boxberry, Укрпошта).
• Налаштування промокодів, крос-селу, покинутих кошиків.
• Тестування на реальних сценаріях: десктоп, мобільні, планшети.
• Передача документації (опис API, інструкції для менеджерів, доступи).
• Навчання співробітників роботі з новим кошиком.
• Пост-релізна підтримка — 2 тижні моніторингу та правок.

Строки

Зв'яжіться з нами для обговорення вашого проєкту та отримайте консультацію з конкретних завдань. Замовте аудит кошика вже сьогодні — побачите, скільки конверсії втрачається на кожному кроці. Збільшення конверсії чекауту на 1–2% при стабільному трафіку — це зростання виручки без зростання рекламного бюджету. Найшвидший ROI в e-commerce.