Платіжний продукт: де починається складність, яку не видно в прототипі

Головне для продуктового рішення

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

Практичний розбір

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

Що відбувається, коли сервіс виходить за межі демо:

• Транзакція підписана, але не підтверджена. Користувач бачить у гаманці pending-статус. У вашому інтерфейсі — що? «Очікуйте»? «Помилка»? Чи зараховуєте ви кошти після першого підтвердження, чи чекаєте на фіналізацію?
• Транзакція відхилена мережею. Причина може бути різною: недостатній баланс для комісії, спроба дублювання, перевищення ліміту блоку. Чи показуєте ви користувачу зрозумілу причину чи загальне «Щось пішло не так»?
• Курс змінився між моментом формування угоди та її підтвердженням. Якщо ви приймаєте платежі з прив’язкою до фіату, ця різниця — ваша або ваша клієнта. Хто її несе?
• RPC-вузол повернув застарілі дані. Ваш сервіс думає, що транзакція не пройшла, а вона пройшла через інший вузол. Дублювання платежів або втрата коштів.
• MEV-перехоплення. Бот змінив порядок транзакцій у блоці, і сума або одержувач виявилися іншими. Користувач заплатив, але не вам.

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

Другий шар складності — reconciliation, або звірка. Коли через ваш сервіс проходять десятки або сотні транзакцій на добу, вам потрібна система, яка відповідає на питання: «Чи збігається те, що ми очікували отримати, із тим, що реально надійшло щодо?». Це окремий інженерний завдання, яке не має нічого спільного з UI кнопки «Оплатити».

Третій шар — повернення коштів. Якщо товар не доставлено, сервіс несправний або користувач помилився сумою, хто ініціює повернення? Хто платить комісію мережі? Як це відображається в обліку? У прототипі повернень немає. У реальному продукті вони неминучі.

Хто має врахувати цей фактор

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

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

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

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

Типові помилки

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

Помилка 2: ігнорувати залежність від інфраструктури. Ваш платіжний продукт працює через RPC-вузли сторонніх провайдерів. Якщо вони затримують відповіді або повертають неконсистентні дані, ваш продукт виглядає зламаним, хоча ваш код правильний. Перевірте, чи має ваш провайдер SLA (гарантовані показники доступності), і що відбувається, коли він не виконує зобов’язань.

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

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

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

Наступний практичний крок

1. Перелічити всі стани транзакції, які може згенерувати ваша система, і для кожного визначити: що бачить користувач, що записується в логи, що робиться з коштами. Якщо хоча б для одного стану відповідь «поки не знаємо» — продукт не готовий до реальних платежів.
2. Перевірити, як ваш сервіс поводиться при відключенні RPC-вузла. Спосіб перевірки: тимчасово змінити endpoint на недійсний і подивитися, що покаже інтерфейс користувачу. Чи є зрозуміле повідомлення? Чи зберігається стан угоди для повторної спроби?
3. Оцінити, чи потрібен вам платіжний продукт як ядро бізнес-модулі, чи достатньо інтегрувати існуюче рішення. Перегляньте продукти, що вже працюють в екосистемі, перед тим як будувати власний.
4. Якщо ви сумніваєтеся, чи блокчейн взагалі потрібен для вашого завдання, пройдіть через критерії з матеріалу «Коли не варто будувати на блокчейні, навіть якщо грант доступний».
5. Для загального орієнтування в тому, що будувати в екосистемі, корисно переглянути огляд напрямків та загальний маршрут від ідеї до продукту.

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