Як стартапам ефективно обробляти платежі та обирати правильний метод – колонка

Уявімо сценарій: ви CEO або продакт-менеджер нового продукту. Визначили MVP, розробили план розвитку та окреслили першу цільову аудиторію. І ось, на завершення юзерського шляху, ви підходите до одного з найважливіших етапів — платежів. Що робити з ними? Про це в колонці для AIN розповідає Іван Ярошенко, Head of Payments у Kiss My Apps. 

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

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

Розгляньмо основні моделі обробки платежів. 

Повний аутсорс

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

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

Переваги:

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

Недоліки:

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

Децентралізація

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

Важливо зазначити що на ринку існує певна кількість гейтвеїв, яких називають «bank-agnostic». Вони не відповідають за ваші МІДи, оскільки їхнім відкриттям і підтримкою займаєтесь ви децентралізовано.

Це відкриває певні можливості, проте несе й додатковий ризик.

Переваги:

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

Недоліки:

• Ефорт vs Нагорода: така модель вимагає більше командного ресурсу для налаштування та підтримки. При її виборі важливо чітко визначити, яку додаткову цінність ми прагнемо отримати.
• Фокус гейтвею: bank-agnostic гейтвеї часто створювались для потреб певних ніш (наприклад, ритейлу чи підписочних сервісів), тож функціонал може відрізнятися. Наприклад, функції повторного проведення транзакцій важливіші для підписочних сервісів, ніж для транзакційного бізнесу. Варто переконатися, що гейтвей має потрібний саме вам функціонал для вашої бізнес-моделі/ніші.

Merchant of Record (MoR)

Ця модель є однією з найефективніших для швидкого запуску нового вебпродукту, адже дозволяє використовувати «чужу» інфраструктуру, включно з рахунками (MID). Серед популярних провайдерів цієї моделі — FastSpring і Paddle.

Податкова звітність, комплаянс, додавання нових методів оплат і все, що пов’язане з платежами — повністю делегується на підрядника. З 1 січня 2024 року в ЄС набрала чинності директива, що регулює сплату ПДВ (VAT) для цифрових продуктів, через що рішення на основі MoR стало особливо актуальним. У більшості це пов’язано з тим що фінансово-юридична інфраструктура деяких компаній не була готова для прозорого процесу збору і сплати VAT в Європі.

Юридично модель MoR на вигляд така, ніби ваш продукт перепродається підрядником, що дозволяє йому надати вам доступ до своїх MID-рахунків.

Переваги: 

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

Недоліки:

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

Підсумок

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

Автор: Іван Ярошенко, Head of Payments у Kiss My Apps

Читайте також: Масштабування без хаосу. Коли та як впроваджувати нові процеси в продуктових компаніях — колонка