Розробка мобільного додатку для страхування (InsurTech)

Розробка мобільного додатку для страхування (InsurTech)

Наша команда мобільних розробників має 10+ років досвіду в InsurTech. За цей час ми реалізували понад 15 проєктів для страхових компаній і брокерів. Наші додатки проходять модерацію App Store та Google Play з першого разу. Гарантуємо стабільну роботу під навантаженням до 100 000 користувачів.

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

Як розробити мобільний додаток для страхування, який вирішує реальні проблеми?

Оформлення полісу онлайн

Калькулятор страховки — перший екран для нового користувача. Каско: марка, модель, рік, потужність, регіон, стаж водія → розрахунок вартості. ОСАГО: дані авто та водіїв → тариф. Технічно це серія залежних запитів: вибір марки → завантаження моделей → вибір моделі → завантаження комплектацій. Autocomplete з дебаунсом для пошуку по базі авто. Кешуємо довідники (марки, регіони) на добу — вони не змінюються щохвилини.

Довга форма оформлення полісу — розбиваємо на кроки зі збереженням прогресу. Користувач перервався на кроці 3 з 6 — при поверненні бачить збережені дані. UserDefaults / SharedPreferences для чернетки форми (не sensitive дані), зашифроване сховище для паспортних даних у проміжному зберіганні.

Сканування документів: паспорт, СТС — MLKit Document Scanner (Android) / VisionKit DataScannerViewController (iOS 16+). Автоматичне заповнення полів із розпізнаних даних знижує кількість помилок введення.

Врегулювання страхового випадку

Тут користувач перебуває у стресі — аварія, крадіжка, НП. UI має бути максимально простим та лінійним.

Фотофіксація пошкоджень — ключовий крок. Користувач фотографує послідовно: загальний вигляд, кожне пошкодження, VIN, документи. Завантаження в S3 через pre-signed URL напряму з пристрою — не через сервер-посередник. Progress bar на кожному файлі. Retry при обриві з'єднання — Exponential Backoff зі збереженням черги завантаження в Core Data / Room для продовження після закриття додатка.

GPS-координати місця події — автоматично до заявки. CoreLocation / FusedLocationProviderClient. Опціонально — адреса через reverse geocoding (CLGeocoder / Geocoder).

Статуси заявки: подана → прийнята → на розгляді → дод. документи запитані → схвалена/відхилена → виплачена. Push на кожен перехід. Екран «Мої заявки» — список із візуальним прогрес-трекером.

Чат із куратором заявки — критична функція. Користувач повинен мати можливість поставити запитання прямо в контексті заявки, не телефонуючи на гарячу лінію. Stream Chat або Sendbird з прив'язкою thread до claimId.

Що входить в роботу?

Особистий кабінет

Список полісів: тип, статус, дата закінчення. За 30 днів до закінчення — push «Ваш поліс КАСКО закінчується. Продовжити?» з deep link на екран продовження.

Документи полісу: PDF на пристрої, доступний офлайн. Кешуємо в Documents directory з перевіркою актуальності за ETag / Last-Modified при наступному відкритті.

Електронний поліс — QR-код із зашифрованими даними полісу. Актуально для ОСАГО — інспектор ДПС сканує. Дані підписані серверним ключем, верифікація офлайн.

Інтеграція із зовнішніми системами

МТСБУ (Моторне (Транспортне) Страхове Бюро України) — API для перевірки КБМ (коефіцієнт бонус-малус). Запит за даними водія → отримуємо клас та коефіцієнт → автоматично застосовуємо до розрахунку.

ГІББД API — перевірка авто за VIN/держномером, історія ДТП, обмеження. Дані підтягуються автоматично при введенні VIN у форму оформлення.

Платіжний шлюз: Stripe, ЮKassa, CloudPayments. Прив'язка картки для автоматичного продовження полісу — setup_intent (Stripe) / аналог. При продовженні списуємо без додаткового підтвердження — згода отримана при прив'язці.

Безпека

Дані паспорта та ІПН — шифруємо в сховищі (iOS Keychain / Android EncryptedSharedPreferences). Не логуємо в Crashlytics. Certificate pinning для API-запитів із персональними даними. Біометрія для входу — стандарт для фінансових додатків.

Чому нативний стек краще для InsurTech?

Порівняємо нативну розробку (Swift + Kotlin) із крос-платформенними фреймворками.

Нативний стек дає на 30% менше крашів у production — критично для фінансового додатка, де кожен збій підриває довіру. Впровадження такого додатка дозволяє скоротити витрати на обробку заявок до 40%.

Процес роботи

1. Аналітика — вивчаємо бізнес-процеси, типи полісів, флоу врегулювання.
2. Прототипування — створюємо клікабельний прототип, затверджуємо із замовником.
3. Дизайн — малюємо екрани, анімації, темну тему (опціонально).
4. Розробка — пишемо код паралельно під iOS та Android, code review щотижня.
5. Інтеграція — підключаємо МТСБУ, ГІБДД, платіжні шлюзи.
6. Тестування — функціональне, навантажувальне, регрес.
7. Публікація — готуємо метадані, проходимо модерацію.
8. Підтримка — моніторимо помилки, оновлюємо під нові версії ОС.

Орієнтовні терміни

• MVP (один тип полісу, оформлення, кабінет, базова подача заявки): 8–12 тижнів.
• Повноцінне InsurTech-додаток з кількома типами страхування, врегулюванням, документообігом та інтеграціями: 4–7 місяців.

