Інтеграція 1С-Бітрікс з інтернет-еквайрингом БелВЕБ (Білорусь)

Інтеграція 1С-Бітрікс з БелВЕБ: де ламається оплата

Інтеграція 1С-Бітрікс з БелВЕБ найчастіше дає збій не на етапі підключення, а на стику платіжного шлюзу та логіки замовлення. Клієнт переходить на сторінку оплати, банк списує кошти, а Бітрікс не отримує підтвердження — замовлення залишається в статусі «очікує оплати». Гроші пішли, товар не відвантажено, і розбиратися з цим доводиться вручну за випискою.

Перший типовий збій — обрив сесії при поверненні з платіжної сторінки. Якщо користувач закрив вкладку або втратив зв'язок, браузер не передає результат назад, і замовлення зависає.

Лікується це не «доопрацюванням кнопки», а серверним повідомленням від банку: шлюз сам повідомляє систему про успіх або відмову, незалежно від того, чи повернувся покупець на сайт.

Другий — розсинхронізація статусів замовлень Бітрікс. Магазин і банк по-різному трактують проміжні стани: часткова оплата, холд, скасування після списання.

Без явного зіставлення кодів відповіді шлюзу внутрішнім статусам замовлення може «стрибати» між станами або зависнути назавжди.

Третій — повторні повідомлення. Банк має право надіслати підтвердження кілька разів, і без захисту від дублів система зараховує одну оплату двічі або знімає холд раніше часу.

Окремий головний біль — звірка: розбіжність між журналом операцій банку та історією замовлень спливає вже в бухгалтерії.

Розбираємо, як це закривається: серверні повідомлення, явна карта статусів та ідемпотентна обробка — так збій оплати на сайті перестає перетворюватися на втрачені замовлення.

Що дає коректна інтеграція платіжного шлюзу

Коректно зібраний платіжний шлюз змінює не «зручність», а вимірювані показники: частку успішних оплат, час від списання до підтвердження замовлення та кількість ручних розборів у бухгалтерії.

Коли модуль еквайрингу БелВЭБ пов'язаний з оформленням замовлення на рівні статусів, а не «збоку», платіж і замовлення живуть в одному сценарії — це і є різниця між працюючою оплатою та постійними розбирательствами.

Успішність платежів

Оплата падає не на шлюзі, а на стику: клієнт пішов на платіжну сторінку, повернувся, а замовлення в статусі «очікує». Ми обробляємо і редірект, і асинхронне повідомлення від банку, тому підтвердження не залежить від того, чи закрив клієнт вкладку. Частка оплат, що доходять до статусу «оплачено», перестає губитися на поверненнях і таймаутах.

Час підтвердження замовлення

Замовлення переводиться в «оплачено» за фактом підтвердження від банку, а не за поверненням клієнта на сайт. Менеджер бачить оплату в момент, коли вона реально пройшла, — без ручної перевірки виписки та дзвінків клієнту. Для служби доставки це різниця між «збираємо сьогодні» та «уточнюємо завтра».

Подвійне списання та звірка

Клас відмов, який найдорожче коштує репутаційно, — повторне списання при оновленні сторінки або збої мережі. Ідемпотентність за ідентифікатором замовлення та коректна обробка повторних повідомлень прибирають його на рівні логіки, а не «ми потім повернемо».

Звірка транзакцій з випискою банку йде за розкладом: розбіжності спливають як звіт, а не як скарга клієнта через тиждень.

Що це дає в цифрах

Сукупно: частка успішних оплат зростає за рахунок прибраних обривів на поверненні, час підтвердження замовлення скорочується до моменту приходу повідомлення, а ручні звірки замінюються автоматичним звітом.

Бухгалтерія отримує збіжність за кожною транзакцією, підтримка — менше звернень «гроші списалися, замовлення немає».

Способи підключення: платіжний модуль, шлюз, ручна звірка

Спосіб приймання оплати визначається тим, як магазин отримує підтвердження операції та хто відповідає за зіставлення замовлення з платежем.

