Для SaaS — програмних продуктів, якими користуються онлайн, часто за підпискою, — платіжний провайдер може здаватися переважно технічним питанням: інтегрувати сервіс, перевірити оплату в тестовому середовищі та перейти до реальних транзакцій. Але технічно готова інтеграція ще не означає, що провайдер погодиться працювати з конкретним бізнесом. На думку Миколи Орленка, якщо значна частина платіжної логіки продукту залежить від одного сервісу, його відмова може відкласти запуск і призвести до перебудови платіжної архітектури.
У статті Микола розповідає, чому після відмови платіжної платформи Stripe вирішив не просто підключити іншого провайдера, а перебудувати платіжну архітектуру продукту. А також пояснює, коли залежність від одного платіжного сервісу стає ризиком, навіщо відокремлювати логіку продукту від конкретного провайдера та що варто перевірити SaaS перед інтеграцією платіжного сервісу.
Чому я обрав Stripe
Для SonikaAI мені були потрібні два сценарії: регулярні платежі за підпискою та разові покупки, наприклад доповнення до неї. Stripe підтримував обидва, тому для невеликого сервісу це давало змогу швидше запустити оплату.
До побудови інтеграції я повністю пройшов верифікацію акаунта й бізнесу. Після цього налаштував оплату, підписки та сповіщення про зміну статусу платежу й перевірив усе в тестовому середовищі.
Технічно сценарії працювали, а верифікація була пройдена. Тому на той момент я не очікував, що проблема виникне вже після переходу до реальних платежів.
Що сталося після переходу з тестового режиму
21 квітня 2026 року я перейшов у робочий режим і зробив власний тестовий платіж. Через два дні Stripe повідомив, що після планової перевірки акаунта виявив високий ризик спорів і більше не прийматиме платежі для SonikaAI.
Виплати з платіжного балансу також призупинили до 21 серпня 2026 року. Я подав апеляцію та необхідні документи, але після повторної перевірки Stripe залишив рішення чинним, пославшись на неприйнятний рівень ризику.
Робити висновки про політику Stripe з одного випадку я не буду. Але цей досвід показав мені різницю між кількома етапами, які до цього здавалися частинами одного процесу. Тестове середовище дало змогу перевірити платіжні сценарії, а верифікація — пройти перевірку акаунта й бізнесу. Проте після першого платежу в робочому режимі Stripe повторно перевірив акаунт і вирішив припинити його обслуговування.
Для бізнесу тут є ще один ризик: у разі обмеження акаунта недоступними можуть стати не лише нові платежі. У моєму випадку виплати з балансу залишалися призупиненими майже чотири місяці. Такий сценарій також варто враховувати під час планування фінансового резерву. Але найбільшою проблемою для мене виявилася навіть не сама відмова. Вона показала, наскільки платіжна логіка продукту залежала від Stripe.
Особливо це стосувалося підписок: коли списувати наступний платіж і що відбувається наприкінці оплаченого періоду. У Stripe регулярні списання веде сам провайдер. У Mollie, який я обрав пізніше, спочатку потрібна перша оплата, що дає дозвіл на повторні списання, і лише після неї створюється підписка. Тому заміна одного провайдера іншим означала б зміни не лише в інтеграції, а й у правилах роботи самого продукту.
Чому я одразу не почав шукати заміну Stripe
Найшвидшим рішенням було підключити іншого провайдера, переписати інтеграцію під нього й запустити оплату. Але продукт залишився б так само залежним від зовнішнього сервісу. Наступна відмова, зміна умов або вихід на ринок, де цей провайдер не працює, знову могли б потребувати перебудови. Тому я вирішив спочатку визначити, яка частина платіжної логіки має залишатися всередині продукту, а за що повинен відповідати провайдер. Правила про те, що купує клієнт, коли активується доступ і яку оплату вважати успішною, я залишив на стороні продукту.
Я вирішив залишити всередині продукту правила, які визначають, що купує клієнт, коли активується доступ і який стан оплати продукт вважає успішним. Провайдер відповідає безпосередньо за проведення платежу.
На перебудову платіжної частини пішло близько півтора тижня — з 24 квітня до 2 травня. За цей час я відокремив спільну логіку, створив адаптер для Mollie, журнал платежів і ручну оплату. Це не разові витрати. Для кожного наступного провайдера потрібні окремий адаптер, налаштування й тестування. Тому зараз я не став би радити кожному молодому SaaS одразу будувати складну систему для кількох провайдерів. Але одну річ після цього досвіду я робив би із самого початку: правила про те, що купив клієнт і коли він отримує доступ, тримав би в самому продукті, а не в інтеграції з конкретним платіжним сервісом.
Як я відокремив платіжну логіку від провайдера
Якщо пояснювати без коду, система тепер складається з двох рівнів.
Перший рівень — спільна частина платіжної системи. Він відповідає за:
- створення оплати та її шлях від наміру заплатити до завершення;
- спільний набір статусів для різних способів оплати;
- журнал подій, що надходять від провайдерів;
- інформацію про можливості кожного провайдера, наприклад підтримку підписок.
Другий — адаптери провайдерів. Кожний із них працює з API конкретного сервісу, приймає та перевіряє його сповіщення, а потім передає дані у спільну частину платіжної системи в єдиному форматі. Бізнесові правила продукту в адаптерах не зберігаються.
1. Продукт створює намір оплати й перевіряє необхідні згоди користувача.
2. Система визначає провайдера. Адаптер Mollie створює першу оплату та повертає посилання для переходу на сторінку оплати.
3. Користувач оплачує підписку на сторінці Mollie. Поки платіж не підтверджено, він має статус «очікує».
4. Mollie надсилає сповіщення про платіж. Після цього адаптер додатково запитує його статус у Mollie та передає підтверджені дані в платіжну систему.
5. Система записує оплату в журнал, створює регулярну підписку й активує доступ до продукту.
Від відмови Stripe до перших реальних оплат через Mollie минуло 50 днів. Ось як розвивалися події:
- 23 квітня — Stripe повідомив про припинення обслуговування акаунта;
- 24–25 квітня — почалася перебудова платіжної логіки;
- 2 травня — були готові інтеграція з Mollie, журнал платежів і ручна оплата;
- 12 червня — пройшли перші реальні оплати через Mollie.
Тобто майже сім тижнів пішли не лише на технічну перебудову. Частину цього часу я використав для перевірки системи й перегляду моделі ціноутворення.
Навіщо я додав ручну оплату та єдиний журнал
Окремим способом стала ручна оплата. Вона потрібна для індивідуальних пропозицій і клієнтів, яким зручніше платити за рахунком. Такий платіж проходить окремим офлайн-сценарієм, але потрапляє в той самий журнал, що й онлайн-оплати. Для ручної оплати потрібне підтвердження — номер рахунку або банківський референс.
Єдиний журнал дає змогу в одному місці побачити, чи оплатив клієнт послугу, коли це сталося і яким способом. Це спрощує кілька сценаріїв:
- підтримку — якщо клієнт повідомляє, що заплатив, але не отримав доступ, не потрібно перевіряти кілька систем;
- звірку платежів — записи можна порівняти з даними Mollie та банківськими виписками;
- роботу з даними — у журнал потрапляють підтверджені платежі, а адміністративні зміни доступу чи ціни без фактичної оплати не записуються як платежі.
Зараз у продукті фактично працюють два способи оплати: Mollie та ручна оплата. Stripe після відмови не використовується. Архітектура технічно дає змогу працювати з кількома онлайн-провайдерами й зберігати інформацію про те, через кого оформлено підписку клієнта. Але на практиці я ще не переводив клієнтів від одного онлайн-провайдера до іншого, оскільки Stripe відмовив до запуску реальних оплат.
Які обмеження залишаються
Така платіжна архітектура не робить провайдерів повністю взаємозамінними. Для нового сервісу все одно потрібно створити адаптер, налаштувати його та протестувати. Можуть відрізнятися й окремі операції. Наприклад, у моїй нинішній інтеграції з Mollie оформлення, продовження та скасування підписки автоматизовані, а повернення коштів я виконую вручну в кабінеті провайдера. В іншого сервісу цей процес може бути організований інакше.
Тому така архітектура не дає змоги просто перемикатися між будь-якими провайдерами. Її перевага в іншому: якщо потрібно підключити новий сервіс, бізнесові правила продукту не доводиться переносити до нової інтеграції. Водночас така побудова платіжної системи не гарантує, що інший провайдер погодиться працювати з бізнесом. Вона лише зменшує кількість змін у продукті, якщо платіжний сервіс доведеться замінити.
Коли варто відокремлювати логіку продукту від платіжного провайдера
Після цього досвіду я не вважаю, що кожному SaaS на старті потрібна архітектура, розрахована на роботу з кількома платіжними провайдерами. Прямої інтеграції з одним провайдером може бути достатньо, якщо продукт ще перевіряє попит, працює на одному ринку, використовує одну валюту й має один чи два прості сценарії оплати.
Залежність від одного провайдера стає більшим ризиком, якщо:
- блокування акаунта зупинить усі надходження і запасного способу приймати платежі немає;
- правила про те, що купив клієнт і коли він отримує доступ, уже закладені в код інтеграції;
- продукт виходить на ринки або додає способи оплати, які поточний провайдер не підтримує;
- через зміну умов або комісій бізнес розглядає інших провайдерів, але для переходу потрібно змінювати сам продукт.
Якби я починав розробку заново, то з першого дня залишив би бізнесові правила оплати в продукті, але не будував би систему для роботи з кількома провайдерами. На старті вистачило б спільних статусів платежів, журналу подій та адаптера для одного сервісу.
Можливість працювати з кількома провайдерами я додавав би тоді, коли з’явилася б реальна потреба підключити другий. Водночас запасний спосіб прийняти оплату я передбачив би раніше. Це не обов’язково має бути ще один повністю інтегрований провайдер. У моєму випадку таким резервним каналом стала ручна оплата за рахунком.
Що ще змінилося перед запуском оплат
Паралельно з перебудовою платіжної системи я переглянув модель ціноутворення. Початкова тарифна схема виявилася складнішою, ніж потрібно на старті. Тому публічну тарифну сітку я скоротив до трьох рівнів, а складніші індивідуальні пропозиції виніс за її межі.
Також я порахував, з чого складається вартість обслуговування клієнта, який повністю використовує місячний ліміт. До розрахунку входили витрати на зовнішні сервіси для перекладу й озвучення, запас на повторні операції та резервні маршрути, а також комісія платіжного провайдера. Найдорожчим сценарієм виявився клієнт, який на повному ліміті використовує і переклад, і озвучення. Тому межі тарифів я визначав за таким сценарієм, а не за середнім використанням.
У результаті до запуску реальних оплат я не лише змінив платіжну архітектуру, а й спростив тарифну модель та точніше порахував витрати на обслуговування клієнтів.
Що SaaS варто перевірити до інтеграції платіжного провайдера
Після цього досвіду я виділив кілька речей, які варто перевірити ще до того, як платіжний провайдер стане частиною продукту.
- Не сприймати пройдену верифікацію як гарантію подальшої роботи. Я перевірив, що Stripe підтримує потрібні мені сценарії, і повністю пройшов верифікацію. Відмова прийшла вже після першого реального платежу, за результатами планової перевірки ризиків. Тому бізнесу варто заздалегідь продумати, що він робитиме, якщо провайдер зупинить акаунт після запуску.
- З’ясувати, що станеться з коштами в разі закриття або обмеження акаунта. У моєму випадку Stripe призупинив виплати майже на чотири місяці. Такий сценарій варто враховувати під час планування фінансового резерву.
- Перевірити, як провайдер працює з підписками. У Stripe регулярними списаннями керує провайдер. У моїй інтеграції з Mollie спочатку потрібна перша оплата й дозвіл на повторні списання, після чого створюється підписка. Від цього залежить, яку частину логіки потрібно реалізувати в самому продукті.
- Перевірити умови та процес повернення коштів. Вони можуть відрізнятися залежно від провайдера. У моїй нинішній інтеграції повернення виконуються вручну в кабінеті Mollie, тому цей процес залишається прив’язаним до конкретного сервісу.
- Визначити власні статуси платежів для продукту. Замість того щоб будувати логіку навколо статусів конкретного провайдера, краще мати спільний набір, наприклад «створено», «очікує», «оплачено», «не вдалося», «скасовано» або «прострочено», і приводити до нього дані від різних сервісів.
- Передбачити запасний спосіб приймати оплату. У моєму випадку це ручна оплата за рахунком з обов’язковим підтвердженням. Вона потрапляє до того самого журналу, що й онлайн-платежі.
- Зберігати інформацію про те, через якого провайдера оформлено клієнта. Навіть якщо зараз сервіс працює лише з одним провайдером, ці дані спростять роботу, якщо згодом потрібно буде додати або замінити платіжний сервіс.
