Платіжні сервіси для українського бізнесу: Tranzzo, iPay, Privat24 та інтернет-еквайринг

Як працює прийом платежів на сайтах в Україні

Український ринок онлайн-платежів — один із найвибагливіших і найдинамічніших у Європі. За простою кнопкою «Оплатити» ховається складна інженерна екосистема з платіжних шлюзів, банків-еквайрів, антифрод-систем та протоколів безпеки, де кожна ланка легко може перетворитись на вузьке місце, чи навіть на вразливість для бізнесу. Вибір платіжного сервісу — не формальність, а рішення, що впливає на конверсію, вартість кожного продажу, швидкість отримання виручки й навіть коло покупців, які зможуть заплатити. У цій статті ми розкажемо, що таке інтернет-еквайринг, розберемо, як влаштований прийом платежів в Україні та чим відрізняються Tranzzo, iPay та інтернет-еквайринг ПриватБанку. 

Як взагалі став можливим сучасний світ без готівки? Фундаментом електронної комерції як такої виступає інтернет-еквайринг — це послуга, що дає змогу приймати оплату картками та електронними гаманцями на сайті, в застосунку чи месенджері, коли покупець не поруч. Звичайний еквайринг для бізнесу працює через POS-термінал: картка присутня фізично, її підтверджують чип і PIN-код. В онлайні картки як фізичного об’єкта немає, тому платника підтверджують через інші механізми — 3D Secure та токени Apple Pay / Google Pay. Звідси й специфіка: потенційно вищі ризики шахрайства, особливий порядок суперечок й повернення коштів (chargeback), вимоги PCI DSS до захисту даних та інтеграція платіжної системи з CMS чи бекендом замість підключення терміналу. Окремо потрібна фіскалізація, відтак чимало сервісів додають до послуги програмний РРО – цифровий аналог касового апарату.

Як працюють онлайн-платежі? 

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

1. Ініціація. Покупець вводить дані картки або обирає метод швидкої оплати (Apple Pay / Google Pay / банківський застосунок).
2. Шифрування та авторизація. Платіжний шлюз шифрує дані та передає їх платіжній системі (Visa / Mastercard).
3. Перевірка. Банк-емітент (що випустив картку) перевіряє залишок коштів і проводить ризик-аналіз (3D Secure).
4. Підтвердження. Банк-емітент схвалює операцію, а банк-еквайр надсилає сповіщення мерчанту про успішну оплату.
5. Кліринг та розрахунок. Гроші списуються з картки та зараховуються на розрахунковий рахунок бізнесу (зазвичай протягом 1–2 банківських днів).

Банк-еквайр, платіжний сервіс і платіжний шлюз: хто за що відповідає

На практиці ці ролі часто об'єднані в одному продукті, але функції в них різні:

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

• Платіжний сервіс (PSP / Aggregator) — технологічний провайдер (наприклад, Tranzzo чи iPay), який об'єднує шлюз, кастомізований касовий інтерфейс, маршрутизацію платежів, антифрод-систему та додаткові інструменти (рекуренти, спліт-платежі).

• Банк-еквайр — фінансова установа (наприклад, ПриватБанк, Monobank), яка забезпечує безпосередній процесинг, взаємодію з платіжними системами та проведення фінансових розрахунків на рахунок компанії.

Українська економіка глибоко диджиталізована. Покупець звик до варіативної оплати в пару кліків із додатковими фінансовими інструментами. Базовий набір для українського бізнесу у 2026 році виглядає так:

• Безконтактні методи Apple Pay та Google Pay (забезпечують понад 70–80% усіх мобільних конверсій).

• Прямі банківські push-платежі (Privat24, Monopay).

• Оплата карткою (Visa, Mastercard) з можливістю збереження даних (Tokenization).

• Розстрочки та інструменти BNPL («Оплата частинами» від ПриватБанку, «Покупка частинами» від Monobank тощо).

Якою має бути платіжна система для сайту

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

Відтак функціональний мінімум сучасної платіжної системи для онлайн-бізнесу має надавати такі можливості:

