Два шляхи до робочої платіжної платформи
Будь-який PSP чи фінтех, який хоче проводити платежі для мерчантів, зрештою обирає між двома шляхами. Перший — побудувати платіжну платформу власними силами: гейтвей, панель мерчанта, роутинг провайдерів і бек-офіс, які створює внутрішня команда розробників і яку сама ж команда потім підтримує. Другий — працювати на платформі, подібній до omwio, де мерчанти, транзакції, кошельки, роутинг, чекаут і бек-офіс вже існують як єдиний пов'язаний продукт. Нижче розглянуто, що насправді означає кожен із цих шляхів, виходячи з того, що покриває власний набір функцій omwio.
Що означає розробка власними силами
Розробка власними силами означає зібрати кожен рівень самостійно: гейтвей, що взаємодіє з провайдерами, панель мерчанта для онбордингу та підтримки, рівень роутингу, який визначає, який провайдер обробляє яку транзакцію, і бек-офіс, що відстежує баланси, диспути та звітність. Усе це проєктує, будує і тестує внутрішня команда, і та ж команда відповідає за підтримку після запуску — виправлення, розширення та синхронізацію зі змінами провайдерів з часом.
Що вже охоплює ядро omwio
Ядро omwio — це база, на якій працює кожен тенант, і вона присутня в кожному тарифному плані. Воно охоплює онбординг мерчантів із тарифами, комісіями та індивідуальними налаштуваннями; єдину модель транзакцій, яка однаково обробляє платежі, виплати, обміни, повернення та чарджбеки, з одним спільним статусом, який бачать мерчанти; мультивалютні кошельки з історією балансу; керування провайдерами та MID з попереднім переглядом визначення маршруту до того, як трафік його досягне; хостовану сторінку чекауту та підписане Processing API; інвойси та зашифрований довідник клієнтів; структурований робочий процес диспутів із файлами-доказами; аналітику конверсії та провайдерів; валютні пари, фіксацію курсів та обміни між мерчантами; а також рольовий доступ із двофакторною автентифікацією, контролем сесій та журналом аудиту. У проєкті «зроби сам» кожен із цих пунктів — це обсяг роботи, який внутрішня команда має спроєктувати і взяти на себе.
Опціональні модулі замість опціонального обсягу роботи
Окрім ядра, omwio пропонує модулі, які тенант може включати чи вимикати залежно від тарифного плану: інбокс підтримки, прив'язаний до транзакції, про яку запитує мерчант, AI-шар, що формує чернетки відповідей у цьому інбоксі, моніторинг стану провайдерів і маршрутів зі сповіщеннями, прив'язаними до конкретного MID, а також модуль обліку та звірки, що охоплює казначейство, щоденний P&L, який закривається і виправляється лише датованим реверсом, фінансовий реєстр для грошей, що рухаються поза транзакціями, та зіставлення виписок із транзакціями платформи. Увімкнення чи вимкнення цих модулів відкриває або закриває відповідні пункти навігації панелі та маршрути API. У власній розробці ті самі можливості — черга підтримки, моніторинг провайдерів, процес звірки — кожна стала б обсягом роботи, яку внутрішня команда проєктує, будує і підтримує за власним графіком.
У чому насправді полягає різниця
Матеріал не каже, який підхід дешевший, забезпечує вищий рівень підтверджених транзакцій чи підходить для будь-якої операції — це залежить від факторів, що виходять за межі описаного тут. Те, що матеріал підтверджує, — це різниця у стартовій точці та в тому, хто потім відповідає за підтримку: розробка власними силами починається з порожнього гейтвею, панелі, рівня роутингу та бек-офісу, які внутрішня команда проєктує і далі підтримує в актуальному стані; тенант на omwio починається з цих частин, вже пов'язаних між собою, і включає чи вимикає опціональні модулі залежно від тарифного плану в міру зміни потреб. Який із цих двох стартових станів підходить конкретній операції — рішення, яке кожен PSP чи фінтех приймає на власних умовах.
