Payment processing як остання надія Digital products

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Мене звати Володимир Ситніков, я СЕО української мультипродуктової ІТ-компанії Brainstack.

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

Brainstack — одна з небагатьох компаній на українському ринку, яка побудувала власний Billing Engine. Ми знаємо цей процес зсередини: від першого MID до оркестрації десятків провайдерів.

Чому взагалі стався такий швидкий перехід у веб-білінг? Масовий перехід з App Store і Play Store на веб спричинений високими комісіями сторів (15–30%), які при постійному зростанні вартості маркетингу просто не дають компаніям виходити в прибуток. Зараз більшість великих продуктових компаній направляє основний трафік саме на веб.

Друга причина — правила Visa і Mastercard для підписочних продуктів постійно ускладнюються. В 2025 році почала діяти нова програма від Visa. А найближчим часом почне діяти нова програма від Mastercard

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

Білінг-глосарій

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

Чотири шляхи налаштування білінгу

Коли продукт виходить на веб і починає продавати підписки напряму, є чотири базові варіанти, як це організувати.

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

Друге рішення — Merchant of Record (Paddle, PayPro Global, FastSpring). В цьому випадку ви продаєте свої продукти через третю особу, яка бере на себе комплаєнс, податки і всю юридичну відповідальність за транзакції. Зручно на старті або якщо у вас невеликий обсяг і немає ресурсів розбиратися з міжнародним податковим законодавством. Але зі зростанням бізнесу обмеження стають відчутнішими: прохідність гірша, комісії вищі, і ви ніколи не є повним власником своїх підписок.

Третє — взяти third-party оркестрацію (Primer, Payrails, Y.Uno) і добудувати підписочний двигун під свої потреби. Ви берете готову платформу, інтегруєте свої MIDs і не витрачаєте ресурси на побудову з нуля. Менш гнучко, ніж повністю власна система, але значно швидше і дешевше. Пам’ятайте, що в цьому випадку ви завжди будете підтримувати щось на ходу і постійно залежати від беклогу ваших партнерів.

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

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

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

Де виникають проблеми з білінгом

Зі свого досвіду я визначив кілька точок, на які варто звернути увагу.

Зростання chargeback’ів

Chargebacks у підписочному бізнесі зростають з кількох причин одночасно. По-перше, користувач бачить назву у виписці і просто не впізнає продукт: дескриптор не збігається з тим, що він купував, або він забув про підписку. По-друге, користувач може впізнати транзакцію і все одно піти за chargeback’ом, не звертаючись до підтримки. Це досить розповсюджена культура у tier-1 країнах.

Використання лише одного провайдера

Stripe можна отримати за місяць, але так само швидко втратити. На те, аби відкрити будь-який інший провайдер, ви можете витратити 6–12 місяців. Якщо у вас лише один канал, будь-яка технічна проблема або рішення еквайра зупиняє всі продажі.

Недостатня деталізація аналітики

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

Що робити

Усі ці проблеми мають конкретні рішення, розберімо кожне.

Будуйте мультиеквайринг одразу

Один провайдер — це залежність і великий ризик. Відразу майте декілька еквайрів з декількома MIDs у кожному.

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

При виборі еквайрів важливо розуміти їхню спеціалізацію. Одні взагалі не працюють з digital-продуктами або підписками, інші заточені саме під них. Регіон теж має значення — для Європи і для США часто потрібні різні провайдери, оскільки еквайри мають різні ліцензії та присутність на ринках. Окремо варто звертати увагу на ризик-метрики конкретного еквайра: наскільки він лояльний до підписочної моделі і як реагує на chargebacks у вашій ніші.

Налаштуйте каскадинг, retry і локальні методи оплати

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

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

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

Підключайте декілька методів оплати. Не всі користувачі платять виключно карткою. Комусь зручно через PayPal, комусь — через Apple Pay або Google Pay. Десь є місцеві платіжні системи. Поцікавтеся усталеними звичками в різних країнах, аби не втрачати конверсію через незручність методу оплати.

Впровадьте network tokenization і слідкуйте за ризик-метриками

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

Відстежуйте ризик-метрики в реальному часі. Якщо ви бачите, що VAMP Rate, chargeback rate або fraud rate зростають, у вас є вікно, аби розібратися в причині. Можливо, проблема в конкретній кампанії, в певній локалі або в одному типі підписки. Без моніторингу в реальному часі ви дізнаєтеся про проблему тільки тоді, коли еквайр вже закрив канал.

Серед інструментів для зниження chargeback rate — RDR та Ethoca alerts. Це системи раннього попередження від Visa і Mastercard: коли користувач звертається до банку з претензією, мерчант отримує сповіщення ще до того, як диспут офіційно відкритий.

На практиці це виглядає так: ви бачите alert, знаходите цього користувача, повертаєте йому гроші або вирішуєте питання через підтримку, і chargeback просто не з’являється в системі. Це значно дешевше, ніж розбиратися з офіційним диспутом, і не псує ризик-метрики еквайра.

Будуйте глибоку аналітику і перевіряйте інвойси

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

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

Висновки

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

• Підключити мінімум два еквайри
• Налаштувати каскадинг і retry-логіку
• Підключити максимум методів оплати
• Впровадити network tokenization
• Відстежувати ризик-метрики в реальному часі
• Підключити RDR/Ethoca alerts
• Будувати глибоку аналітику
• Перевіряти інвойси від провайдерів, аби не допустити розбіжностей
• Робити refund легко — це дешевше за chargeback і фінансово, і репутаційно

Білінг — це не разова задача, яку один раз налаштували і забули. Тільки системна робота і постійний фокус допоможуть не втрачати зароблені гроші.

Моє особисте прагнення — щоб якнайбільше класних ІТ-продуктів було створено в Україні. Якщо потрібна консультація з білінгу, я готовий до спілкування. Пишіть мені на [email protected]