• Онлайн-оплата для інтернет-магазину через картки, Apple Pay та Google Pay: підтримка Visa та Mastercard є базовою умовою, проте понад 70–80% мобільних транзакцій в Україні здійснюються через Apple Pay та Google Pay. Можливість розплатитися в один дотик або за Face ID / Touch ID без ручного введення реквізитів картки суттєво підвищує конверсію касової сторінки.

• Оплата за посиланням, інвойси та платежі без повноцінного інтернет-магазину: інструменти соціальної комерції (Social Commerce) дозволяють приймати оплату через платіжні посилання (Pay-by-Link) чи електронні інвойси в месенджерах (Telegram, Viber), Instagram, email або по телефону. Це ідеальне рішення для продажу послуг, консультацій, торгівлі через соцмережі та B2B-угод, де немає традиційного кошика покупок.

• Рекурентні платежі, токенізація та збереження банківської картки: технологія токенізації (заміна реальних даних картки на безпечний цифровий токен) дозволяє реалізувати функцію One-Click Pay для повторних покупок. Для SaaS-сервісів, підписок, регулярних внесків та сервісів із періодичним списанням коштів це дає змогу налаштувати рекурентні (автоматичні) платежі за розкладом без участі користувача.

• Повернення коштів, часткові повернення та скасування операцій: гнучке управління транзакціями через платіжний API або особистий кабінет. Система має підтримувати двостадійну оплату (холдування/преавторизацію коштів на картці з подальшим списанням), а також швидке повне або часткове повернення (Refund) у разі відсутності товару чи зміни умов замовлення.

• Мультивалютні платежі. Для компаній, які масштабуються на зовнішні ринки або обслуговують іноземних клієнтів, платіжна система має підтримувати динамічну конвертацію валют (DCC), прийом закордонних карток та коректне відображення цін у доларах (USD), євро (EUR) чи інших локальних валютах.

Tranzzo: можливості платіжної платформи для бізнесу

Фінтех-провайдер Tranzzo (або Транзо) пропонує гнучку платіжну інфраструктуру із фокусом на потреби ринків Східної Європи. Його модель поєднує високу технологічність, кастомізований касовий UX та розширені інструменти для управління платіжними потоками. Завдяки власній антифрод-системі та прямим інтеграціям із міжнародними еквайрами платформа забезпечує високий показник проходження платежів (Approval Rate) та максимальну швидкість обробки транзакцій. 

Сервіс надає повноцінний комплекс платіжних інструментів, включаючи безконтактні методи Apple Pay та Google Pay, оплату картками Visa/Mastercard, рекурентні платежі за підпискою, преавторизацію (холдування коштів), сплит-платежі для маркетплейсів, а також інструменти генерації платіжних посилань (Pay-by-Link) та інвойсингу. 

Однією з головних переваг Tranzzo є швидкий та дешевий старт. Платформа пропонує готові модулі та плагіни під популярні CMS (OpenCart, WooCommerce, WordPress, Magento тощо). Для мобільних продуктів надаються зручні SDK (iOS, Android), що дозволяє інтегрувати безшовну оплату безпосередньо в інтерфейс застосунку без редиректів на зовнішні сторінки. 

Інфраструктура севісу надає розширене REST API та SDK для реалізації унікальних платіжних сценаріїв будь-якої складності. Платіжна сторінка (Checkout) підтримує гнучке брендування під корпоративний стиль компанії, адаптивну верстку під будь-які пристрої та можливість проведення платежу у формі кастомного віджета (Iframe або Embedded Form), що зберігає клієнта всередині сайту мерчанта. 

Для якого бізнесу може підійти Tranzzo

Завдяки високій гнучкості та масштабованості платформа стане ідеальним рішенням для:

• e-Commerce та великих інтернет-магазинів з високим обсягом транзакцій;

• SaaS-сервісів, платформ онлайн-освіти та контентних сервісів, що працюють за моделлю підписок та рекурентних списань;

• Маркетплейсів та сервісних платформ, де необхідне автоматичне розщеплення платежів (сплітування) між кількома продавцями чи виконавцями;

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

iPay: що це та як працює прийом платежів

