Інтеграції інтернет-магазину: оплата, доставка і CRM

Інтернет-магазин ніколи не буває просто сайтом. За кожним замовленням стоять платіжний сервіс, що списує гроші з картки, служба доставки, що везе посилку, облікова система, яка знає залишки, ПРРО, що формує фіскальний чек, і CRM, яка перетворює разового покупця на постійного. Коли ці системи обмінюються даними автоматично, магазин працює рівно. Коли ні, менеджери переносять дані між вкладками, замовлення губляться, а покупці оплачують товар, якого вже немає на складі.

Цю «з’єднувальну» роботу і називають інтеграціями. У статті пояснюємо, що вони включають, розбираємо основні типи інтеграцій для українського інтернет-магазину (оплата, доставка, CRM і маркетинг, облік, маркетплейси), порівнюємо способи їх побудови і показуємо, як спланувати проєкт, щоб інтеграції не стали джерелом щоденних проблем.

Ми робимо розробку інтернет-магазину разом з усіма інтеграціями і працюємо з ритейлом і брендами в Україні та Європі. Більше про наш досвід на сторінці рішення для ритейлу та e‑commerce.

Що таке інтеграції інтернет-магазину

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

Технічно інтеграції тримаються на кількох складових:

• API. Програмний інтерфейс, через який одна система запитує або передає дані іншій: «створити ТТН», «отримати залишок товару».

• Webhooks. Замість того щоб щохвилини питати про зміни, система сама надсилає повідомлення, щойно щось сталося: оплата пройшла, посилку доставлено, повернення оформлено.

• Middleware. Проміжний шар, який отримує дані від однієї системи, перетворює їх і передає іншій. Це може бути власний код або готова платформа.

• iPaaS. Хмарна платформа для побудови інтеграцій без власного сервера для middleware.

• Синхронізація даних. Правила, як тримати однакові дані узгодженими в різних системах: яка система головна для цін, яка для залишків, як часто вони синхронізуються.

Ось типовий шлях замовлення в інтегрованому магазині, від кошика до обліку:

1. Покупець оформлює замовлення і платить. Платіжний сервіс підтверджує оплату і повертає статус у магазин.

2. ПРРО автоматично формує фіскальний чек і надсилає його покупцю.

3. Магазин створює замовлення і передає його в CRM або облікову систему, де резервується товар.

4. Інтеграція з доставкою створює ТТН у «Новій пошті» чи іншій службі і повертає номер для трекінгу.

5. Покупець отримує лист або повідомлення з номером ТТН.

6. Залишки оновлюються на сайті та на всіх маркетплейсах, де продається товар.

7. Продаж і оплата фіксуються в обліковій системі, а аналітика отримує подію покупки.

Кожна стрілка в цьому ланцюжку — це окрема інтеграція. Якщо одна зламається, хтось робитиме цей крок руками.

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

Інтеграція онлайн-оплати

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

В Україні основні варіанти такі:

• LiqPay, сервіс ПриватБанку з широкою підтримкою готових модулів для популярних CMS;

• WayForPay з розвинутими інструментами для інтернет-магазинів і рекурентних платежів;

• plata by mono, платіжне рішення від monobank;

• інтернет-еквайринг інших банків для бізнесу, з яким у вас уже є рахунок.

Майже всі ці сервіси підтримують Apple Pay і Google Pay, які помітно прискорюють оплату на мобільних. Окремий інструмент — оплата частинами (наприклад, від ПриватБанку чи monobank), яка допомагає продавати дорожчі товари без класичного кредиту.

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

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

Як обрати платіжний сервіс

Порівнюючи сервіси, дивіться далі за розміром комісії:

• Комісії. Відсоток з транзакції, комісії за повернення і чарджбеки, можливі щомісячні платежі. Рахуйте на своєму реальному профілі замовлень.

• Валюти. Чи потрібні вам платежі в іноземній валюті від клієнтів з-за кордону?

• Швидкість виплат. Як швидко гроші надходять на рахунок і чи є затримки для нових продавців.

• UX оплати. Чи можна вбудувати форму в checkout, чи покупця перенаправляють на сторінку сервісу. Чи підтримуються Apple Pay, Google Pay і збереження картки.

• Якість інтеграції. Зрозуміла документація, тестове середовище, надійні webhooks і готові модулі для вашої платформи.

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

Безпека та фіскалізація

Карткові платежі мають суворі правила. PCI DSS — це стандарт безпеки для всіх, хто працює з картковими даними. Найпростіший спосіб зменшити свої зобов’язання: ніколи не пропускати повні номери карток через власні сервери. Використовуйте платіжну форму провайдера і токенізацію, коли картку зберігає платіжний сервіс, а магазин отримує лише токен. 3-D Secure додає підтвердження оплати в банківському застосунку, і якісна інтеграція проводить покупця через цей крок без збоїв.