Для БелВЭБ на практиці застосовують три схеми: готовий платіжний модуль, інтеграцію через платіжний шлюз за протоколом і ручну звірку платежів.

Вибір впливає на швидкість зарахування, обсяг ручних операцій і те, які сценарії повернення та часткової оплати доступні без доопрацювань.

Платіжний модуль закриває більшу частину завдань малого та середнього магазину: він ставиться як розширення, налаштовується через режим оплати в адмінці й сам передає статус у замовлення.

Його слабке місце — прив'язка до типової логіки: якщо у вас нестандартний розрахунок кошика або кілька юросіб на одне замовлення, обробник доведеться адаптувати.

Платіжний шлюз дає більше контролю: підпис запиту, ідемпотентність повторних повідомлень, окрема обробка скасувань і повернень. Це виправдано, коли платежів багато і важлива автоматична звірка.

Ручна звірка залишається робочим варіантом для рідкісних платежів, але при потоці вона перетворюється на вузьке місце — статус замовлення відстає від факту оплати, а розбіжності доводиться шукати вручну.

Як ми впроваджуємо еквайринг: етапи робіт

Роботи йдуть від аудиту поточної схеми оплати до передачі налаштованої системи з підтвердженим тестовим платежем.

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

1. Аудит платежів. Розбираємо, як замовлення, оплата та статус в обліковій системі пов'язані між собою: які реквізити йдуть у платіжний шлюз, де зберігається ідентифікатор транзакції, що відбувається при скасуванні та частковому поверненні. На виході — карта поточного процесу та список місць, де оплата розходиться із замовленням.
2. Проєктування схеми. Визначаємо, який сценарій потрібен: разова оплата, рахунок на юридичну особу, оплата за посиланням або з особистого кабінету. Фіксуємо, які події підтверджують успіх, а які — відмову, і як вони відображаються в замовленні та в обліковій системі.
3. Налаштування еквайрингу. Підключаємо магазин в особистому кабінеті банку, налаштовуємо платіжні методи та сценарії підтвердження. Секретні ключі та параметри з'єднання розміщуємо в захищеному сховищі, а не в коді — при зміні ключа правки не потребують перезбирання сайту.
4. Реалізація та обробка статусів. Пишемо модуль оплати та обробник повідомлень від банку: він приймає результат, звіряє підпис і суму, переводить замовлення в потрібний статус. Повторні та запізнілі повідомлення розпізнаються і не створюють дублів оплат.
5. Тестовий платіж. Проганяємо повний цикл у тестовому контурі банку: успішна оплата, відмова, скасування, повернення. Перевіряємо не лише сам факт списання, а й те, що замовлення, лист клієнту та запис в обліковій системі отримали узгоджений статус.
6. Передача системи. Віддаємо доступи, схему проходження платежу, інструкцію для співробітників щодо розбору спірних операцій та порядок дій при збої. Показуємо, де дивитися журнал операцій і як звірити платіж із замовленням.
7. Супровід після запуску. Перший час стежимо за проходженням платежів і звіркою, потім переходимо на планову підтримку: оновлення модуля, реакція на зміни на боці банку, розбір нетипових випадків.

Такий порядок дає передбачуваний запуск: на момент передачі системи платіжний сценарій уже перевірено на реальних операціях, а не лише на папері. Опишіть вашу схему оплати — повернемося з оцінкою та планом робіт.

Що залишається у замовника після впровадження

Після здачі проєкту у замовника залишається не лише працюючий платіжний модуль, а й повний комплект матеріалів, за яким систему можна розвивати, передавати новому підряднику та проходити перевірки. Нижче — що саме ми фіксуємо в документації та передаємо разом із рішенням.