Один із піонерів українського ринку інтернет-еквайрингу (заснований у 2008 році), який відіграв важливу роль у розвитку вітчизняного eCommerce. Сьогодні iPay.ua — це платіжний сервіс-агрегатор (PSP), що виступає універсальним технологічним мостом між бізнесом, банками-еквайрами та кінцевими споживачами. 

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

Понад те, сервіс надає повний спектр інструментів для сучасного e-Commerce: прийом платежів через Apple Pay, Google Pay та картки Visa/Mastercard, підтримку технології Click to Pay, миттєві виплати на картки (P2P-перекази), створення платіжних інвойсів та QR-кодів, рекурентні списання за передплатою, а також холдування (двостадійну оплату). Крім того, iPay пропонує готові рішення для інтеграції з програмними РРО (пРРО) для автоматичної фіскалізації чеків. 

Інтеграція платформи дуже зручна. Для популярних CMS (WooCommerce, OpenCart, Magento, PrestaShop тощо) доступні готові безкоштовні модулі, які дозволяють підключити прийом платежів за декілька годин. Для кастомних сайтів та мобільних застосунків надаються розширені API та SDK, що дозволяють реалізувати як редирект на захищену касову сторінку iPay, так і вбудовану віджетну форму чекауту без переходу на зовнішні ресурси. 

Коли бізнесу варто розглядати iPay 

Сервіс буде оптимальним вибором для таких гравців: 

• малого та середнього e-Commerce, якому потрібен швидкий старт із готовими CMS-модулями та стабільною підтримкою;

• компаній, яким важлива висока відмовостійкість процесингу завдяки мультибанківській маршрутизації платежів;

• бізнесу, якому потрібні комплексні рішення «all-in-one»: інтернет-еквайринг + пРРО + інструменти виплат на картки клієнтам;

• комунальних, освітніх та фінансових сервісів, що потребують специфічних сценаріїв прийому регулярних та масових платежів.

LiqPay та Privat24: інтернет-еквайринг ПриватБанку

Один з найбільших українських банків пропонує бізнесу два пов'язані інструменти для платежів. Перший — LiqPay, сервіс інтернет-еквайрингу банку: він приймає картки, Apple Pay і Google Pay, оплату через PrivatPay та за QR-кодом, підтримує токени для повторних платежів і працює з сайтами, застосунками та платіжними посиланнями. Другий — «Приват24 для бізнесу», застосунок, у якому можна підключити еквайринг і керувати ним.

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

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

Інтеграція з бізнес-системами будується навколо цих самих callback. Статус «оплачено» оновлює замовлення в CMS, передається в CRM чи ERP і запускає відвантаження зі складу. Фіскальні чеки формує програмний РРО, а кошти надходять на рахунок протягом одного банківського дня. Комісія залежить від тарифу й для українських карток становить орієнтовно 1,3–1,5%, актуальні умови подано на сайті LiqPay.

Коли банківський еквайринг може бути вигіднішим за окремий платіжний сервіс

Напряму обирати еквайринг від ПриватБанку доцільно у таких випадках: 

• Рахунок уже в ПриватБанку. Розрахунки відбуваються в межах одного банку, без посередника між бізнесом та еквайром.

• Аудиторія з картками ПриватБанку. Оплата через PrivatPay у звичному інтерфейсі скорочує шлях до покупки.

• Типовий сайт без складної логіки. Один основний метод оплати та готовий модуль для CMS не вимагають окремої платформи.

• Мінімум учасників у ланцюжку. Один договір, один кабінет, програмний РРО в комплекті.

Tranzzo, iPay чи банківський інтернет-еквайринг: що обрати

Вибір між платіжною платформою (Tranzzo), сервісом-агрегатором (iPay.ua) та прямим банківським еквайрингом (наприклад, ПриватБанк чи Monobank) залежить від низки бізнес-факторів та технічних параметрів: архітектури проєкту, обороту, необхідності специфічних платіжних сценаріїв, потрібного рівня кастомізації тощо. Як обрати найкраще рішення? Починати потрібно з пошуку сильних та слабких сторін кожного підходу та порівняння за релевантними аспектами. 

