Платіжний шлюз: як обрати й підключити оплату на сайті

Шлюз, провайдер та оркестратор виконують різні завдання

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

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

Переглянути інструменти для розробників

Спершу перевірте відповідність вашому бізнесу

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

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

Дізнатися про оркестрацію платежів

Оберіть спосіб інтеграції під свій процес продажу

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

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

Налаштувати платіжні сповіщення

Зв’яжіть платіж із замовленням на сервері

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

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

Повернення покупця не дорівнює підтвердженню оплати

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

Документація Mollie радить отримувати стан платежу через API після сповіщення; повернення покупця може відбутися раніше за webhook. У власному процесі передбачте зрозумілий стан очікування та повторне отримання результату. Не показуйте остаточне «оплачено» лише тому, що відкрилася певна адреса. Водночас не змушуйте клієнта платити повторно, поки результат попередньої спроби залишається невідомим.

Webhooks потребують перевірки та обробки повторів

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

OrsunPay надає підписані сповіщення та інструкції перевірки HMAC-SHA256 за початковими байтами тіла запиту. У застосунку потрібно уникнути повторної видачі товару чи активації послуги, якщо одна подія надійшла двічі. Зберігайте достатньо ідентифікаторів для розслідування, але не записуйте зайві платіжні або персональні дані в журнали. Визначте окремий порядок роботи з невдалою доставкою повідомлень.

Повтор запиту має зберігати бізнес-сенс

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

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

Не приписуйте оркестрації функції автоматично

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

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

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

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

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

Почніть із обмеженого перевірюваного запуску

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

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

Джерела

• Mollie: процес приймання платежів
• Stripe: документація webhooks