Два бренди онлайн-фінансування однієї компанії — і в кожного свій сайт та свій особистий кабінет, через який клієнт проходить увесь шлях. Ми підтримуємо й доробляємо сайти й кабінети обох брендів, а наявні iOS- і Android-застосунки одного з брендів переписали на Flutter і супроводжуємо в App Store та Google Play. Компанія — ліцензована фінансова установа під наглядом НБУ. Її назву не розкриваємо: проєкт під NDA.
Клієнт: фінансова компанія на регульованому ринку
Компанія перебуває в реєстрі НБУ як небанківська фінансова установа й працює за ліцензією регулятора. Під двома брендами вона пропонує онлайн-фінансування приватним особам, і весь шлях клієнта дистанційний: від заявки до останнього платежу не треба ні приходити в офіс, ні підписувати паперові документи. До проєкту входять також iOS- та Android-застосунки одного з брендів. Ними вже користуються клієнти, тож кожен реліз одразу потрапляє до реальних користувачів.
Вимоги до такого продукту задають одразу кілька сторін. НБУ визначає, що має бути на сайті й як ідентифікувати клієнта без особистої зустрічі, закон — як укладається й змінюється договір, App Store і Google Play — що дозволено фінансовому застосунку. Кожна з цих вимог зрештою стає конкретним екраном, полем чи кроком у шляху клієнта.
Два бренди — дві окремі системи
У кожного бренду свій сайт і свій особистий кабінет, тож бренди працюють як дві окремі системи, що не залежать одна від одної. Спільні в них лише ліцензія, регулятор і вимоги закону. Ось за що в цих системах відповідає ANIART:
| Шар | Що всередині | Роль ANIART |
|---|---|---|
| Публічні сайти (по одному на бренд) | Своя подача й аудиторія, однакові обов'язкові розділи за вимогами НБУ | Підтримка й доробки |
| Особисті кабінети (окремий у кожного бренду) | Увесь шлях клієнта: вхід, заявка, ідентифікація, підписання, виплата, погашення, зміни умов, картки, історія договорів | Підтримка й доробки |
| Мобільні застосунки одного з брендів (iOS і Android) | Нативна оболонка навколо кабінету цього бренду: JS-міст, push-сповіщення, глибокі посилання | Переписали на Flutter, супроводжуємо в App Store і Google Play |
Шлях клієнта: від входу до останнього платежу
Нижче — шлях клієнта в кабінеті бренду, застосунки якого ми переписали. Кабінет другого бренду — окрема система, яка відповідає тим самим вимогам закону й регулятора.
- Вхід. Номер телефону й одноразовий код через SMS або месенджер — замість пароля.
- Заявка. Анкета онлайн. Одночасно може бути відкритий лише один договір.
- Ідентифікація. На вибір — кілька дистанційних способів, серед них BankID НБУ, Дія та відеоверифікація; частину з них доповнює селфі з перевіркою «живості». Глибина перевірки залежить від суми: нижче порогу достатньо базової онлайн-ідентифікації, вище потрібна розширена.
- Умови й підписання. Клієнт обирає умови й може застосувати промокод програми лояльності. Далі — два кроки з окремими одноразовими кодами: спершу документ із переддоговірною інформацією, потім — сам договір.
- Виплата. Тільки на власну картку клієнта або на його IBAN. Збережені картки відображаються в маскованому вигляді, а змінити картку можна заявою, підписаною одноразовим кодом.
- Погашення й зміни. Оплата в кабінеті або без входу в нього — за реквізитами договору, під захистом reCAPTCHA; платіжного провайдера обирає сервер. Онлайн доступні й дострокове погашення, додаткові кошти в межах ліміту та реструктуризація: новий графік платежів і додаткова угода, підписана кодом.
Регулятор і закон: що стоїть за сайтами й кабінетами
| Вимога | Що це означає для сайтів і кабінетів |
|---|---|
| Розкривати на сайті істотні характеристики послуг, попередження, приклади розрахунку, посилання на реєстр НБУ й порядок подання скарг | На сайтах обох брендів — блок розкриття інформації за вимогами НБУ; калькулятор вартості показує реальну річну ставку |
| Не змінювати умови договору в односторонньому порядку | Додаткові кошти, реструктуризація й інші зміни — лише через оферту, яку клієнт підписує в кабінеті: документ і підпис, а не перемикач в адмін-панелі |
| Доступність для людей з інвалідністю (вимоги НБУ) | На сайтах — режим доступності: підвищений контраст, світла й темна теми, збільшений шрифт |
Що ми зробили: переписали застосунки на Flutter
В одного з брендів уже були застосунки для iOS та Android. Ми переписали обидва на Flutter і супроводжуємо їх: збираємо, публікуємо, проводимо через модерацію App Store і Google Play, виправляємо й оновлюємо.
Переписувати застосунок, яким уже користуються, складніше, ніж запускати новий: користувачі мають у ньому чинні договори, графіки платежів, збережені картки й історію. Тут допомагає архітектура. Кабінет бренду — вебзастосунок на Laravel і Vue 3, а новий застосунок — нативна оболонка навколо нього: фінансові правила й дані залишаються в кабінеті бренду, а застосунок відповідає лише за те, що потребує нативного коду.
Один код — дві платформи
Версії для iOS та Android зібрані з однієї кодової бази на Flutter: більшість виправлень і нових функцій робимо один раз для обох платформ.
Міст із кабінетом
У застосунку той самий кабінет, що й у браузері. Через JS-міст кабінет знає, звідки прийшла сесія — із застосунку чи з вебу.
Повернення з Дії
Після підтвердження в Дії клієнт повертається в застосунок і продовжує оформлення, а не губиться між застосунками.
Push-сповіщення
Нативні сповіщення через Firebase Cloud Messaging — окремий канал поряд із web push на сайті бренду.
Глибокі посилання
Universal Links та App Links: посилання з сайту бренду чи повідомлення відкриває потрібний екран застосунку.
Сучасні платформи
Нові версії зібрані під сучасні iOS та Android; мінімальну підтримувану версію Android підвищено.
Дві швидкості змін
Зміни в логіці заявки, підписання чи погашення ми вносимо в кабінет, і вони доходять до користувачів застосунку без нового релізу в магазинах. Нативний шар — сповіщення, глибокі посилання, повернення з Дії — ми змінюємо в єдиному Flutter-коді для iOS та Android, а платформні частини й публікацію ведемо окремо для кожної платформи.
Реліз фінансового застосунку — окрема дисципліна
App Store і Google Play перевіряють фінансові застосунки суворіше за звичайні: у Google Play діє окрема політика щодо фінансових послуг, в Apple — спеціальні правила App Review. Тому кожен реліз проходить прискіпливу модерацію, і це не формальність. Ми ведемо кожен реліз від збірки до публікації в обох магазинах.
Підтримка й доробки
Крім застосунків, ми постійно працюємо із сайтами й кабінетами обох брендів:
- доробки — нові сценарії, розділи й виправлення в обох системах;
- зовнішні сервіси — BankID НБУ й Дія, омніканальний чат і месенджери, web push, Google Tag Manager і GA4, обмін даними з обліковими системами (ERP): стежимо, щоб ці зв'язки працювали після кожної зміни;
- захист — reCAPTCHA на вході, реєстрації та оплаті без входу, відбиток пристрою, одноразові коди на кожному кроці підписання, Cloudflare перед публічними сайтами: доробки робимо так, щоб жодна нова функція не відкривала обхідного шляху повз ці шари.
Результат
Застосунки одного з брендів переписано на Flutter: одна кодова база для iOS та Android, власний нативний шар — сповіщення, глибокі посилання, повернення з Дії — і той самий кабінет, що й у браузері. Одна команда ANIART супроводжує обидві незалежні системи, тобто сайт і кабінет кожного бренду, а також застосунки одного з брендів — від сторінки бренду до релізу в App Store і Google Play.
Розвиваєте фінансовий продукт у регульованому середовищі, ведете кілька брендів або плануєте переписати на Flutter застосунок, яким уже користуються? Подивіться, як ми працюємо з фінтех-проєктами й мобільними застосунками, або зв'яжіться з нами.