В Україні до цього додається фіскалізація. Оплата карткою на сайті через інтернет-еквайринг, як правило, потребує формування фіскального чека через РРО або ПРРО. Програмний РРО, наприклад Checkbox, інтегрується з магазином і автоматично створює чек після успішної оплати, надсилаючи його покупцю на email чи в месенджер. Конкретні вимоги залежать від форми бізнесу і способу розрахунку, тому схему фіскалізації варто погодити з бухгалтером до запуску.

Інтеграція служб доставки

Після оплати доставка дає найбільшу економію ручної роботи. Для більшості українських магазинів головна інтеграція тут — API «Нової пошти». Він дозволяє сайту:

• шукати місто і показувати покупцю список відділень і поштоматів, зокрема на карті;

• розраховувати вартість і орієнтовний строк доставки ще в кошику;

• автоматично створювати ТТН, щойно замовлення готове до відправлення;

• отримувати статуси посилки і передавати їх покупцю;

• оформлювати повернення.

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

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

Кур’єрська та локальна доставка

Не всі замовлення їдуть через національних перевізників. Продукти, квіти, меблі, техніка з монтажем часто доставляють власні кур’єри або локальні партнери. Тут інтеграція має враховувати:

• зони доставки з різною вартістю і мінімальною сумою замовлення;

• власних кур’єрів, розподіл замовлень між ними і маршрути;

• слоти доставки, які покупець обирає при оформленні, з обмеженням кількості замовлень на слот.

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

Інтеграція з CRM і маркетингом

Дані замовлень цінні не лише для відправлення. Коли магазин інтегрований з CRM, менеджери бачать повну картину по клієнту: історію замовлень, звернення, статуси, повернення. Для українського e‑commerce популярні KeyCRM і SalesDrive, які мають готові інтеграції з «Новою поштою», платіжними сервісами і маркетплейсами. Для B2B і міжнародних продажів часто обирають HubSpot. Яка CRM-система підійде саме вам, залежить від обсягу замовлень, кількості менеджерів і каналів продажу. Дивіться насамперед на готові інтеграції з вашою платформою, службами доставки і ПРРО, а також на те, наскільки зручно в ній працювати менеджерам щодня.

Що дає ця зв’язка:

• Сегментація. Нові покупці, постійні, найцінніші, покупці конкретної категорії.

• Покинутий кошик. Автоматичні листи чи повідомлення тим, хто залишив товари в кошику. Одна з найрезультативніших автоматизацій в e‑commerce.

• Ланцюжки після покупки. Підтвердження, прохання про відгук, допродажі, нагадування про повторну покупку.

• Робота менеджерів. Нові замовлення і звернення стають задачами в CRM з нагадуваннями.

Для email і месенджер-розсилок в Україні часто використовують eSputnik і SendPulse. Аналітика і реклама — частина тієї ж картини: GA4 має отримувати повний набір e‑commerce подій, від перегляду товару до покупки, а Meta Conversions API передає покупки з сервера в Meta, що покращує точність відстеження і оптимізацію реклами.

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

Облік, склад і ERP

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

Типові потоки даних:

• Синхронізація залишків. Залишки з обліку чи складу потрапляють на сайт, тож покупець бачить реальну наявність. Це головний захист від продажу відсутнього товару.

• Синхронізація цін. Зміни цін в обліковій системі автоматично з’являються на сайті, включно з оптовими цінами для B2B.

• Передача замовлень. Замовлення з сайту потрапляють у облік або OMS для комплектації, рахунків і повернень.

• Товарний контент. PIM-система зберігає описи, характеристики і фото та передає їх на сайт і в інші канали.

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

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

Маркетплейси, POS і мультиканальні продажі

Багато брендів продають одночасно в кількох каналах: власний сайт, Rozetka, Prom.ua, Epicentr, порівняльні сервіси на кшталт Hotline, товарна реклама через Google Merchant Center і фізичні магазини з POS-системою.

Мультиканальна інтеграція з’єднує всі ці канали з одними залишками і одним потоком замовлень:

• Маркетплейси отримують товари, ціни й залишки через API або фіди, а замовлення з них потрапляють у вашу CRM.

• Hotline і Google Merchant Center отримують товарний фід з цінами та наявністю.

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

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

Для B2B-продажів інтеграція з обліком ще важливіша. Оптовим клієнтам потрібні індивідуальні ціни, відстрочка платежу, кредитні ліміти і документи, які формуються в обліковій системі. Без інтеграції B2B-кабінет не замінить звичні замовлення телефоном і поштою, і менеджери продовжать переносити їх вручну.

Способи інтеграції

Є чотири основні способи будувати інтеграції. Більшість магазинів їх поєднують.

