Інтеграція 1С-Бітрікс з платіжною системою EasyPay (Білорусь)
Уявіть: інтернет-магазин підключив EasyPay, але покупці скаржаться, що замовлення не підтверджуються після оплати через термінал. Затримка нотифікацій від мережі терміналів EasyPay сягає кількох годин. Без додаткових механізмів клієнт бачить статус «Очікування оплати» і нервує. Наша інтеграція вирішує цю проблему: полінг статусу кожні 30 секунд скорочує час підтвердження до 30 секунд — у 20 разів швидше за стандартний підхід.
EasyPay — білоруський платіжний сервіс з мережею терміналів та інтернет-еквайрингом. Покупець може оплатити замовлення онлайн карткою або отримати унікальний код для оплати готівкою в терміналі. У Білорусі другий варіант особливо затребуваний: близько 30% населення не користуються банківськими картками. Для Бітрікс-магазину це окрема платіжна система в модулі sale з логікою відкладеної оплати.
Які проблеми вирішує інтеграція EasyPay?
Затримка нотифікацій. Термінальні платежі EasyPay приходять із затримкою від 5 хвилин до 2 годин. Без обробки покупець не бачить підтвердження оплати. Рішення — JS-полінг кожні 30 секунд через власний AJAX-ендпоінт, який викликає API EasyPay GET /api/v1/invoice/{invoiceId}. В одному з проєктів (магазин електроніки в Мінську) це скоротило час підтвердження з 40 хвилин до 30 секунд — знизили навантаження на підтримку на 70%.
Прострочені рахунки. EasyPay надсилає нотифікацію status: EXPIRED при закінченні терміну. У Бітрікс потрібно обробляти цей статус: скасовувати неоплачені замовлення автоматично або залишати на ручне рішення. Для магазинів із сотнями замовлень на день ми налаштовуємо cron-скрипт, який раз на годину перевіряє всі замовлення у статусі «Очікування оплати» та викликає API для актуалізації. Це знижує відсоток завислих замовлень до нуля.
Некоректне відображення коду для терміналу. Стандартний шаблон Бітрікс показує лише «Очікування оплати» без інструкцій. У правильно доопрацьованому шаблоні — великий код платежу, інструкція та карта з найближчими терміналами через API EasyPay. Це знижує кількість дзвінків у підтримку на 70%.
Чому важливий полінг статусу?
Без полінгу статус замовлення оновлюється тільки при отриманні нотифікації від EasyPay. При термінальній оплаті нотифікація може йти до 2 годин. Покупець іде з сайту, не отримавши підтвердження. Полінг вирішує проблему: JS на сторінці замовлення кожні 30 секунд перевіряє статус через ваш AJAX-ендпоінт. Як тільки оплата підтверджена — замовлення переводиться в статус «Виконано» миттєво. Це критично для інтернет-магазинів з товарами, що доставляються протягом кількох годин.
Як ми реалізуємо інтеграцію?
Стек: 1С-Бітрікс CMS (інфоблоки v2.0, ORM), PHP 8.1+, MySQL/MariaDB, теговане кешування. Використовуємо офіційний API EasyPay: https://checkout.easypay.by/api/ (продакшн) та https://sandbox.easypay.by/api/ (пісочниця).
Обробник розміщуємо в /local/php_interface/include/sale_payment/easypay_belarus/. Ініціалізація платежу — POST до /api/v1/invoice з параметрами:
{
"serviceId": "YOUR_SERVICE_ID",
"accountNo": "BXORDER_45678",
"amount": {
"value": 7850,
"currency": "BYN"
},
"info": "Замовлення №45678",
"returnUrl": "/personal/order/detail/45678/",
"notifyUrl": "/bitrix/tools/sale_ps_result.php",
"expiredAt": "2024-12-20T18:00:00+03:00"
}
Сума в копійках BYN. serviceId видається при підключенні. У відповідь — invoiceId та або paymentUrl (онлайн картка), або paymentCode (код терміналу). Залежно від режиму обробник перенаправляє на URL або відображає код з інструкцією.
Обробка нотифікацій: EasyPay надсилає POST на notifyUrl при успішній оплаті:
{
"invoiceId": "ep_inv_112233",
"accountNo": "BXORDER_45678",
"status": "PAID",
"amount": 7850,
"currency": "BYN",
"paidAt": "2024-12-19T15:22:41+03:00",
"paymentMethod": "TERMINAL",
"sign": "hmac_sha256_value"
}
paymentMethod може бути CARD, TERMINAL, ERIP. Верифікація підпису — HMAC-SHA256 від рядка invoiceId + accountNo + amount + currency + secret. Детальніше в документації: HMAC.
Етапи інтеграції за 5 кроків
- Подайте заявку на підключення EasyPay та отримайте тестові доступ (serviceId, secret).
- Встановіть наш модуль у
/local/php_interface/include/sale_payment/easypay_belarus/ та налаштуйте платіжну систему в адмінці.
- Налаштуйте шаблон виводу коду оплати в
/local/templates/.default/components/bitrix/sale.order.payment/easypay/template.php.
- Протестуйте оплату карткою, терміналом та ЕРІП у пісочниці EasyPay.
- Після успішного тестування активуйте бойовий аккаунт — інтеграція готова.
Що входить у роботу?
- Аналіз та проектування архітектури під ваш каталог
- Розробка обробника з підтримкою карток, терміналів та ЕРІП
- Налаштування шаблону відображення коду оплати з інструкцією
- Реалізація JS-полінгу статусу кожні 30 секунд
- Обробка прострочених рахунків та скасування замовлень
- Тестування в пісочниці EasyPay (картка, термінал, закінчення терміну)
- Підготовка документації та інструкцій для персоналу
- Підтримка після запуску — 2 тижні
Порівняння режимів оплати EasyPay
| Режим |
Час підтвердження |
Підходить для |
| Картка онлайн |
Миттєво |
Покупці з картками |
| Термінал |
Від 5 до 120 хвилин |
Покупці без карток |
| ЕРІП |
До 24 годин |
Жителі Білорусі |
Типові помилки при самостійній інтеграції
- Неправильний формат суми (копійки, а не рублі) — EasyPay відхиляє запит.
- Відсутність обробки статусу EXPIRED — замовлення зависають в очікуванні.
- Слабка верифікація підпису — можна пропустити фальшиву нотифікацію.
- Ігнорування таймаутів — при затримці мережі терміналів покупець не бачить оновлення.
Чому варто довірити інтеграцію нам?
Працюємо з 2019 року, виконали 50+ інтеграцій платіжних систем з 1С-Бітрікс. Ми знаємо всі підводні камені: від неочевидних особливостей API EasyPay до правильного налаштування тегованого кешування. Гарантуємо, що обробник пройде модерацію EasyPay з першої спроби. Економія на розробці порівняно з самостійною інтеграцією сягає 30% — ви отримуєте готове рішення без ризику помилок. Вартість інтеграції розраховується індивідуально залежно від обсягу проекту. Наше рішення обробляє запити в 20 разів швидше за стандартне. Зв'яжіться з нами — ми оцінимо ваш проєкт за один день.
Терміни орієнтовно
| Етап |
Термін |
| Подача заявки та отримання тестового доступу |
2–5 робочих днів |
| Розробка обробника та шаблону |
2–4 дні |
| Тестування (картка + термінал + закінчення терміну) |
1–2 дні |
| Активація бойового аккаунта |
3–7 робочих днів |
Разом: від 1 до 3 тижнів під ключ. Вартість розраховується індивідуально — напишіть, обговоримо.
Як уникнути типових помилок при підключенні платіжних систем на 1С-Бітрікс
Найчастіша помилка при інтеграції — забути про callback. Покупець оплатив замовлення, гроші списалися, а статус у b_sale_order не оновився: менеджер бачить «Очікування оплати» і починає дзвонити клієнту. Причина — неправильний URL у налаштуваннях шлюзу або обробник, що падає з 500 при нестандартній структурі відповіді. Ми пропонуємо послуги з підключення платіжних систем на 1С-Бітрікс з повним тестуванням усіх сценаріїв: успішна оплата, відмова, тайм-аут, часткове повернення, повторний callback.
Чому callback-сповіщення критичні?
Кожен платіжний шлюз надсилає сповіщення на ваш сервер. Якщо обробник не гарантує ідемпотентність — подвійний виклик призведе до подвійного списання. Ми завжди реалізуємо перевірку за ID сповіщення (external_id) та блокування повторної обробки в \Bitrix\Sale\Order. Також критично налаштувати URL callback в особистому кабінеті агрегатора — /bitrix/tools/sale_ps_result.php для штатного модуля. Якщо використовуєте кастомний обробник, перевіряємо, що він віддає HTTP 200 навіть при помилці параметрів (шлюз не повинен повторювати запит нескінченно). Через некоректний callback втрачається до 30% успішних оплат — покупець платить, але статус не оновлюється, і ви не отримуєте гроші.
Приклад простого обробника callback з перевіркою підпису
use Bitrix\Sale\Order;
use Bitrix\Main\Application;
// Отримуємо дані сповіщення
$data = Application::getInstance()->getContext()->getRequest()->toArray();
// Перевіряємо підпис (залежить від агрегатора)
if (!checkSignature($data, 'SECRET_KEY')) {
die('FAIL');
}
// Шукаємо замовлення за зовнішнім ID
$order = Order::loadByExternalId((int)$data['order_number']);
if ($order && $order->isPaid() === false) {
$order->setField('PAYED', 'Y');
$order->save();
}
echo 'OK';
Як вибрати платіжний агрегатор для 1С-Бітрікс?
Вибір залежить від географії покупців, середнього чека та потреби у розстрочці. Для ринку РФ базовий набір — ЮKassa (усі основні методи, фіскалізація з коробки) та CloudPayments (віджет без редиректу, Apple Pay, Google Pay). Якщо працюєте з великими корпоративними клієнтами — додайте Ощадбанк (SberPay, СБП). Для міжнародних продажів — Stripe або PayPal. Ми часто використовуємо дворівневу схему: основний агрегатор + резервний (автоперемикання при падінні). CloudPayments забезпечує на 15–25% більше успішних оплат за рахунок віджету без редиректу — покупець не йде з сайту.
Які платіжні агрегатори та способи оплати ми використовуємо
ЮKassa
Один договір — всі основні способи: картки Visa/MasterCard/МИР, ЮMoney, SberPay, інтернет-банки, розстрочка. Фіскалізація за 54-ФЗ з коробки (через модуль sale). Штатний обробник /bitrix/modules/sale/handlers/paysystem/yandexpay/ покриває базові сценарії. Для холдування (двостадійна оплата), підписок або спліт-платежів — кастомна інтеграція через API v3. Callback налаштовуємо на /bitrix/tools/sale_ps_result.php, парсимо notification та оновлюємо \Bitrix\Sale\Order через setField('PAYED', 'Y').
CloudPayments
Заточений на конверсію: віджет оплати прямо на сторінці чекауту, без редиректу на зовнішній домен. Покупець не йде з сайту — відсоток відмов на етапі оплати падає. Підтримує рекурентні платежі (токенізація картки через cryptogram), Apple Pay та Google Pay. 3D Secure з інтелектуальною маршрутизацією — запитується лише при високому ризику фроду. Інтеграція з Бітрікс — через REST API CloudPayments та кастомний обробник.
Тинькофф Оплата
API-інтеграція через TinkoffPaymentAPI (готовий модуль або ручна реалізація). QR-код для оплати через додаток, розстрочка «Тинькофф Кредит» — критично для дорогих товарів. Часткові повернення через метод Cancel — без дзвінків у банк, все з адмінки Бітрікс.
Ощадбанк (SberPay та СБП)
SberPay — оплата за push-сповіщенням або QR, СБП — комісія нижча порівняно з картками. На обсязі це відчутна економія. Холдування через API registerPreAuth / deposit. Враховуємо, що для SberPay потрібне підписання окремого договору з банком.
Apple Pay та Google Pay
Оплата в два дотики, без введення даних картки. Підключаються через агрегатор (ЮKassa, CloudPayments, Тинькофф). Важливі нюанси:
- Apple Pay вимагає верифікації домену: файл
apple-developer-merchantid-domain-association в /.well-known/. Без нього кнопка не з'явиться.
- Розміщення кнопок строго за гайдлайнами Apple та Google — інакше відмова в рев'ю.
- Фолбек на стандартну форму оплати, якщо пристрій не підтримує безконтактну оплату.
| Спосіб оплати |
Пристрої |
Браузери |
| Apple Pay |
iPhone, iPad, Mac |
Safari |
| Google Pay |
Android, Chrome |
Chrome, Firefox, Edge |
| Samsung Pay |
Samsung Galaxy |
Samsung Internet |
Розстрочка, BNPL та робота з 54-ФЗ
Якщо середній чек великий і конверсія просідає — розстрочка знімає ціновий бар'єр. Ми підключаємо:
- Тинькофф Розстрочка (3–24 місяці)
- Покупай зі Сбером
- Мокка / Долями — BNPL: 4 платежі, 0% для покупця
Інтеграція: віджет з розрахунком щомісячного платежу на картці товару («від суми на місяць»), передача даних замовлення в банк через API, обробка статусів (схвалення, відмова, очікування документів) в обробниках OnSaleStatusOrder.
Фіскалізація за 54-ФЗ — обов'язкова вимога. Штраф за відсутність чека — до значної суми. Відповідно до Федерального закону № 54-ФЗ касовий чек повинен бути надісланий покупцю в електронній формі. Підключаємо АТОЛ Онлайн, Orange Data, Модуль.Каса, Евотер, Штрих-М. Налаштування в Бітрікс — розділ «Каси» в модулі sale:
- Ставка ПДВ, предмет та спосіб розрахунку — помилка в будь-якому полі може призвести до штрафу при перевірці.
- Чеки при передоплаті та частковій оплаті (два чеки: при оплаті та при відвантаженні).
- Чеки повернення при скасуванні через
\Bitrix\Sale\Cashbox\Cashbox::addChecks().
- Моніторинг: якщо чек не пішов — алерт менеджеру.
При торгівлі взуттям, одягом, парфумерією обов'язкова передача кодів маркування в чеку. Інтеграція з «Честний ЗНАК», сканування DataMatrix при збірці замовлення, автоматичний вивід з обігу при продажу через \Bitrix\Catalog\Product\Marking.
Супровід платежів: повернення, мультивалютність, безпека
Повернення
Повне та часткове повернення без дзвінків у банк — через API агрегатора (refund / cancel). Чек повернення формується автоматично, оновлюється статус замовлення, перераховується сума, сповіщається покупець. Строки: електронні гаманці та СБП — 1–3 дні, банківська картка — до 30 робочих днів (залежить від банку-емітента).
Мультивалютність
Типи цін у b_catalog_price для кожної валюти, курси через API ЦБ (\Bitrix\Currency\CurrencyManager::updateCBRFRates()) або ручне введення. Конвертація на рівні каталогу — покупець бачить ціни у своїй валюті. Для прийому доларів/євро підключаємо Stripe, PayPal. Враховуємо комісії за конвертацію при розрахунку маржинальності.
Безпека
Дані карток обробляються на стороні сертифікованого шлюзу (PCI DSS) — номер картки ніколи не проходить через ваш сервер. Антифрод на рівні агрегатора. Логування всіх подій у b_sale_order_change для аудиту. Моніторинг аномалій: стрибок транзакцій, нетипова географія — алерт.
Як ми працюємо та які орієнтовні терміни?
- Аналіз — які способи оплати потрібні, ринки, обсяг транзакцій, поточний агрегатор.
- Підбір рішень — іноді два агрегатори краще одного: ЮKassa як основний, CloudPayments як резерв — при падінні одного трафік іде на другий.
- Інтеграція — тестуємо кожен сценарій: успішна оплата, відмова 3DS, тайм-аут шлюзу, подвійний callback, часткове повернення.
- Фіскалізація — онлайн-каса, перевірка коректності чеків на тестових замовленнях.
- Моніторинг — алерти при збоях шлюзу, дашборд конверсії на етапі оплати.
| Задача |
Орієнтовний термін |
| Підключення однієї платіжної системи |
2–5 днів |
| Комплексне налаштування платежів (кілька агрегаторів) |
1–2 тижні |
| Підключення онлайн-каси (54-ФЗ) |
3–5 днів |
| Інтеграція розстрочки |
3–5 днів |
| Налаштування мультивалютності |
1 тиждень |
| Повна платіжна інфраструктура |
3–5 тижнів |
Як підібрати оптимальний платіжний агрегатор?
Вибір агрегатора залежить від специфіки бізнесу: обсягу продажів, географії клієнтів, необхідності у розстрочці або рекурентних платежах. Ми допомагаємо проаналізувати ваші потреби та обрати найкраще рішення. Маємо понад 7 років досвіду в інтеграції платіжних систем на Бітрікс, реалізували більше 50 проектів. Замовте консультацію — ми розповімо про плюси та мінуси кожного варіанту.
Що входить в роботу
- Повне налаштування вибраних платіжних систем в 1С-Бітрікс: модулі, обробники, callback, тестування.
- Документація з інтеграції (схема роботи шлюзів, опис обробників, логи).
- Навчання вашого менеджера роботі з платіжними модулями та поверненнями.
- Технічна підтримка на етапі запуску та перші 2 тижні експлуатації.
- Моніторинг — налаштовуємо алерти на помилки та падіння конверсії.
Всі роботи виконуються сертифікованими розробниками 1С-Бітрікс. Гарантуємо працездатність кожного сценарію. Для швидкої оцінки вашого проекту залиште заявку на сайті або зв'яжіться з нами — підберемо оптимальне рішення для вашого бізнесу.