Інтеграція криптоплатежів у 1С-Битрикс: де губляться замовлення
Замовлення оформлено, покупець надіслав криптовалюту й бачить підтвердження в мережі — а в магазині воно досі «очікує оплати». Товар не зарезервовано, лист не надіслано, менеджер дізнається про проблему від самого клієнта.
Замовлення не переведено в оплачені — і це не косметика статусу: розсипається резерв, відвантаження й звірка з обліковою системою.
Причина майже завжди одна: приймання криптовалюти на сайті — асинхронний контур. Факт підтвердження в мережі й повідомлення, яке платіжний сервіс надсилає магазину, — дві різні події: між ними є затримка, а обробник може бути недоступним.
Якщо вебхук загубився, а повторної перевірки статусу немає, транзакція залишається в підвішеному стані.
Завислі транзакції накопичуються тихо. Частина клієнтів іде, не дочекавшись, частина пише в підтримку — і кожне таке листування забирає час інженера та довіру.
Окремий біль — розбіжність: у мережі оплата пройшла, в обліку її немає, і закривати період доводиться вручну, за виписками з мережі.
Інтеграція криптоплатежів у 1С-Битрикс закривається не кнопкою «підключити», а схемою: зіставлення замовлення й платежу за унікальним ідентифікатором, ідемпотентна обробка повідомлень, періодична звірка з платіжним сервісом і заздалегідь описана поведінка при недоплаті, переплаті та скасуванні. Нижче — як це влаштовано і в яких місцях розривається найчастіше.
Що змінюється після підключення: підтвердження, звірки, відмови
Якщо приймання криптоплатежів вбудовано в 1С-Битрикс на рівні бізнес-логіки замовлення, а не винесено окремою сторінкою оплати, змінюється весь контур: підтвердження надходить від мережі, модуль звіряє суму, адресу отримувача й потрібну кількість підтверджень — замовлення саме переходить в «оплачено». Менеджер дізнається про оплату не з листування, а зі статусу.
Частка підтверджених замовлень зростає завдяки тому, що зникає розрив між «гроші надіслано» та «статус оновлено». Автоматичне підтвердження оплати спрацьовує за повідомленням від мережі, а не за натисканням кнопки.
Час зарахування вимірюється очікуванням потрібної кількості підтверджень — клієнт бачить прогрес і не йде зі сторінки.
Скорочення ручних звірок — другий ефект. Звірка гаманця з таблицею замовлень перетворюється на регламентне завдання: сходяться суми, адреси й хеші транзакцій, а розбіжності потрапляють в окремий список. Вручну залишаються одиниці випадків — недоплата, платіж з чужої адреси, повторне надсилання.
Відмовостійкість приймання платежів тримається на ідемпотентності: повідомлення може надійти двічі, і повторна обробка не створює друге замовлення. Черга з повторами закриває недоступність вузла або тайм-аут відповіді, а нерозібрані події складаються в журнал, а не губляться.
Підсумок — зникає цілий клас відмов «оплата пройшла, замовлення не оформлено». Частка незавершених замовлень скорочується не завдяки умовлянням клієнта, а тому що кожна транзакція доводиться до кінцевого статусу автоматично.
Способи приймання криптоплатежів: шлюз, пряма мережа, кастодіальний сервіс
У 1С-Битрикс приймання криптовалюти не зводиться до кнопки «Оплатити»: модуль створює рахунок, віддає адресу та суму, а статус замовлення змінює обробник вебхука — він приймає підтвердження з мережі або від провайдера й записує хеш транзакції у властивості замовлення.
Далі все вирішує одне питання: де живуть приватні ключі й хто підтверджує факт оплати. Від цього залежать строки зарахування, схема повернень і обсяг того, що команда супроводжує власними силами.
Розбіжність між варіантами проявляється не на запуску, а на поверненнях, повторній звірці та розборі ситуації «замовлення позначено оплаченим, а транзакція не дійшла». Нижче — реальні альтернативи, між якими обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Платіжний шлюз для криптовалют | Потрібно приймати оплату в короткий строк і без власної інфраструктури | Зарахування та повернення йдуть за правилами провайдера, ключі й кошти на його боці |
| Пряма робота з блокчейн-мережею | Потрібен повний контроль над ключами й мінімум посередників | Власний вузол і моніторинг вхідних транзакцій, самостійна обробка підтверджень |
| Кастодіальний сервіс | Важливіше — зручний облік і керування через особистий кабінет | Контрагентський ризик: зберігання ключів і виведення — на боці сервісу |
| Некастодіальний прийом | Ключі залишаються в компанії, але піднімати повний вузол не хочеться | Потрібен окремий контур захисту ключів і звірка розбіжностей за транзакціями |
На практиці способи комбінують: основний потік іде через один варіант, резервний — через інший, а звірка живе окремим регламентом.
У 1С-Битрикс будь-який із них — це модуль з обробником вебхуків, журналом транзакцій і зв'язкою замовлення з хешем; відрізняється лише контур зберігання ключів і обсяг супроводу.
Як проходить впровадження: від аудиту кошика до передачі регламентів
Впровадження йде фіксованою послідовністю: спочатку розбираємо, як у магазині влаштовано приймання грошей, і лише потім підключаємо криптовалютний контур.
Порядок принциповий — якщо почати зі встановлення модуля, а не з аудиту платіжного контуру, спливають сценарії, де замовлення йде в збірку без підтвердженого платежу, а розбіжність знаходиться вже за випискою.
Послідовність етапів
- Аудит платіжного контуру. Дивимося, які обробники вже підключені, де зберігається й змінюється статус замовлення, як влаштовані повернення, часткові оплати й повторні спроби, що потрапляє в журнал подій.
- Схема оплати та узгодження. Фіксуємо місце криптоплатежу в життєвому циклі замовлення: окремий спосіб оплати чи комбінований, хто фіксує курс, скільки живе рахунок, за якими правилами він скасовується.
- Налаштування модуля оплати. Реєструємо обробник у системі, налаштовуємо ключі магазину, адреси повідомлень від платіжного шлюзу, вибір мережі та відповідність статусів замовлення статусам транзакції.
- Перевірка сценаріїв оплати. Проганяємо успішну оплату, недоплату й переплату, повторне повідомлення, прострочений рахунок, скасування покупцем — окремо дивимося, що перехід статусу спрацьовує один раз і не дублює замовлення.
- Тестування в закритому контурі. Працюємо на копії сайту з тестовою мережею та пісочницею шлюзу: ручні прогони плюс автоматичні перевірки на ідемпотентність і втрату повідомлень.
- Переведення в робочий режим. Змінюємо ключі на бойові, обмежуємо доступи за ролями, вмикаємо журналювання та оповіщення про замовлення, які довго висять у проміжному статусі.
- Передача регламентів. Віддаємо схему статусів, інструкції для менеджерів, порядок дій при розбіжності та доступ до журналів.
Після передачі ваша команда сама додає способи оплати й розбирає інциденти, не звертаючись до нас щодо кожної операції.
Що залишається в проєкті після здачі: модуль, регламенти, доступи
Після здачі в проєкті залишається не лише робочий код, а й шар, який дозволяє експлуатувати інтеграцію криптоплатежів у 1С-Битрикс без нас. Нижче — артефакти, які замовник отримує на руки разом з доступом до репозиторію та стендів.
- Конфігурація модуля оплати: прийнятні мережі та токени, поріг підтверджень, прив'язка до курсу, тайм-аут очікування оплати й поведінка при недоплаті винесені в адміністративні налаштування, а не зашиті в код.
- Схема проходження платежу: від виставлення рахунку до зарахування замовлення — усі статуси, точки розгалуження й місце, де стоїть захист від повторної обробки одного повідомлення від шлюзу.
- Політики доступу та ролі: хто бачить реквізити приймання, хто змінює налаштування модуля, хто вивантажує журнал; права розведені за принципом мінімально необхідних і однаково налаштовані на тестовому та робочому контурі.
- Журналювання операцій: кожна подія пишеться з номером замовлення, сумою, ідентифікатором транзакції та статусом — за журналом відновлюється будь-яка спірна операція.
- Регламент розбору інцидентів: покрокові сценарії на завислий платіж, розбіжність суми й недоступність вузла мережі — зі строками реакції, відповідальними та точками ескалації.
- Набір перевірок і порядок відкату: сценарії приймання на тестовій мережі, інструкція з розгортання та повернення на попередню версію модуля зі збереженням налаштувань.
Кейс: частка незавершених замовлень і ручні звірки — до й після
Магазин на 1С-Битрикс приймав оплату в криптовалюті, але підтвердження платежу залишалося ручним: менеджер отримував повідомлення від платіжного сервісу на пошту, звіряв суму й адресу гаманця із замовленням і лише після цього переводив його в статус «Оплачено».
Уночі та у вихідні черга накопичувалася до ранку, частина покупців встигала оформити замовлення повторно або йшла.
Що було до
Із 1 200 замовлень з оплатою в криптовалюті 214 зависли на кроці підтвердження — 18% замовлень у підвішеному стані. Ручна звірка займала в середньому 7 хвилин на замовлення, а розбіжності через комісію мережі розбиралися окремо.
Що змінили і що стало після
Підключили зворотне повідомлення від платіжного сервісу: підтвердження надходить на окрему адресу, підпис перевіряється, статус замовлення змінюється автоматично. Менеджеру залишили лише чергу винятків — незбіг суми та повторні повідомлення.
| Показник | До | Після |
|---|---|---|
| Замовлення без підтвердження | 18% | 2% |
| Ручна звірка на замовлення | 7 хвилин | лише винятки |
| Час до статусу «Оплачено» | до 14 годин | 1-3 хвилини |
| Звернення «де моє замовлення» | 40 на місяць | 6 |
Решта 2% — платежі з низькою підтвердженістю мережі: вони не губляться, а чекають потрібної кількості підтверджень без участі людини.
Що робити, якщо криптоплатежі вже частково підключені
Часткове підключення криптоплатежів — частий випадок: модуль уже стоїть, один-два способи оплати працюють.
Небезпечна тут не неповнота, а розбіжність — частина замовлень висить у статусі очікування, менеджер закриває їх руками, і повторне повідомлення мережі проводить оплату вдруге.
Перед міграцією платіжного контуру фіксуємо поточний стан: які обробники викликаються, де зберігається зв'язок замовлення з транзакцією, за якою ознакою замовлення вважається оплаченим.
Переписувати зазвичай доводиться лише шар підтвердження — каталог, кошик і історія замовлень залишаються недоторканими.
Порядок робіт будуємо так, щоб приймання оплати не зупинялося: новий обробник вмикаємо паралельно зі старим на одному способі оплати й звіряємо результати, решту переводимо після повного збігу.
Накопичені замовлення не переоформлюємо — дописуємо зв'язок «замовлення — транзакція» в наявні записи, а закриті вручну позначаємо, щоб автоматика їх не чіпала.
Штатний функціонал 1С-Битрикс розширюється, а не замінюється: сторінка оплати, листи та звіти залишаються на місці, змінюється лише шар підтвердження платежу.
Обмеження та спірні сценарії: коли криптоприймання не підходить
Криптоплатіж незворотний на рівні мережі: відкликати або скасувати транзакцію не можна, тому повернення — це окремий вихідний переказ з вашого гаманця. До запуску варто відповісти, чи є вільний баланс під такі повернення і хто їх підписує.
Якщо частка скасувань після оплати в моделі бізнесу помітна, криптоприймання додасть ручних операцій, а не прибере їх.
Друге обмеження — час підтвердження. Поки мережа не набрала потрібну кількість підтверджень, платіж не вважається здійсненим: при високому навантаженні це десятки хвилин, а в окремих мережах — години.
Замовлення в цей період висить у статусі очікування, товар тримається в резерві, клієнт пише в підтримку. Робоче рішення — свій тайм-аут очікування й автоматичне скасування з вивільненням резерву.
Третій шар — облік. У 1С-Битрикс платіж надходить вебхуком, і його потрібно пов'язати із замовленням, зафіксувати суму й курс на момент зарахування, інакше виручка та складський облік не зійдуться.
Окремо — перевірки на боці провайдера: адреса або монета може бути позначена як сумнівна, і кошти заморожуються вже в нього.
Клієнт оплатив, але підтверджень немає — що із замовленням?
Замовлення залишається в проміжному статусі, а не в «оплачено». Переводить його повідомлення з потрібною кількістю підтверджень; до цього працює тайм-аут, за яким замовлення скасовується і резерв повертається.
Повторні повідомлення обробляються ідемпотентно за хешем транзакції, а спірні випадки закриваються ручною звіркою адреси та суми.
Обговоримо задачу: повернемося з оцінкою, схемою та планом робіт
Щоб повернутися з точною оцінкою, а не вилкою «від і до», нам потрібно побачити поточний контур приймання оплати.
Опишіть, як влаштовано магазин на 1С-Битрикс: які способи оплати вже підключені, де зберігаються замовлення і чи є зовнішній сервіс, який приймає повідомлення від платіжних шлюзів.
З боку замовника достатньо підготувати:
- перелік криптовалют і мереж, приймання яких потрібне для впровадження приймання криптоплатежів;
- доступ до адміністративної панелі та до тестового середовища сайту;
- опис поточного шляху замовлення: від оформлення кошика до зміни статусу оплати;
- реквізити гаманців або підтвердження, що їх видає платіжний провайдер;
- вимоги бухгалтерії до документів і вивантажень за криптоопераціями;
- контакт інженера, який підтримує сайт зараз, — щоб узгодити правки ядра та оновлення.
У відповідь ми повернемо:
- оцінку трудовитрат за етапами та загальний план робіт зі строками;
- схему проходження платежу: кошик, рахунок, підтвердження в мережі, вебхук, зміна статусу замовлення;
- перелік модулів і правок, які знадобляться, з оцінкою впливу на майбутні оновлення платформи;
- порядок перевірки на тестовій мережі та сценарії відкату, якщо підтвердження не надійшло.
Обговорити задачу можна у зручному форматі: листування, дзвінок або розбір за вашою схемою. Чим точніше описано поточний контур, тим менше припущень залишиться в плані робіт.
