Платіжні шлюзи для магазину: як порівняти повну вартість

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

Нижче — спосіб порівняти LiqPay, WayForPay та інші доступні вам рішення без універсального рейтингу. Міжнародний сервіс на кшталт Stripe додавайте до списку лише після перевірки доступності для вашої юридичної особи.

Спочатку визначте, що саме ви купуєте

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

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

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

Зберіть повну вартість, а не одну ставку

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

Регулярні платежі та утримання

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

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

Гроші, які тимчасово недоступні

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

Технічні витрати — аналіз, модуль або власна інтеграція, обробка статусів, зв’язок з обліком, тести, моніторинг і підтримка. Модуль треба перевірити на сумісність із вашою CMS. Для ширшого бюджету є матеріал що впливає на вартість магазину протягом трьох років; тут рахуємо платіжний контур.

Порівняйте кандидатів за перевірюваними критеріями

Документація LiqPay описує Checkout із платіжною сторінкою провайдера, прямим списанням, блокуванням коштів та підпискою. У WayForPay Purchase також описана захищена сторінка, повернення покупця через returnUrl і окреме сповіщення продавця через serviceUrl. Це відправні точки для технічного порівняння, а не доказ однакових тарифів або однакової доступності функцій.

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

Порахуйте однаковий кошик операцій

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

Умовний приклад, не ринкові тарифи: магазин має 1 000 успішних оплат по 800 грн. Пропозиція А — 1,5% плюс 2 грн за оплату, пропозиція Б — 1,8% без фіксованої частини. За цими припущеннями А коштує 14 000 грн, Б — 14 400 грн. Різниця становить 400 грн, а не всю різницю між відсотками. Приклад навмисно не враховує повернення, валютні операції та інші можливі платежі.

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

Перевірте, як магазин дізнається про оплату

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

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

Умовний сценарій із затриманим підтвердженням

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

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

Пройдіть приймання до запуску реклами

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

1. Звірте суму, валюту й номер замовлення між кошиком, запитом і записом платежу. Перевірте знижку та зміну складу кошика.
2. Пройдіть успіх, відмову, перерване підтвердження банком і закриту вкладку. Покупець має розуміти поточний стан і наступну дію.
3. Перевірте затримане й повторне серверне повідомлення. Окремо переконайтеся, що непідтверджене повідомлення не змінює стан оплати.
4. Виконайте погоджені сценарії повного й часткового повернення. Зіставте залишок до повернення та записи магазину й провайдера.
5. Звірте звіт операцій із замовленнями та обліком. Для робочого середовища за затвердженою процедурою перевірте також фактичне надходження виплати.
6. Перевірте мобільний шлях, доступи співробітників, сповіщення про збої та інструкцію підтримки. Збережіть результати й відповідальних за виправлення.

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

Строки, ризики та остаточне рішення

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

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

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

Підготуйте паспорт продажів, відповіді провайдерів і перелік проблем чинної оплати. З ними зверніться до GL.ua (Глянець), щоб обговорити платіжну інтеграцію в межах розробки чи розвитку інтернет-магазину. Конкретний наступний результат — погоджені сценарії, межі робіт і критерії приймання, за якими можна оцінити бюджет без здогадок.