Вартість розраховується індивідуально. Замовте розробку сьогодні — отримайте MVP за 8–12 тижнів. Зв'яжіться з нами, щоб обговорити деталі вашого проєкту. Гарантуємо фіксацію ціни на етапі ТЗ.

Джерело: власний досвід реалізації 15+ InsurTech-проєктів.

Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

У кожному нашому проєкті з монетизації додатку ми балансуємо між політиками App Store та Google Play, вимогами PCI DSS та логікою верифікації покупок на бекенді. Неправильно зроблена система платежів — це не просто баг, це фінансові втрати та можливий бан додатку. За 7 років ми розібрали понад 50 кейсів інтеграції платіжних SDK — від простої Stripe-форми до розподіленого біллінгу з власними серверними вебхуками.

Як вибрати між In-App Purchase та зовнішнім платіжним шлюзом?

Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.

In-App Purchase: дві платформи, два різних API

StoreKit 2 (iOS 15+)

StoreKit 2 — повна переробка оригінального StoreKit з async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читабельно та передбачувано порівняно з чергою транзакцій через SKPaymentTransactionObserver.

Найважливіша зміна: транзакції в StoreKit 2 підписані JWS (JSON Web Signature) і верифікуються локально без серверного roundtrip. Transaction.verificationResult повертає .verified(Transaction) або .unverified(Transaction, VerificationError). Це не означає, що сервер не потрібен — він потрібен для зберігання статусу підписки, але локальна верифікація прибирає затримку при старті.

StoreKit.AppTransaction — верифікація самого факту завантаження додатку з App Store. Потрібна для додатків з платним завантаженням або безстроковими покупками, не підписками.

Складне місце в StoreKit 2 — обробка renewalState для підписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Стан inGracePeriod означає, що Apple намагається відновити оплату (до 16 днів) — у цей час потрібно продовжувати надавати доступ. Не обробиш — втратиш лояльних користувачів, у яких тимчасово не пройшла картка. За досвідом, близько 5% підписок потрапляють у billing retry, і автоматичне відновлення доступу повертає до 80% з них.

Google Play Billing Library (v6+)

Google Billing — складніший за StoreKit за кількістю сценаріїв. BillingClient з PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обов'язково викликати при кожному старті додатку, не покладатися на PurchasesUpdatedListener як єдине джерело правди.

Підтвердження покупки: acknowledgePurchase() для non-consumables та підписок, consumePurchase() для consumables. Якщо не викликати acknowledge протягом 3 днів — Google автоматично зробить повернення. Це гарантована втрата грошей, якщо забути про acknowledge на бекенді після верифікації.

ProductDetails з SubscriptionOfferDetails — в Billing v5+ структура оферт ускладнилася: один продукт може мати кілька basePlanId та offerId (пробний період, знижка для нових користувачів, retention-офер). BillingFlowParams.SubscriptionUpdateParams для апгрейду/даунгрейду підписки з prorationMode.

Чому серверна верифікація обов'язкова?

Ніколи не довіряйте лише клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.

Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус у БД, віддає відповідь клієнту. RevenueCat робить це за вас — але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.

Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток — додаток не отримає про цю подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус. Ми використовуємо перевірку підпису вхідних запитів через Apple's signedPayload та Google's DeveloperNotification.

Як RevenueCat спрощує інтеграцію?

Підтримувати StoreKit 2 та Google Billing одночасно, з урахуванням промо-кодів, оферт, відновлення покупок та серверної верифікації — це кілька місяців розробки. RevenueCat закриває більшу частину цього шару.

RevenueCat — не просто SDK для платежів. Це:

• Єдиний API для iOS та Android (і Stripe для вебу)
• Серверна верифікація та зберігання статусів підписок
• Webhooks на події (покупка, відновлення, скасування, billing issue)
• Аналітика по когортам, MRR, churn
• A/B тестування оферт через Experiments

Purchases.configure(withAPIKey:) при старті, Purchases.shared.getCustomerInfo() для отримання поточних entitlements — мінімальний інтегрований шар. Purchases.shared.purchase(package:) замість прямого виклику StoreKit/Billing.

У документації RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Обмеження RevenueCat: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.

Stripe в мобільних додатках

Stripe — для оплати фізичних товарів, послуг, B2B-платежів де IAP не вимагається політикою платформи.

Stripe iOS SDK та Android SDK — PaymentSheet для готового UI оплати, PaymentSheetFlowController для кастомного UI зі збереженими картками. Payment Intent створюється на сервері, client secret передається в додаток — карткові дані ніколи не проходять через ваш сервер, лише через Stripe.

Apple Pay та Google Pay через Stripe: PKPaymentRequest (iOS) та GooglePayLauncher (Android) вже інтегровані в Stripe SDK. Конверсія у Apple Pay дає в 1.3–2 рази вищий результат, ніж форми з ручним введенням картки — це цифри, які ми підтвердили на десятці проєктів.

Збережені картки через SetupIntent + Customer API — користувач платить в один тап при повторному візиті. Compliance: PCI DSS SAQ A — найлегший рівень compliance, оскільки Stripe Tokenization прибирає потребу зберігати карткові дані на своїй стороні. Згідно з PCI DSS, передача токенів звільняє від необхідності сертифікації рівня 1.

3DS2 (Strong Customer Authentication) — обов'язковий для платежів у ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно коректно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.

Що входить в роботу (deliverables)

Процес та терміни

Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.

Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.

Як налаштувати тестове середовище для платежів?

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.