Як ми застосовуємо ці підходи на практиці, дивіться в наших кейсах e‑commerce, від бутиків одягу до маркетплейсів і платформ бронювання.

Готові модулі та плагіни

Для більшості популярних платформ є готові модулі: для OpenCart, WooCommerce, Shopify. Для LiqPay, WayForPay, «Нової пошти» і популярних CRM зазвичай знайдеться готове рішення. Для стандартних задач це найшвидший і найдешевший шлях.

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

Кастомна API-інтеграція

Кастомна інтеграція з’єднує системи напряму через їхні API: REST-запити і webhooks. Це правильний вибір, коли процес специфічний, обсяги великі або надійного модуля немає.

Кастомні інтеграції мають враховувати реальні деталі: ліміти запитів (скільки запитів API приймає за хвилину), повторні спроби при тимчасовій недоступності сервісу, дублікати webhooks, зміни версій API. Якщо зроблено правильно, це найнадійніший і найпередбачуваніший варіант.

Middleware та iPaaS

Middleware-платформи стоять між системами і дозволяють будувати інтеграції як сценарії. Zapier і Make популярні для простіших автоматизацій. n8n дає більше гнучкості і може працювати на власному сервері, що важливо, коли ви хочете контролювати дані й витрати. Такий підхід добре працює, коли магазин з’єднує багато інструментів, процеси часто змінюються, а команда хоче налаштовувати сценарії без повного циклу розробки. Ми регулярно будуємо такі сценарії, детальніше на сторінці автоматизація на n8n.

Headless і composable commerce

У headless commerce вітрина (те, що бачить покупець) відокремлена від бекенду магазину (каталог, кошик, замовлення) і з’єднана з ним через API. Composable commerce йде далі: магазин збирають з окремих сервісів для пошуку, контенту, оплат, акцій тощо. MACH-архітектура (мікросервіси, API-first, хмара, headless) описує саме цей підхід. Він дає максимальну гнучкість для великих брендів, але потребує сильної технічної команди і ретельного планування, бо тут усе є інтеграцією.

Як спланувати інтеграції

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

1. Складіть карту інтеграцій. Перелічіть усі системи: сайт, оплата, ПРРО, доставка, облік, CRM, розсилки, маркетплейси, аналітика. Намалюйте потоки даних між ними. Така карта часто показує дублювання інструментів або відсутні зв’язки.

2. Визначте головні системи. Для кожного типу даних вирішіть, яка система головна: товари в PIM чи обліку, залишки на складі, клієнти в CRM.

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

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

5. Продумайте обробку помилок. Що відбувається, коли система недоступна або дані некоректні: повторні спроби, черги, сповіщення, ручна перевірка.

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

6. Тестуйте в тестовому середовищі. Платіжні сервіси і служби доставки мають тестові режими. Перевірте крайні випадки: невдала оплата, часткове повернення, розділене відправлення, товар, що закінчився.

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

7. Налаштуйте моніторинг. Після запуску відстежуйте збої синхронізації, затримки замовлень і помилки API. Інтеграція, що ламається тихо, гірша за ту, що ламається помітно.

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

8. Задокументуйте все. Коротко опишіть кожну інтеграцію: що вона робить, які системи з’єднує, які ключі та webhooks використовує, хто за неї відповідає і що робити при збої. Такий документ економить дні, коли в команду приходить новий розробник або коли щось ламається в найгірший момент, наприклад під час розпродажу.

Хто відповідає за інтеграцію з вашого боку. Інтеграція поєднує системи, якими керують різні люди: бухгалтерія веде облік, склад відповідає за залишки, маркетинг — за CRM і розсилки. Призначте одну людину з боку бізнесу, яка знає, як має працювати процес, ухвалює рішення щодо правил обміну даними і перевіряє результат. Без такої людини розробники змушені вгадувати, а помилки виявляються вже після запуску.

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

Запускайте інтеграції поетапно. Якщо одночасно підключати оплату, доставку, облік, CRM і маркетплейси, проблеми важко відстежити. Почніть з того, що потрібно для прийому й виконання замовлень, зазвичай це оплата і доставка. Далі додайте синхронізацію залишків і обліку, потім CRM і маркетинг. Кожен етап тестуйте на реальних замовленнях, перш ніж починати наступний.

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

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

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

Типові проблеми інтеграцій і як їх уникнути

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

Дублі даних. Той самий клієнт чи товар існує кілька разів у різних системах з трохи різними даними. Уникнути допомагають чіткі головні системи й унікальні ідентифікатори.

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

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

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

Vendor lock-in. Усі інтеграції побудовані всередині екосистеми однієї платформи, тож переїзд означає перебудову всього. Тримайте важливу бізнес-логіку у власному middleware чи коді й документуйте кожну інтеграцію.

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