Універсального рішення не існує — вибір залежить від балансу між розміром комісії та потрібним функціоналом. Якщо для базового e-Commerce із рахунком у ПриватБанку цілком достатньо прямого еквайрингу LiqPay із мінімальними витратами, то для складних проєктів із мобільними застосунками, підписками чи мультибанківською маршрутизацією (Cascading) вигідніші агрегатори — Tranzzo або iPay.ua. Їхня трохи вища комісія з надлишком перекривається кастомізованим касовим UX, відмовостійкістю транзакцій та гнучкими сценаріями списань, які істотно підвищують конверсію сайту. 

3D Secure: що це і як захищаються онлайн-платежі

Безпека онлайн-платежів базується на технології 3D Secure (3DS) — це міжнародний стандарт та безпековий протокол для перевірки власника картки під час оплати в інтернеті. Його головна мета — переконатися, що покупку здійснює саме законний власник картки, а не зловмисник, який дізнався її номер чи CVV-код. Назва «3D» походить від трьох доменів (Three Domains), які беруть участь у перевірці: банк-еквайр (що обслуговує сайт), банк-емітент (що видав картку покупцю) та платіжна система (Visa або Mastercard). 

Як 3D Secure працює на практиці? Під час підтвердження платежу покупця перенаправляють на захищену сторінку банку-емітента, де потрібно ввести одноразовий код або підтвердити операцію в мобільному застосунку. Це захищає бізнес від шахрайських транзакцій та несанкціонованих списань. 

У своїй сучасній ітерації EMV 3DS 2.x. протокол позбавив кінцевого користувача від застарілих та незручних інструментів на кшталт SMS-паролів. Тепер підтвердження відбувається за допомогою біометрії (Face ID, Touch ID) або в один клік у банківському застосунку (Privat24, Monobank). Окрім цього, 3DS 2.0 оцінює ризикованість операції у фоновому режимі: якщо платіж безпечний, він проходить миттєво без додаткових дій користувача (Frictionless Flow). 

Одна з найважливіших функцій 3DS — захист бізнесу від чарджбеку (Chargeback) — процедури оскарження платежу покупцем через банк-емітент (наприклад, у разі шахрайства, недоставки товару або невідповідності послуги). Чарджбеки загрожують бізнесу штрафами від міжнародних платіжних систем, а іноді навіть втратою еквайрингового облікового запису. Використання 3D Secure перекладає відповідальність за шахрайські транзакції (Liability Shift) з мерчанта на банк-емітент, захищаючи компанію від збитків. 

Ще один стовп безпеки онлайн-платежів — суворе дотримання стандарту PCI DSS, який чверть століття тому був створений найбільшими міжнародними платіжними системами: Visa, Mastercard, American Express, Discover та JCB. Відповідно до стандарту сервери магазину не зберігають і не обробляють чутливих даних карток (номер картки, термін дії, CVV). Для цього застосовується токенізація — заміна реальних карткових даних зашифрованим цифровим токеном. 

І нарешті, найбільш динамічний контур безпеки – безперервна протидія самих платіжних платформ спробам шахрайства. Сервіси постійно вдосконалюють свої антифрод-системи, аби виявляти будь-які аномалії в платежах та підозрілу активність. Алгоритми машинного навчання дозволяють моніторити кожен платіж в реальному часі, з урахуванням IP-адреси, геопозиції, поведінкових факторів та цифрового відбитка пристрою (Device Fingerprint) за кожним окремим кейсом. 

Як підключити інтернет-еквайринг до сайту

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

1. Реєстрація бізнесу та підготовка документів. Для підписання договору з банком чи PSP-провайдером бізнес має бути офіційно зареєстрований (ТОВ або ФОП). Провайдер проводить перевірку compliance (KYC), під час якої перевіряє виписки з ЄДР, статутні документи, реквізити IBAN та сам сайт. На вебресурсі обов'язково мають бути розміщені публічна оферта, політика конфіденційності, умови повернення коштів та контакти компанії.
2. Вибір способу інтеграції: готовий платіжний модуль чи API. Найпростіший шлях для типових інтернет-магазинів — встановлення готового плагіна для CMS (WordPress/WooCommerce, OpenCart, Magento, PrestaShop). Для кастомних вебсайтів та мобільних застосунків використовують REST API або спеціалізовані SDK, що надають повну свободу в управлінні платіжною логікою.
3. Визначення формату checkout. Бізнес має обрати формат касової сторінки:
   1. Зовнішня (Redirect Checkout): Покупця перенаправляють на захищену сторінку платіжного сервісу (наприклад, LiqPay чи iPay.ua). Це найпростіший спосіб, який значно пом’якшує для мерчанта вимоги щодо сертифікації PCI DSS.
   2. Вбудована (Embedded Form / Iframe / Widget): Форма вводу картки інтегрується безпосередньо в чек-аут сайту через Iframe або SDK (як у Tranzzo). Це створює безшовний UX, покращує конверсію та зберігає єдиний стиль бренду.
