Оплата через ЕРИП ламається на етапі підтвердження замовлення
Найчастіше збій проявляється так: клієнт оплачує замовлення через ЕРИП, гроші списуються, а в особистому кабінеті замовлення так і висить у статусі «очікує оплати».
Менеджер бачить неоплачене замовлення, телефонує клієнту, той надсилає чек — і лише тоді з'ясовується, що оплата пройшла.
Причина майже завжди в тому, що інтеграція 1С-Бітрікс з ЕРИП налаштована на прийом платежу, але не на його підтвердження: система не отримує або некоректно обробляє повідомлення банку про статус операції.
Другий типовий збій — дублювання рахунків. При повторному зверненні до оплати (оновлення сторінки, повернення з ЕРИП, повторний клік) система створює новий рахунок на те саме замовлення, і в банк ідуть два платежі з різними номерами.
Клієнт оплачує один, другий залишається висіти, а звірка наприкінці дня не сходиться: бухгалтерія витрачає години на ручний пошук відповідностей між замовленнями та випискою.
Третій збій — втрата повідомлень банку. Якщо обробник підтвердження оплати не відповідає вчасно або падає з помилкою, банк повторює повідомлення, але не безкінечно. Після вичерпання спроб платіж залишається без статусу, і замовлення «застрягає» назавжди.
Тут важлива ідемпотентність: повторне повідомлення з тим самим ідентифікатором не повинно створювати новий платіж або змінювати вже підтверджений статус.
Окрема причина — розсинхронізація між сайтом і обліковою системою. Замовлення оформлюється в 1С-Бітрікс, а фактичний рух грошей фіксується в 1С; якщо обмін іде за розкладом, а не за подією, статус оплати надходить із затримкою і не збігається з реальністю.
Розбираємо, як це закривається: налаштовуємо прийом повідомлень банку, ідемпотентну обробку підтвердження замовлення, синхронізацію статусу оплати та повідомлення менеджеру і клієнту.
Що дає коректна інтеграція 1С-Бітрікс з ЄРИП
Коректна інтеграція 1С-Бітрікс з ЄРИП прибирає головне джерело ручної роботи в інтернет-магазині — розбір платежів «очима».
Коли оплата надходить у систему автоматично, замовлення переходить у статус «оплачено» без участі оператора: частка замовлень, підтверджених без людини, сягає 95–98%, а час зарахування у статусі замовлення скорочується з годин до 1–3 хвилин після підтвердження платежу банком.
Окремий ефект — звірка платежів. Замість вивантаження реєстру з банку та порівняння рядок за рядком із замовленнями система сама пов'язує платіж із номером замовлення за унікальним ідентифікатором.
Бухгалтерія отримує узгоджену картину за кожен день, а розбіжності випливають одразу, а не в кінці місяця, коли клієнт уже забув, що і коли платив.
Статуси замовлень перестають бути ручним полем. Оплата, скасування, повернення та часткова оплата проставляються за фактом події від платіжної системи, а не за дзвінком клієнта.
Це знімає цілий клас помилок: замовлення не йде у збирання без грошей і не висить «очікує оплати» після того, як гроші вже надійшли.
Для замовника інтеграція 1С-Бітрікс з ЄРИП — це передбачуване навантаження на операторів: чим більше замовлень, тим менша частка ручних операцій на кожне. Нижче розбираємо, як це влаштовано і що потрібно для підключення.
Способи підключення оплати ЄРІП: порівняння варіантів
Є три робочі схеми приймання оплати через ЄРІП, і вибір між ними визначається не «модністю», а тим, хто у вас веде облік рахунків і як часто змінюється номенклатура.
Нижче — порівняння за умовами застосовності, а не за ціною: вартість у всіх трьох складається з різного набору робіт, і на старті це не завжди очевидно.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до банку | Власний білінг, стабільний потік рахунків, потрібен повний контроль над статусами та вивантаженням | Договір з банком, власний модуль обміну, доопрацювання при зміні формату вивантаження; заявки на підключення розглядає банк |
| Платіжний агрегатор | Потрібно швидко запустити приймання оплат, немає ресурсу на інтеграцію з банком | Комісія посередника, залежність від його регламентів і строків зарахування, обмежена кастомізація сценарію |
| Ручне вивантаження рахунків | Мала кількість платежів, оплата за виставленими рахунками, разові надходження | Ручна праця, затримка між оплатою та закриттям замовлення, помилки зіставлення при зростанні обсягу |
Пряме підключення
Тут ви самі формуєте рахунок з ідентифікатором у системі «Розрахунок» і отримуєте від банку статус оплати. Це дає повний контроль: можна закривати замовлення автоматично, надсилати повідомлення, будувати звітність за фактичними надходженнями.
Плата за це — договір з банком і модуль обміну, який доведеться супроводжувати при змінах на боці банку.
Агрегатор і ручне вивантаження
Агрегатор знімає роботу з банком і бере обмін на себе: ви інтегруєтеся з однією точкою і отримуєте статуси через його інтерфейс. Обмеження — регламенти посередника та комісія, а також менша гнучкість у нестандартних сценаріях.
Ручне вивантаження рахунків виправдане лише на малих обсягах: воно не масштабується і створює розрив між оплатою та закриттям замовлення.
Розбираємо, який варіант закриває вашу схему обліку без зайвих доопрацювань.
Етапи впровадження оплати ЕРИП у 1С-Бітрікс
Впровадження оплати через ЕРИП торкається не лише сторінки оформлення замовлення, а й обміну з 1С, статусів замовлень і звірки платежів. Тому працюємо за етапами — від розбору поточної схеми до передачі налаштованої системи з регламентами. Нижче — як виглядає процес для замовника.
-
Аудит замовлень і поточної схеми оплати. Дивимося, як формуються замовлення, які статуси використовуються, де зберігаються суми та як дані потрапляють у 1С. Фіксуємо вузькі місця: ручні звірки, дублювання замовлень, розбіжності статусів після оплати.
-
Проєктування сценарію оплати. Визначаємо, на якому кроці покупець переходить у ЕРИП, як повертається на сайт, що відбувається при відмові та повторній спробі. Узгоджуємо логіку статусів: «очікує оплати», «оплачено», «скасовано» — щоб бухгалтерія та склад бачили одне й те саме.
-
Налаштування обміну з 1С. Налаштовуємо вивантаження замовлень, синхронізацію номенклатури та коректну передачу сум. Обмін іде за розкладом і за подіями — замовлення не «зависає» в проміжному стані.
-
Підключення оплати ЕРИП. Інтегруємо платіжний модуль в оформлення замовлення, налаштовуємо формування рахунку та прийом підтверджень про оплату. Перевіряємо, що покупець бачить зрозумілий статус, а система — коректну відмітку.
-
Тестування платежів. Проганяємо сценарії: успішна оплата, відмова, повторна спроба, оплата із затримкою. Звіряємо, що суми, статуси та дані в 1С збігаються на кожному кроці.
-
Передача системи та регламентів. Передаємо налаштовану систему, інструкції для менеджерів і порядок дій при спірних платежах. Показуємо, де дивитися статус і як звірити оплату.
-
Підтримка після запуску. Супроводжуємо перші цикли оплат, відстежуємо розбіжності та коригуємо обмін, якщо змінюються умови або номенклатура.
Такий порядок закриває головний ризик — розбіжність між сайтом, оплатою та обліком. Опишіть вашу схему замовлень і обміну з 1С — повернемося з оцінкою та планом за етапами.
Що замовник отримує після налаштування інтеграції
Інтеграція вважається завершеною не тоді, коли «оплата пройшла», а коли передача результату не залежить від конкретного інженера. Тому фіксуємо все, що потрібно для експлуатації, супроводу та передачі іншій команді.
- Конфігурації обміну: робочі профілі інтеграції 1С-Бітрикс з ЕРИП та обліковою системою, параметри зіставлення номенклатури, ставок і статусів замовлення, налаштування черг повторного надсилання при недоступності шлюзу.
- Схема обміну: карта потоків «кошик → рахунок → підтвердження оплати → закриваючі документи» з точками ідемпотентності, щоб повторний виклик не створював дубль платежу.
- Політики доступу: розмежування прав на платіжні методи та вивантаження, окремі сервісні облікові записи, ротація ключів і правила зберігання логів транзакцій.
- Документація: опис сценаріїв оплати та повернення, перелік кодів помилок ЕРИП з розшифруванням і діями оператора, інструкція для менеджера щодо ручної звірки завислих рахунків.
- Регламенти обслуговування: періодичність звірки оплат з банківською випискою, порядок дій при розбіжності сум, точки контролю після оновлень платформи та модулів.
- Інструменти діагностики: журналювання запитів і відповідей платіжного шлюзу, тестовий контур для прогону сценаріїв оплати та повернення без реальних списань.
- План відкату: порядок повернення до попереднього способу оплати та збереження коректності вже проведених транзакцій.
Кожен пункт передаємо у вигляді, придатному для роботи: конфігурації — у репозиторії, схеми та політики — у вигляді актуальних описів, регламенти — із зазначенням відповідальних ролей. Опишіть вашу задачу — повернемося з оцінкою та планом за складом артефактів.
Кейс: як ми усунули подвійні списання при оплаті через ЄРІП
Клієнт — сервісний провайдер з особистим кабінетом на 1С-Бітрікс — приймав платежі через ЄРІП і вручну розбирал звернення. Проблема проявлялася не постійно, а пачками: при обриві сесії між шлюзом і сайтом покупець бачив помилку, повторював платіж, і обидва списання проходили.
Заявки на повернення накопичувалися, бухгалтерія звіряла виписки ЄРІП із замовленнями вручну, а частина розбіжностей спливала лише при закритті місяця.
Що було до впровадження
Обробник оплати підтверджував замовлення за фактом повернення на сайт, а не за фактом зарахування. Якщо покупець закривав сторінку або втрачав зв'язок, замовлення залишалося неоплаченим, хоча гроші вже пішли.
Повторна спроба створювала другий платіж, і пов'язати їх між собою було нічим — у виписці ЄРІП обидва платежі виглядали як самостійні.
Повернення оформлялися вручну: бухгалтер знаходив платіж, ініціював повернення в системі банку і окремо правив статус замовлення на сайті. На одну операцію йшло до півгодини, а при масових збоях черга розтягувалася на дні.
Що змінили
Ми перевели підтвердження оплати на асинхронну схему: замовлення закривається за повідомленням від платіжного шлюзу, а не за поверненням покупця на сайт. Кожному платежу присвоюється унікальний ідентифікатор, за яким повторна спроба розпізнається і не створює друге списання.
Далі додали автоматичну звірку: регламентне завдання раз на добу зіставляє виписку ЄРІП із замовленнями і позначає розбіжності. Повернення пішли в той самий контур — операція ініціюється з картки замовлення, статус синхронізується з банком і сайтом без ручного втручання.
Що стало
Подвійні списання припинилися: клас відмов, при якому покупець платить двічі, закритий на рівні логіки підтвердження. Звірка займає хвилини замість ручного розбору, а розбіжності видно в перший день, а не при закритті місяця.
Повернення оформляються з інтерфейсу за лічені хвилини, і бухгалтерії більше не потрібно звіряти статуси в двох системах.
Чим відрізняється оплата через ЕРИП від еквайрингу?
Еквайринг — це картковий потік: покупець вводить дані картки, банк-еквайр авторизує операцію онлайн і відповідає в момент оплати.
Гроші при цьому зараховуються не одразу, а розрахунковим циклом, але статус «оплачено» надходить синхронно, і замовлення можна проводити в 1С практично миттєво.
ЕРИП влаштований інакше: це платіжна система з деревом послуг, де кожній послузі відповідає код в ієрархії, а платіж ініціюється на стороні банку або інфокіоску, а не на сайті.
Ключова відмінність — у механіці підтвердження. При еквайрингу сайт сам надсилає запит до банку й отримує відповідь захищеним каналом.
При ЕРИП сайт лише формує рахунок з унікальним номером і кодом послуги, покупець переходить в інтернет-банкінг і платить там, а підтвердження надходить зворотним повідомленням від банку або звірянням реєстру платежів.
Тобто оплата асинхронна: між переходом покупця в банк і статусом «оплачено» на сайті минає час, і замовлення не можна вважати закритим до надходження підтвердження.
Терміни зарахування теж різняться. Еквайринг дає миттєву авторизацію, а зарахування на рахунок — за регламентом банку.
ЕРИП підтверджує факт оплати протягом хвилин, але підсумкове зарахування та звіряння йдуть пакетами, тому інтеграція зобов'язана вміти чекати й повторно перевіряти статус, а не покладатися на одну відповідь.
Вимоги до інтеграції з цього й випливають. Для ЕРИП потрібні реєстрація послуги в дереві, коректний код і номер рахунку, обробник повідомлень від банку та регулярне звіряння реєстру — інакше платежі «зависнуть» без прив'язки до замовлення.
Для еквайрингу достатньо платіжного модуля й обробки колбеку. На практиці багато проєктів тримають обидва способи: еквайринг для швидкої оплати карткою, ЕРИП — для тих, кому зручніше платити через банк.
Часті технічні питання щодо інтеграції оплати
Інтеграція оплати майже ніколи не відбувається «в порожнє поле»: на боці замовника вже працює облікова система, є довідники, документи, ролі. Тому перше питання на старті — не «який модуль поставимо», а «що саме доведеться змінювати у вже розгорнутій системі». Нижче — те, що найчастіше виринає на етапі оцінки.
Що робити, якщо обмін з ЄРІП впав уночі й замовлення «зависли»?
Перший крок — не перезапускати обмін наосліп, а розібрати чергу: які рахунки вже оплачені на боці провайдера, але не підтверджені в нас. Кожне підтвердження ідемпотентне — повторна обробка одного й того самого платежу не створює дубль замовлення.
Якщо збій зачепив вікно обміну, платежі наздоганяються з журналу операцій, а розбіжності зводяться звіркою за номером рахунку. Клієнту при цьому не потрібно нічого робити вручну.
У нас уже розгорнута система на 1С — доведеться її перебудовувати?
Ні. Інтеграція вбудовується в поточний контур: довідники номенклатури, контрагентів і договорів залишаються як є, змінюється лише шар обміну статусами оплати. Ми фіксуємо точки стикування, описуємо формати вивантаження і тільки після цього торкаємося коду.
Якщо облікова база нестандартна, спочатку знімаємо схему потоків даних — інакше будь-яка правка ламає звіти.
Чим погане ручне вивантаження платежів і коли воно все ж допустиме?
Ручне вивантаження не масштабується: за десятків операцій на день з'являються розбіжності, а звірка займає години. Воно виправдане лише на старті або для рідкісних разових платежів, поки не налаштований автоматичний обмін.
Щойно потік зростає, ручний режим перетворюється на джерело помилок — статус оплати надходить із затримкою, а замовлення йдуть у відвантаження раніше за підтвердження.
Які обмеження є в інтеграції і як ви їх закриваєте?
Обмеження задає не платіжний шлюз, а регламент обміну: частота опитування, глибина зберігання історії, права доступу до бази. Ми виносимо ці параметри в конфігурацію, щоб їх можна було змінювати без правки коду.
Окремо описуємо поведінку при недоступності зовнішньої сторони — черга, повторні спроби, повідомлення відповідальному. Так збій обміну залишається інцидентом на моніторингу, а не проблемою бухгалтерії.
Обговоримо ваше завдання щодо інтеграції оплати
Щоб повернутися з оцінкою та планом впровадження, а не із загальними словами, нам потрібна картина вашої поточної схеми: як замовлення потрапляють у 1С, де формуються рахунки, хто звіряє оплати та що відбувається при розбіжності. Чим точніші вхідні дані, тим менше припущень у кошторисі та тим передбачуваніші терміни.
Опишіть завдання — і ми розберемо його по суті. Достатньо відповісти на кілька питань:
- Яка конфігурація 1С використовується і як вона пов'язана із сайтом: обмін через модуль, веб-сервіси чи ручне вивантаження.
- Як зараз приймаються оплати: ЕРИП, еквайринг, готівка — і які статуси замовлення проставляються вручну.
- Де ведеться облік замовлень і номенклатури: в 1С, у Бітрікс24 чи в двох системах паралельно.
- Чи є доопрацювання в типовому обміні та хто їх підтримує — це впливає на обсяг робіт.
- Які звіти потрібні за підсумком: звірка оплат, вивантаження в бухгалтерію, повідомлення менеджерам.
- Чи є обмеження щодо доступів, хостингу та регламенту оновлень.
Після розбору ми повернемося з оцінкою робіт і планом впровадження: етапи, що робимо на кожному, що потрібно від вашої сторони та як перевіримо результат до виведення в робочу експлуатацію. Наступні кроки узгодимо за фактом відповідей — без зайвих ітерацій.