• Схема потоків платежів — від оформлення замовлення в 1С-Бітрікс до підтвердження оплати та повернення коштів: які події ініціюють запит, де зберігається статус транзакції, як обробляються повторні повідомлення від банку.
• Конфігурація інтеграції — параметри підключення до еквайрингу, налаштування тестового та робочого контурів, перелік використовуваних методів та їхнє призначення, щоб налаштування можна було відтворити під час розгортання в новому середовищі.
• Документація з платежів — опис життєвого циклу замовлення та транзакції, поведінка системи при відмовах і тайм-аутах, правила повторного надсилання та обробки статусів.
• Регламент звірки — порядок зіставлення даних з особистого кабінету банку із замовленнями в системі, періодичність, відповідальні та дії при розбіжностях.
• Інструкція адміністратора — покроковий посібник для співробітників: як перевірити статус платежу, оформити повернення, знайти журнал операцій і куди дивитися при інциденті.
• Матриця помилок і реакцій — типові коди відповідей еквайрингу та що робити в кожному випадку: від повторної спроби до звернення до підтримки банку.
• Журнал змін і точка відкату — що і коли змінювалося в інтеграції, як відкотитися до попередньої робочої конфігурації без втрати даних про платежі.

Такий комплект знімає залежність від конкретного виконавця: будь-який інженер за документацією відновлює логіку інтеграції та продовжує роботу без зворотного проєктування.

Якщо під час експлуатації змінюються тарифи банку або додаються способи оплати, оновлення вноситься в ті самі матеріали — вони залишаються актуальними, а не перетворюються на архів.

Кейс: скорочення завислих замовлень у 4 рази

Клієнт — роздрібний магазин із доставкою по Білорусі, оплата карткою через інтернет-еквайринг БелВЭБ. До проєкту замовлення створювалися в 1С-Бітрікс, а підтвердження оплати надходило окремим файлом-випискою, який оператор розбирав вручну.

Якщо платіж проходив, але виписка затримувалася, замовлення залишалося в статусі «очікує оплати» — і таких завислих накопичувалося до 18% від усіх замовлень за місяць.

Що було до

Оплата й замовлення жили в двох незв'язаних контурах. Успішною вважалася лише та оплата, яку оператор встигав зіставити із замовленням вручну, — за фактом частка успішних оплат трималася на рівні 76%.

Решту розбирали руками: звіряли суму, номер замовлення й час платежу, частину замовлень скасовували, частину повертали клієнту. На розбір ішло 2-3 години на день, а пікові дні продажів перетворювалися на чергу з необроблених платежів.

Що змінили

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

Додали ідемпотентність — повторна відповідь банку не створює дубль платежу, а завислі замовлення йдуть в окрему чергу з автоповтором перевірки статусу. Для оператора залишили лише ті випадки, де банк не дав однозначної відповіді.

Що стало

Частка успішних оплат зросла з 76% до 94%, а кількість завислих замовлень скоротилася у 4 рази. Ручних розборів стало менше на 80% — оператор займається клієнтами, а не звіркою виписок.

Скасування замовлень через «незрозумілий» статус оплати практично зникло, а повернення клієнтам скоротилися пропорційно до кількості завислих замовлень.

Метрики до й після: частка успішних оплат 76% → 94%, завислі замовлення — мінус 75%, ручні розбори — мінус 80%, час на щоденну звірку — з 2-3 годин до 20-30 хвилин.

Чим відрізняється оплата карткою від оплати через ЄРИП?

Оплата карткою та оплата через ЄРИП — це два принципово різних сценарії, і різниця проявляється вже в момент ініціалізації платежу.

Під час оплати карткою покупець не залишає сайт: форма введення даних картки відкривається прямо в інтернет-магазині, банк-еквайр авторизує операцію за секунди, а підтвердження оплати надходить зворотним викликом на сервер і одразу фіксується в замовленні. Статус змінюється синхронно — клієнт бачить успіх, а система вже готова відвантажувати товар.

ЄРИП влаштований інакше. Покупець отримує рахунок з унікальним номером і вирушає оплачувати його в інтернет-банкінг, мобільний застосунок або касу банку. Між оформленням замовлення та фактичним надходженням грошей минає час — від кількох хвилин до кількох годин, а іноді й днів.

Підтвердження оплати надходить не миттєво, а окремим повідомленням із банку, тому замовлення має вміти жити в проміжному статусі «очікує оплати» й коректно переходити в «оплачено» за фактом зарахування.

