Інтеграція рассрочки Халва в мобільному додатку
Халва (Совкомбанк) — карта рассрочки, яку інтернет-магазини додають як альтернативу «купи зараз, плати потім». У мобільному додатку інтеграція будується на REST API Халви та deeplink-переході в приложение Халви — якщо воно встановлено на пристрої.
Два сценарії потоку
Приложение Халви встановлено. Користувач нажимає «Оплатити в рассрочку Халва» → ваш додаток відкриває deeplink halva://partner/pay?orderId=...&amount=...&token=... → користувач бачить екран підтвердження в приложенні Халви → підтверджує → Халва повертає користувача через deeplink-callback у ваш додаток → сервер отримує webhook про статус заявки.
Приложение не встановлено. Fallback на WebView-форму: відкриваємо SFSafariViewController / Custom Tabs з URL web-форми Халви. Потік той же, тільки через браузер.
Перевірка наявності приложення на iOS: UIApplication.shared.canOpenURL(URL(string: "halva://")!). Важливо: з iOS 9 потрібно заранее додати halva в LSApplicationQueriesSchemes в Info.plist, інакше canOpenURL завжди повертає false незалежно від наявності приложения. Один з найчастіших пропусків.
Розрахунок рассрочки
Перед оформленням користувач хоче бачити графік платежів: «12 місяців — X рублів/міс». Халва надає API /v1/installment/calculate з параметрами amount та partnerId. Відповідь: список доступних періодів рассрочки з сумами платежів. Відображаємо як picker/chip-компонент — користувач вибирає строк, додаток оновлює ежемісячный платіж в реал-тайм.
Кэшуємо відповідь розрахунку на 10–15 хвилин — умови рассрочки не мінюються поминутно, а лишні мережеві запити сповільнюють UX.
Серверна частина
Мобільний клієнт не повинен напрямку звертатися до API Халви з секретними ключами. Весь потік через ваш сервер: створення заявки → отримання токена/URL → передача клієнту. Webhook від Халви (application.approved / application.rejected) обробляє сервер, міняє статус замовлення, відправляє push-сповіщення користувачу.
Push при одобренні заявки — важлива деталь UX. Користувач пішов у приложение Халви, повернувся, але не дочекався відповіді. Push через Firebase Cloud Messaging (FCM) / APNs повертає його до завершення замовлення.
Типові помилки
- Deeplink callback не обработан при cold start приложения (користувач свайпнув додаток з пам'яті, Халва відкриває deeplink — додаток запускається з нуля, callback втрачається). Рішення: зберігаємо orderId в UserDefaults/SharedPreferences, при старті перевіряємо pending-заявки.
- Не обробляємо
application.expired— заявка одобрена, але користувач не підтвердив протягом 30 хвилин. Потрібен таймер та відповідний UI.
Flutter та React Native
На Flutter: deeplink обробляється через uni_links пакет. getInitialLink() при cold start, linkStream для foreground. При старті додатку — перевіряємо getInitialLink() на наявність Халва-callback, якщо є — відновлюємо контекст замовлення з SharedPreferences та показуємо правильний екран статусу.
На React Native: Linking.getInitialURL() + Linking.addEventListener('url', handler). Логіка та сама — pending orderId зберігається в AsyncStorage.
Ориєнтири по терміам
Повна інтеграція з розрахунком рассрочки, deeplink-потоком та WebView-fallback: 2–3 дні. Для Flutter/React Native з правильною обробкою cold start — плюс півдня на відладку Linking.