Сцена, яку я бачу дедалі частіше. Людина за вихідні збирає в Lovable, Bolt чи v0 гарний інтернет-магазин. Дизайн охайний, сторінки товарів працюють, кошик рахує правильно. Потім настає момент, коли треба, щоб клієнт реально заплатив через LiqPay, щоб покупець обрав відділення Нової Пошти, щоб після продажу автоматично пробився фіскальний чек у ПРРО. І саме тут усе зупиняється.
ШІ генерує кнопку оплати, яка виглядає ідеально. Тільки гроші через неї не приходять. Малює форму «увійти через Дію», яка нікого не автентифікує. Обіцяє експорт чека, який ДПС ніколи не побачить. Це не випадковість і не поганий промпт — це фундаментальна межа, на якій теперішні ШІ-інструменти зупиняються. У цій статті я поясню, чому так, які саме українські інтеграції вимагають людини, і що це реально означає для ціни та терміну вашого проєкту. Я пишу це як практик, який не раз доводив застряглі вайбкод-прототипи до робочого продакшну.
Чому ШІ добре генерує інтерфейс, але не інтеграції
Інтерфейс — це та сфера, де ШІ справді сильний. Кнопки, форми, сітки, анімації — усе це повторювані патерни, яких в інтернеті описано мільйони прикладів. ШІ навчений саме на такому коді, тож гарний і навіть адаптивний фронтенд він створює вражаюче швидко. Якщо вам потрібно, щоб сайт виглядав добре, ШІ справді допоможе.
Інтеграція з реальною системою — зовсім інша історія. LiqPay, monobank, Нова Пошта, Дія чи ДПС — це не шматки коду, які ШІ може «пригадати» й згенерувати. Це живі системи, що існують за межами вашого сайту і яким потрібні три речі, яких у ШІ фізично немає: договірних відносин вашої компанії з провайдером, ваших секретних бойових ключів і безпечного сервера, де ця логіка працюватиме. ШІ не підпише за вас договір еквайрингу з monobank. Не підтвердить ваш ФОП у системі провайдера. Не зберігатиме безпечно ваші API-ключі, бо він просто вставляє їх у код, який бачить кожен користувач браузера.
Це принципова різниця між «схоже, що працює» і «працює в продакшні з реальними грошима». Докладніше про той самий феномен я писав у статті про справжню ціну «безкоштовного» сайту на ШІ — інтеграції якраз і є тією частиною, де застрягає найбільше людей.
Класична помилка, яку я знаходжу на ШІ-сайтах
Відкриваєш згенерований магазин, тиснеш «Оплатити» — і потрапляєш на сторінку, яка просто показує «Дякуємо за замовлення». Жодної реальної оплати не сталося. ШІ згенерував візуал платіжного потоку, а не саму транзакцію. Ще гірше, коли бойові ключі залишені у видимому коді фронтенду — тоді будь-хто може їх побачити й зловживати. Це не дрібниця, яку «потім виправиш». Це вся серверна частина, якої просто немає.
Українські інтеграції, яким потрібна людина
Подивімося конкретно. Ось інтеграції, з якими реально стикається кожен український онлайн-бізнес, і чому кожній із них потрібна людина, а не промпт.
| Інтеграція | Для чого | Чому ШІ не підключить |
|---|---|---|
| LiqPay / monobank еквайринг / WayForPay / Fondy | Онлайн-оплата картками, Apple/Google Pay, оплата частинами | Договір з банком чи сервісом, бойові ключі, перевірка підпису callback на сервері |
| Накладений платіж (Нова Пошта) | Оплата при отриманні — досі величезна частка замовлень | Договір з перевізником, налаштування зворотної доставки коштів, узгодження статусів |
| Дія / Diia.Signature / BankID НБУ / КЕП | Ідентифікація особи, вхід, кваліфікований підпис | Договірний доступ через id.gov.ua, безпечне підписання запитів, захист персональних даних |
| ПРРО + податкові накладні (ЄРПН, ДПС) | Фіскальний чек і подання податкових даних | Реєстрація в ДПС, суворий формат даних, відповідність, обробка помилок |
| Нова Пошта / Укрпошта / Meest / Justin API | Відділення, генерація ТТН, трекінг посилок | Договір і ключі перевізника, завантаження довідників, формування ТТН через їхню систему |
| Вчасно / M.E.Doc (Медок) | Електронний документообіг, бухгалтерія | Узгодження бізнес-логіки, двосторонній обмін документами, узгодження з бухгалтером |
Оплата: LiqPay, monobank еквайринг, WayForPay, Fondy
В Україні оплата карткою онлайн — стандарт, і у людей є кілька звичних кнопок: LiqPay від ПриватБанку, «plata by mono» (еквайринг моно з найнижчою комісією і безкоштовним ПРРО), WayForPay з оплатою частинами та Fondy для магазинів і маркетплейсів. Щоб це працювало, потрібен договір з банком або платіжним сервісом, підтверджений акаунт ФОП чи ТОВ і бойові ключі. Але найважливіша частина невидима: коли клієнт платить, провайдер надсилає підтвердження (callback) на ваш сервер, і ваш сервер мусить перевірити підпис цього повідомлення, перш ніж позначити замовлення оплаченим. Без цієї перевірки будь-хто може надіслати підроблене «оплачено» і отримати товар безкоштовно. Цієї серверної логіки ШІ не генерує, бо в нього немає ваших ключів і він не розуміє наслідків для вашого бізнесу.
Накладений платіж і Apple/Google Pay
Окрема українська реальність — накладений платіж через Нову Пошту. Попри весь онлайн, значна частина покупців досі платить при отриманні, і магазин без цієї опції втрачає замовлення. Це не «кнопка»: треба налаштувати зворотне переказування коштів продавцю, узгодити статуси і коректно закривати замовлення. Поруч ідуть Apple Pay і Google Pay, без яких сучасний чекаут виглядає неповним, та ПРОСТІР як національна платіжна система. Кожен із цих варіантів — окремий потік, який ШІ намалює, але не з'єднає.
Автентифікація: Дія, BankID НБУ та КЕП
Якщо вашому сервісу потрібна надійна ідентифікація — фінанси, медицина, договори, реєстрації — українець очікує входу через Дію, BankID НБУ (через monobank чи Privat24) або підписання через КЕП. Це доступно через офіційні шлюзи, як-от id.gov.ua, на договірній основі, і вимагає правильного підписання запитів та коректного потоку підтвердження особи. Помилка тут має два боки: або ніхто не може увійти, або, що значно гірше, ви впускаєте не ту людину. Це не форма — це система безпеки, яку має будувати й тестувати людина, що розуміє, чим закінчується помилка.
ПРРО та податкові накладні: ДПС не приймає «майже правильне»
Після продажу потрібен фіскальний чек, а для більшості роздрібних і онлайн-продажів ПРРО (програмний РРО) обов'язковий — добра новина в тому, що безкоштовні рішення є в monobank, Fondy та в кабінеті ДПС. Дані податкових накладних реєструються в ЄРПН. Тут ШІ обіцяє «згенерувати чек», але система ДПС приймає лише дані, відформатовані точно за вимогами: правильні поля, податкові коди, структура. Формату «майже правильно» не існує — дані або приймаються, або відхиляються з помилкою, яку треба зрозуміти й виправити. Цю відповідність забезпечує людина, яка знає, як реально поводиться система ДПС, а не текст, що виглядає переконливо.
Доставка та документообіг: Нова Пошта, Укрпошта, Вчасно
Інтернет-магазину потрібно, щоб покупець обрав відділення чи поштомат, щоб автоматично згенерувалася ТТН і щоб клієнт міг відстежити посилку. Для цього потрібен договір з перевізником, ключі акаунта, завантаження довідника відділень і формування ТТН через їхню систему — Нова Пошта тут must-have, далі Укрпошта, Meest, Justin. ШІ намалює віконце вибору відділення, але воно буде порожнім: без реального зв'язку з API Нової Пошти там немає ні відділень, ні ТТН. Глибше — електронний документообіг через Вчасно чи M.E.Doc, де помилка означає неузгоджені документи з вашою бухгалтерією.
Спільний знаменник
Помітьте закономірність: усі ці інтеграції вимагають договірних відносин із зовнішньою системою, ваших секретних ключів і серверної логіки з перевірками. Жодної з цих трьох речей немає в згенерованому ШІ фронтенді. Ось чому кнопка виглядає, але не працює — бракує саме тієї частини, якої не видно.
Чому це не «підключи API за 5 хвилин»
Часто чую: «але ж є документація, просто підключи API». Так, демо, де кнопка виглядає як оплата, справді робиться за 5 хвилин. Реальне підключення, яке не має втратити гроші, не прийняти подвійний платіж і витримати аудит провайдера, складається з кількох етапів, жоден з яких не можна пропустити.
- Договір і підтвердження акаунта. Провайдер має підтвердити ваш ФОП чи ТОВ і надати продакшн-доступ. Це часто триває довше, ніж сам код.
- Тестування в sandbox. У кожного провайдера є тестове середовище, де потік перевіряють перед увімкненням реальних грошей. Пропустиш цей крок — першим тестом стане живий клієнт.
- Перевірка підписів і callback. Сервер мусить переконатися, що підтвердження оплати справді прийшло від провайдера, а не від зловмисника.
- Відповідність і захист даних. Дані ідентифікації та платежів чутливі — їх обробка має відповідати закону про захист персональних даних, а не лише «працювати».
- Крайні випадки. Що робити, коли платіж обірвався на півдорозі, коли клієнт натиснув двічі, коли провайдер не відповів, коли треба повернути кошти. Саме ці випадки відрізняють демо від продукту.
Це той самий «важкий 30 %», про який я кажу майже кожному клієнту. ШІ доводить проєкт до 70 % — гарного, видимого, вражаючого. Решта 30 % — інтеграції, безпека, крайні випадки, відповідність — найскладніша й найдорожча частина. Не тому, що її «важко завершити», а тому, що саме вона і є реальним продуктом. Якщо хочете чесно розібратися, де ШІ вам справді достатньо, а де без людини не обійтися, почитайте коли достатньо ШІ, а коли потрібен розробник — там я розкладаю обидві сторони без прикрас.
Що це означає для ціни й терміну
Буду відвертим: ось реальні орієнтовні діапазони, скільки коштує чисто підключити українські інтеграції до сайту чи інтернет-магазину. Ціни в гривні, з приблизним перерахунком у євро (курс плаває, орієнтовно 1 € ≈ 45 ₴ станом на середину 2026). Це не «латання коду», а система, яка витримує реальний трафік і аудит провайдера.
| Інтеграція | Орієнтовна ціна | Термін (за наявності акаунта) |
|---|---|---|
| Одна платіжна система (LiqPay / monobank / WayForPay / Fondy) | 25 000 – 60 000 ₴ (≈ 550–1 300 €) | 1 – 2 тижні |
| API Нової Пошти + накладений платіж | 20 000 – 50 000 ₴ (≈ 450–1 100 €) | 1 – 2 тижні |
| Автентифікація через Дію / BankID / КЕП | 45 000 – 110 000 ₴ (≈ 1 000–2 450 €) | 2 – 3 тижні |
| ПРРО + податкові накладні (ЄРПН, ДПС) | від 35 000 ₴ (≈ від 780 €) | 2 – 4 тижні |
| Документообіг / бухгалтерія (Вчасно, M.E.Doc) | від 40 000 ₴ (≈ від 890 €) | 2 – 4 тижні |
Дві речі, які варто запам'ятати щодо терміну. По-перше, найбільше часу часто забирає не код, а підтвердження акаунта провайдера та отримання бойових ключів — цей процес варто починати якомога раніше, незалежно від того, хто будує сайт. По-друге, інтеграції рідко бувають ізольованими: оплата, фіскальний чек і доставка зазвичай утворюють один ланцюг, тож їх варто планувати разом, а не латати по одній. Як ФОП на єдиному податку я працюю з рахунками й актами офіційно, а в dev-B2B нормально, коли ціну прив'язують до € чи $ і конвертують у гривню — я показую реальні діапазони в ₴ із поміткою в €.
Коли ШІ вам цілком достатньо
Буду чесним: якщо вам потрібен лише інформаційний сайт, лендинг для перевірки ідеї чи внутрішній інструмент без реальних оплат та ідентифікації — інструмента на кшталт Lovable чи Bolt може цілком вистачити, і я не нав'язуватиму розробника без потреби. Межа чітка: інтеграції з реальними грошима, ідентифікацією клієнтів і ДПС починаються там, де ШІ закінчується. Перетнувши цю межу, потрібна людина, яка розуміє наслідки.
Як до цього підходжу я
Коли я беру проєкт, у якому інтеграції не працюють, я не латаю згенерований код по шматочку. Дивлюся, що реально треба підключити, складаю весь ланцюг — оплата, фіскальний чек, доставка, автентифікація — і будую серверну частину з усіма перевірками, тестуванням у sandbox і крайніми випадками. Мета не «щоб кнопка виглядала», а щоб гроші реально приходили, чек пробивався в ПРРО, а ДПС приймала податкові накладні. Senior-підхід ще й у тому, що я повторно використовую все придатне з вашого вайбкод-прототипу, а не переписую з нуля заради переписування — ви лишаєтеся з робочим продуктом і кодом, який належить вам, а не з гарним фасадом, за яким нічого немає. Якщо вам потрібен повний цикл, я роблю це в межах розробки застосунків і сайтів.
Маєте ШІ-сайт, де не працює оплата чи інтеграції?
Покажіть, що вже є, і обговоримо, що реально треба підключити, щоб запрацювало в продакшні. Дам конкретний план з ціною в ₴ і терміном — без зобов'язань.
Обговорити інтеграціїЧасті запитання
Чому ШІ може зробити сайт, але не підключить LiqPay чи monobank?
ШІ чудово генерує інтерфейс, бо він повторюваний і рясно описаний в інтернеті. Інтеграція LiqPay чи monobank еквайрингу вимагає реального договору з банком або платіжним сервісом, підтвердженого акаунта вашого ФОП чи ТОВ, доступу до бойових ключів, перевірки підпису платіжних callback-ів на сервері та безпечного хостингу. Цього ШІ фізично не зробить за вас: у нього немає даних вашого бізнесу, він не підпише договір і не зберігатиме безпечно ваші секретні ключі. Тому згенерована кнопка оплати виглядає добре, але гроші через неї не приходять.
Чи можна підключити Дію або вхід через BankID самостійно?
Автентифікація через Дію, BankID НБУ (вхід через monobank чи Privat24) або підписання через КЕП доступні лише за договором з провайдером, через офіційні шлюзи на кшталт id.gov.ua, і вимагають безпечного сервера, правильного підписання запитів, коректного потоку підтвердження особи та обробки персональних даних згідно з українським законодавством. Це не кнопка, яку вставляєш, а система ідентифікації, де помилка означає, що або ніхто не може увійти, або ви впускаєте не ту людину. Такі інтеграції має будувати й тестувати людина, яка розуміє наслідки.
Скільки коштує підключити українські інтеграції до сайту?
Чисте підключення однієї платіжної системи (LiqPay, monobank еквайринг, WayForPay чи Fondy) із тестуванням у sandbox та виходом у продакшн зазвичай коштує від 25 000 до 60 000 ₴ (приблизно 550–1 300 €), залежно від складності потоку. API Нової Пошти з вибором відділення, генерацією ТТН і накладеним платежем — від 20 000 до 50 000 ₴. Автентифікація через Дію, BankID або КЕП — від 45 000 до 110 000 ₴. Фіскалізація через ПРРО та податкові накладні в ЄРПН — від 35 000 ₴ і вище. Точна цифра залежить від кількості інтеграцій і того, наскільки глибоко вони пов'язані з вашою бізнес-логікою.
Чому не можна просто підключити API за 5 хвилин?
Платіжні та ідентифікаційні API вимагають реєстрації в провайдера, договору, бойових і тестових ключів, тестування в sandbox перед увімкненням реальних грошей, перевірки підписів, обробки помилок і повернень, відповідності закону про захист персональних даних та безпечного зберігання ключів. Демо, де кнопка лише виглядає як оплата, справді робиться за 5 хвилин. Реальне підключення, яке не втрачає гроші, не приймає подвійних платежів і витримує аудит провайдера, займає дні — і це нормально.
Чи безпечна згенерована ШІ кнопка оплати?
Візуально так, вона виглядає як кнопка оплати. Функціонально майже ніколи не безпечна для продакшну. Найчастіші проблеми: секретні ключі залишені у видимому коді в браузері, підтвердження платежу не перевіряється на сервері, тож замовлення можна підробити, немає перевірки підпису callback, тож сповіщення про оплату може надіслати будь-хто. Такі діри я знаходив не на одному сайті, початому з ШІ. Безпеку тут визначає не вигляд кнопки, а серверна логіка, якої в згенерованому варіанті просто немає.
За який час ви підключите оплату, доставку та фіскальний чек до мого сайту?
Якщо акаунт провайдера та договір уже є, чисте підключення однієї платіжної системи з тестуванням у sandbox я запускаю за 1–2 тижні. API Нової Пошти з накладеним платежем — 1–2 тижні. Фіскалізацію через ПРРО та податкові накладні в ЄРПН — 2–4 тижні, бо тут більше крайніх випадків і узгодження з вашим бухгалтером. Найбільше часу зазвичай забирає не код, а підтвердження акаунта провайдера та отримання бойових ключів — це варто починати якомога раніше.
Від гарного фасаду до робочого продукту
Якщо ШІ довів вас до 70 %, а оплата, ідентифікація та чеки досі не працюють — я можу збудувати той важкий 30 %, щоб усе реально запрацювало. Відверта розмова про ваш випадок, конкретний план у ₴, жодних зобов'язань.
Отримати конкретний план