Повернення платежу теж працює по-різному. Для карткового платежу повернення ініціюється з панелі керування магазином і проходить тим самим каналом, що й оплата, — гроші повертаються на ту саму картку.

У ЄРИП повернення складніше: воно прив'язане до конкретного платіжного документа, і повернути кошти можна лише через банк, оформивши окрему операцію.

Тому в системі важливо зберігати номер платіжного документа та історію його статусів, інакше повернення перетворюється на ручний пошук.

На практиці це означає, що інтеграція 1С-Бітрікс з БелВЕБ має підтримувати обидва сценарії одночасно: синхронне підтвердження оплати карткою та асинхронне звіряння платежів ЄРИП за випискою.

Тільки тоді замовлення не зависають у невизначеному статусі, а бухгалтерія бачить реальну картину надходжень.

Часті технічні питання щодо інтеграції

Інтеграція з еквайрингом майже ніколи не буває «налаштував і забув»: у банку змінюються тарифи, у магазину — сценарії оплати, у бухгалтерії — вимоги до звірки.

Нижче — питання, які найчастіше виникають уже після запуску, і як ми закриваємо їх на рівні конфігурації, а не ручних правок.

Що робити при зміні тарифу або реквізитів у банку?

Тариф, торговий ідентифікатор і набір доступних способів оплати — це параметри, а не код. Ми тримаємо їх у конфігурації модуля та в змінних середовища, тому зміна тарифу зводиться до правки значень і перезапуску обробника, без перезбирання сайту.

Якщо банк змінює формат підпису або склад полів у відповіді, оновлюємо адаптер і проганяємо той самий тестовий набір — регрес займає години, а не дні.

Як влаштовані логи платежів і розбір помилок?

Кожен запит і відповідь пишеться в окремий журнал з ідентифікатором замовлення, сумою, статусом і часом. За ним видно весь ланцюжок: чи пішов запит у банк, що повернулося, на якому кроці замовлення зависло.

Помилки розкладені за класами — мережеві, відмова банку, невідповідність суми, повторна оплата — і за кожною є зрозуміла реакція: автоматичний повтор, ручна звірка або повідомлення відповідальному. Це знімає головний біль підтримки: не потрібно гадати, чи загубився платіж, чи клієнт закрив вікно.

Якщо ваш випадок не потрапив до списку — опишіть задачу, повернемося з оцінкою та планом робіт.

Обговоримо ваше завдання щодо інтеграції 1С-Бітрікс БелВЕБ

Щоб інтеграція 1С-Бітрікс з БелВЕБ пройшла без сюрпризів, нам важливо побачити вашу поточну схему оплати: як оформлюється замовлення, де фіксується статус, хто звіряє надходження з базою.

Опишіть завдання у вільній формі — повернемося з оцінкою робіт і планом впровадження, де кожен етап прив'язаний до результату, а не до абстрактного «налаштуємо оплату».

Що даємо на виході:

• Розбір поточного сценарію оплати та точок, де розривається зв'язок між замовленням і платежем.
• Схему інтеграції 1С-Бітрікс з інтернет-еквайрингом БелВЕБ під ваш каталог, доставку та правила статусів замовлення.
• Оцінку робіт з розбивкою за етапами: налаштування, тестовий контур, виведення в робоче середовище.
• План впровадження з порядком перевірок на кожному кроці та точкою відкату.
• Перелік доопрацювань, якщо частина логіки вже реалізована і її потрібно вбудувати в нову схему.
• Регламент підтримки платежів: як читати журнал операцій, що робити при розбіжності статусу, кому йде повідомлення.
• Домовленості щодо доступів і розподілу зон відповідальності між вашою командою та нашою.

Нам не потрібен готовий технічний документ — достатньо опису процесу: як зараз приймаєте оплату, які способи вже підключені, що не влаштовує. За цим описом наші інженери зберуть оцінку і запропонують послідовність робіт. Обговоримо завдання — і повернемося з конкретним планом, термінами та складом етапів.