4. Налаштування webhook. Аби сервер сайту миттєво дізнавався про результати транзакції, налаштовуються Webhook-повідомлення. Після завершення оплати платіжний шлюз надсилає асинхронний HTTP-запит (callback) на вказаний URL із зашифрованими даними про статус (success, failure, processing).
5. Вихід у тестове середовище та перевірка сценаріїв оплати. Перед запуском підключення онлайн-оплати обов'язково тестується в пісочниці (Sandbox). Розробники перевіряють роботу за допомогою тестових карткових номерів: тестують успішні оплати, відмови (нестача коштів, помилка CVV), скасування операцій, холдування та обробку Webhook-повідомлень.
6. Інтеграція платежів із CRM, ERP та системою обліку. Завершальний етап — автоматизація бізнес-процесів. Зміна статусу платежу через Webhook запускає ланцюжок дій в облікових системах: створення угоди в CRM, оновлення залишків товару в ERP, автоматичну фіскалізацію чека через пРРО та відправку покупцеві сповіщення з чеком і даними про доставку.

Як вибрати платіжний сервіс під конкретну бізнес-модель

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

Інтернет-магазин і класичний e-Commerce

Головні критерії тут — готові модулі для CMS, набір способів оплати та конверсія на checkout. Покупці очікують картки, Apple Pay і Google Pay, а також оплату в застосунку банку. Для типового магазину зазвичай достатньо одного сервісу з одним основним методом. Якщо потрібні фіскальні чеки, зручно, коли програмний РРО вже входить у послугу. Для більшого каталогу й пікових розпродажів додатково оцінюють стабільність шлюзу та наявність резервних маршрутів.

Маркетплейс із платежами між кількома сторонами

Тут платіж потрібно розділити між платформою та продавцями, утримати комісію й виплатити решту. Знадобляться спліт-платежі, виплати на картки чи рахунки та двостадійні операції з холдуванням коштів до підтвердження доставки. У Tranzzo такі функції є в описі платформи, тому маркетплейси часто розглядають саме агрегатори. Для кожного кандидата варто окремо з'ясувати юридичну схему розрахунків із продавцями, адже від неї залежать вимоги до договорів і звітності.

SaaS, підписки та регулярні платежі

Ключова вимога — токенізація карток і списання без повторного введення даних. Також важливі обробка відмов (нестача коштів, прострочена картка), повторні спроби списання та повідомлення клієнтів. Рекурентні платежі підтримують і банківський еквайринг із токенами, як LiqPay, і платіжні платформи. Для Tranzzo Apple Pay та Google Pay для підписок запроваджено ще в 2024 році.

B2B-портал і особистий кабінет клієнта

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

Мобільний застосунок

У застосунку покупець не повинен вводити дані картки вручну, тому пріоритет мають Apple Pay / Google Pay, токени та оплата в один дотик. Ключову роль під час розробки відіграє наявність у платіжного сервісу готових SDK для iOS і Android. Форма оплати має відображатися всередині застосунку, без розриву сценарію переходом у зовнішній браузер. Apple Pay і Google Pay підтверджуються системною автентифікацією: Face ID або Touch ID на iOS, біометрією чи блокуванням екрана на Android. Окремо потрібно перевірити, чи коректно покупець повертається в застосунок після проходження 3D Secure. 

Бізнес із міжнародними клієнтами

