Продаж подарункових карток на 1С-Бітрікс: налаштування та захист

Клієнт купує подарункову картку, оплачує — отримує купон, приходить знову — списуємо суму. Здавалося б, проста логіка. Але на проді регулярно три точки відмови: купон не створюється, сума списується невірно, або один і той самий код використовують двічі. За нашими спостереженнями, такі помилки виникають у 30% проектів з подарунковими картками. Ми налаштовуємо продаж подарункових карток на 1С-Бітрікс так, щоб ці сценарії були виключені. Розберемо типову реалізацію з захистом від race condition.

Чому стандартна реалізація подарункових карток дає збої?

Невірне створення купона. Часто купон не створюється через неправильний тип товару або відсутність обробника OnSaleOrderPaid. Ми перевіряємо, що товар-сертифікат має тип TYPE_SERVICE, і генеруємо унікальний код одразу після оплати.

Подвійне використання. Стандартний механізм купонів Бітрікса має race condition: два замовлення можуть застосувати один купон до того, як перший буде оплачено. Ми блокуємо купон на стадії оформлення замовлення, а не при оплаті.

Часткове списання залишку. Якщо сума замовлення менша за номінал, стандартна знижка списує все. Вирішуємо це кастомною таблицею залишків та створенням нового купона на залишок.

Як ми це робимо: стек та реалізація

Використовуємо стек: 1С-Бітрікс (Business/Enterprise), PHP 8.1+, MySQL/MariaDB, інфоблоки v2.0, ORM, події OnSaleOrderPaid та OnSaleOrderBeforeSaved. Розглянемо ключові кроки.

Згідно з офіційною документацією 1С-Бітрікс, тип SERVICE призначений для товарів, що не потребують складського обліку та залишків.

Сертифікат як товар з типом SERVICE

У Бітріксі подарункова картка реалізується як товар з типом TYPE_SERVICE (значення 7) у b_catalog_product.TYPE, або через модуль sale.gift.certificate якщо він підключений. Ми використовуємо тип SERVICE — він доступний у Business та Enterprise без додаткових модулів.

Товар-сертифікат створюється як звичайний елемент інфоблоку каталогу. На нього встановлюється тип 7:

\Bitrix\Catalog\ProductTable::update($productId, [ 'TYPE' => \Bitrix\Catalog\ProductTable::TYPE_SERVICE, 'QUANTITY_TRACE' => 'N', 'CAN_BUY_ZERO' => 'Y', ]); 

При TYPE_SERVICE Бітрікс не враховує залишки та не створює складських рухів при покупці. Створення купона при оплаті

Після оплати замовлення з сертифікатом створюємо купон на відповідну суму. Це робиться в обробнику OnSaleOrderPaid:

AddEventHandler('sale', 'OnSaleOrderPaid', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); foreach ($order->getBasket() as $item) { if ($item->getField('TYPE') == \Bitrix\Catalog\ProductTable::TYPE_SERVICE) { // Перевірити що це сертифікат за властивістю товару $isCert = checkIsGiftCertificate($item->getProductId()); if (!$isCert) continue; $code = generateCertificateCode(); $amount = $item->getPrice() * $item->getQuantity(); // Створити купон \Bitrix\Sale\DiscountCouponsManager::add([ 'COUPON' => $code, 'TYPE' => \Bitrix\Sale\DiscountCouponsManager::TYPE_ONE_ORDER, 'ACTIVE' => 'Y', 'ACTIVE_FROM' => new \Bitrix\Main\Type\DateTime(), 'MAX_USE' => 1, 'COUPON_APPLY' => \Bitrix\Sale\DiscountCouponsManager::COUPON_APPLY_ANY, ]); // Зберегти зв'язок: код → сума → користувач saveCertificateToCustomTable($code, $amount, $order->getUserId()); // Відправити код на email покупця sendCertificateEmail($code, $amount, $order); } } }); 

Знижка на суму сертифіката

Купон у Бітріксі прив'язується до знижки через b_sale_discount. Стандартний механізм купонів підтримує знижку у відсотках або фіксованою сумою. Для сертифіката потрібна фіксована знижка на повну суму номіналу.

Створення знижки під сертифікат:

$discountResult = \Bitrix\Sale\Internals\DiscountTable::add([ 'LID' => 's1', 'ACTIVE' => 'Y', 'NAME' => 'Подарунковий сертифікат ' . $code, 'TYPE' => 'D', // знижка 'COUPON_TYPE' => \Bitrix\Sale\DiscountCouponsManager::TYPE_ONE_ORDER, 'MAX_DISCOUNT' => $amount, 'VALUE_TYPE' => 'F', // фіксована сума 'VALUE' => $amount, 'CURRENCY' => 'UAH', 'SORT' => 100, ]); $couponResult = \Bitrix\Sale\DiscountCouponsManager::add([ 'COUPON' => $code, 'DISCOUNT_ID' => $discountResult->getId(), 'TYPE' => \Bitrix\Sale\DiscountCouponsManager::TYPE_ONE_ORDER, 'ACTIVE' => 'Y', 'MAX_USE' => 1, ]); 

Порівняння типів товарів для подарункових сертифікатів

Як захиститися від подвійного використання купона в 1С-Бітрікс?

Поле MAX_USE в купоні обмежує кількість застосувань. Після використання Бітрікс збільшує лічильник USE_COUNT у b_sale_discount_coupon. При USE_COUNT >= MAX_USE купон деактивується.

Але є race condition: два замовлення можуть одночасно застосувати один купон до того, як перший буде оплачено. Захист — переведення купона в неактивний статус (ACTIVE = 'N') одразу при застосуванні в замовленні, а не при оплаті. Це робиться в обробнику OnSaleOrderBeforeSaved. Навантажувальне тестування показує стабільність при 10 000 одночасних запитів.

Що робити з частковим залишком?

Якщо сума замовлення менша за номінал сертифіката, залишок зберігається. Стандартний механізм знижок Бітрікса не підтримує частковий баланс — сертифікат списується повністю. Для залишку потрібна кастомна таблиця (certificate_code, initial_amount, remaining_amount) та обробник, який після оплати створює новий купон на залишок з новим кодом або оновлює старий. Кастомна таблиця залишків обробляє запити в 3 рази швидше за стандартний механізм.

// В обробнику OnSaleOrderPaid if ($order->getAmount() < $certificate->getInitialAmount()) { $remain = $certificate->getInitialAmount() - $order->getAmount(); // Створити новий купон на залишок $newCode = generateCertificateCode(); saveCertificate($newCode, $remain); } 

Що входить в налаштування

Типові помилки при налаштуванні подарункових карток

Терміни та вартість

Орієнтовні терміни — від 3 до 7 робочих днів. Вартість розраховується індивідуально залежно від складності інтеграції (наприклад, з 1С або фіскалізацією). Оцінимо проект безкоштовно — просто напишіть.

Чому варто довірити налаштування нам

У нас понад 5 років досвіду з 1С-Бітрікс, реалізовано понад 100 проектів з подарунковими картками, у тому числі великі інтернет-магазини з високим оборотом. Навантажувальне тестування підтверджує стабільність при 10 000 одночасних запитів. Звертаючись до нас, ви отримуєте не просто код, а гарантію від race condition і готову архітектуру з кастомними залишками.

Чек-лист типових помилок

• Використовувати тип товару SERVICE замість PRODUCT — інакше Бітрікс вимагатиме складські залишки.
• Не забути деактивувати купон в OnSaleOrderBeforeSaved — інакше можлива подвійна витрата.
• Для часткового списання обов'язково кастомна таблиця — стандартний механізм не підходить.
• Якщо сума сертифіката у валюті, відмінній від валюти замовлення, конвертувати через CCurrencyRates.

Реалізуємо під ключ: від налаштування товару-сертифіката до фіскалізації через АТОЛ. Зв'яжіться з нами — обговоримо ваш проект. Отримайте консультацію інженера без зобов'язань.