Интеграция рассрочки Халва в мобильное приложение
Халва (Совкомбанк) — карта рассрочки, которую интернет-магазины добавляют как альтернативу «купи сейчас, плати потом». В мобильном приложении интеграция строится на 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 Халвы с секретными ключами. Весь flow через ваш сервер: создание заявки → получение токена/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.