Для українського бізнесу, зареєстрованого в Україні, популярні міжнародні платформи на кшталт Stripe чи PayPal недоступні для прийому платежів. Тому оплату від клієнтів із-за кордону зазвичай організовують через українські сервіси з підтримкою іноземних карток або через рішення, що працюють із іншою юрисдикцією. У тарифах за іноземні картки комісія, як правило, вища: у LiqPay вона близько 2% проти 1,3–1,5% для українських. Окремі питання — валюта розрахунків і вимоги валютного регулювання.

Міжнародні платіжні рішення: коли українському бізнесу потрібна альтернатива

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

Amazon Pay: де використовується і чим відрізняється від локального еквайрингу

Гаманець Amazon Pay дає змогу платити на сторонніх сайтах за допомогою даних з акаунта Amazon, без введення картки й адреси доставки. Покупця перенаправляють на сторінку гаманця, де він підтверджує платіж і повертається в магазин. Така оплата скорочує checkout до кількох дотиків. Сервіс орієнтований на США, Велику Британію та Європу.

Принципова відмінність від локального еквайрингу в тому, що Amazon Pay є способом оплати, прив'язаним до акаунта покупця, а не банківською послугою з прийому карток. Підключити його може бізнес, зареєстрований у США, Великій Британії або країнах Європи зі списку Amazon; України в ньому немає. Розрахунки ведуться в іноземній валюті на рахунок у відповідній юрисдикції, а не в гривні.

PayPal та інші міжнародні способи онлайн-оплати

PayPal після березня 2022 року став доступним в Україні, але переважно для фізичних осіб: бізнес-акаунт для прийому платежів від клієнтів відкрити усе ще не можна. Тому підприємці зазвичай реєструють компанію в країні, де це можливо, наприклад у Польщі, а це вже іноземна юридична особа з власними податковими й обліковими наслідками. Актуальні умови варто звіряти з сайтом PayPal.

Ще один популярний сервіс міжнародних платежів, Payoneer, пропонує бізнес-акаунти для підприємців, зокрема деяких ФОП, і призначений переважно для отримання виплат від іноземних платформ і клієнтів. Apple Pay і Google Pay доступні українському бізнесу, бо підключаються через локальні сервіси на кшталт Tranzzo, iPay чи LiqPay.

Коли міжнародний платіжний сервіс не замінює локальну платіжну систему

Попри високий рівень довіри за кордоном, міжнародні платформи не здатні повністю закрити потреби українського бізнесу всередині країни. Вони мають вищі комісії (часто 2.9–4.4% + фіксована плата за транзакцію), недоступні для прямих списань через локальні методи (PrivatPay, QR-коди), не підтримують автоматичну фіскалізацію через український пРРО та створюють складності з прямим виведенням коштів на гривневий розрахунковий рахунок у день транзакції. Без локальних методів частина покупців просто не завершить оплату. Тож міжнародний сервіс здебільшого доповнює локальний еквайринг, а не замінює його. 

Що враховувати під час роботи одночасно з українськими та іноземними клієнтами

• Окремі сценарії оплати. Способи оплати залежать від країни покупця: для України локальні методи, для решти світу міжнародні картки та гаманці.

• Валюта та комісії. За іноземними картками комісія зазвичай вища: у LiqPay орієнтовно близько 2% проти 1,3–1,5% за українськими.

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

• Податки та документи. Продаж цифрових послуг і товарів нерезидентам може мати власні вимоги щодо обліку й ПДВ.

• Ризики шахрайства та chargeback. Для міжнародних платежів вони вищі, тому важливі вимоги 3D Secure 2.0 й впроваджувати антифрод-інструменти.

• Мова та підтримка. Адаптований англомовний інтерфейс і зрозумілі умови повернення коштів знижують кількість суперечок.

Типові помилки під час інтеграції онлайн-платежів

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

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

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

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

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

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

Побудова безшовної та безвідмовної екосистеми eCommerce потребує глибокого розуміння індустрії та неабиякої технічної експертизи у відповідних технологіях. Тож ми не радимо довіряти реалізацію складних сценаріїв оплати та кастомних компонентів UX командам без досвіду — краще звернутися до міцної IT-команди із відповідною репутацією та кейсами. 

FAQ