У клиента в приложении падала конверсия на этапе оплаты — пользователи бросали корзину на полусумме. Решение — рассрочка «Карта покупок». В отличие от российской Халвы, у эмитента нет отдельного мобильного приложения: флоу полностью через WebView-форму и серверное API. Наш опыт показывает, что правильная интеграция повышает конверсию на 15–25%, а средний чек — на 20%.
Как устроен флоу
Пользователь выбирает «Оплатить в рассрочку» → ваш сервер создаёт заявку через API Карты покупок, получает URL платёжной формы → мобильное приложение открывает URL в SFSafariViewController (iOS) / Custom Tabs (Android) → пользователь вводит данные карты покупок и подтверждает → редирект на successUrl/failUrl → webhook на ваш сервер о финальном статусе.
Нюанс: форма Карты покупок использует OTP-подтверждение через SMS. В SFSafariViewController SMS AutoFill (iOS 12+) работает штатно — Safari предлагает вставить код из сообщения. В обычном WKWebView это тоже работает при правильно выставленном contentType = .oneTimeCode в форме. Убеждаемся, что не блокируем JavaScript в WebView.
SFSafariViewController на 40% быстрее обрабатывает OTP-подтверждение за счёт изоляции cookie-хранилища.
Расчёт и отображение условий
API предоставляет эндпоинт расчёта рассрочки: передаём сумму, получаем доступные периоды (3, 6, 12 месяцев) и ежемесячный платёж. Отображаем до открытия формы — пользователь должен видеть условия до того, как нажал кнопку.
Пример ответа: {"periods": [{"months": 6, "monthly": 83.33}, {"months": 12, "monthly": 41.67}]}. Показываем как горизонтальный список с чипами выбора периода — стандартный UX для BNPL-продуктов.
Обработка статусов
Карта покупок возвращает три финальных статуса: approved, rejected, cancelled. rejected — банк отказал в рассрочке — показываем сообщение с предложением оплатить картой. Не пишем «ошибка» — пишем «Банк не одобрил рассрочку. Вы можете оплатить картой». Разница в конверсии ощутимая.
Callback через returnUrl обрабатываем в AppDelegate/Application по URL scheme. Параллельно — webhook на сервер. Статус берём из webhook, не из query-параметров returnUrl (их можно подделать).
Типичные ошибки при реализации
-
Обычный
WKWebViewвместоSFSafariViewController. ВWKWebViewнет доступа к системным cookies Safari. Если Карта покупок использует cookie-based сессию на своей форме, пользователь каждый раз будет проходить авторизацию заново.SFSafariViewControllerрешает это — он разделяет cookie-хранилище с Safari. - Не обрабатываем таймаут заявки. Заявка на рассрочку активна ограниченное время (обычно 15–30 минут). Если пользователь ушёл с экрана формы и вернулся через час — показываем «Время сессии истекло, попробуйте снова» вместо зависшего спиннера.
- Нет retry при временной недоступности API. Создание заявки — критичный запрос. При
503/504от сервера Карты покупок — Exponential Backoff с тремя попытками перед показом ошибки пользователю.
Почему стоит выбрать SFSafariViewController вместо WKWebView?
SFSafariViewController обеспечивает изоляцию cookie-хранилища и поддерживает SMS AutoFill. Если ваша целевая аудитория использует iOS 12+, этот подход гарантирует минимальное трение при вводе OTP. Для Android используем Custom Tabs — они аналогично разделяют cookies с Chrome.
Как гарантировать прохождение модерации App Store?
App Store Review Guidelines (Section 4.2) требуют, чтобы платёжные формы не нарушали приватность пользователя. Использование SFSafariViewController соответствует этим требованиям — он работает в изолированном процессе и не имеет доступа к данным приложения. Мы проверяем каждый проект на соответствие правилам.
Что входит в интеграцию под ключ?
| Этап | Что делаем | Результат |
|---|---|---|
| Анализ | Изучаем API Карты покупок, тестовые credentials | Техническое задание |
| Серверная часть | Реализуем создание заявки, обработку webhook | Готовый модуль |
| Мобильная часть | Настраиваем WebView-флоу, deep linking | Работающий флоу |
| Тестирование | Проверяем все статусы, timeout, retry | Отчёт о тестах |
| Документация | Пишем описание API и инструкцию для поддержки | PDF/Notion |
Мы гарантируем, что интеграция пройдёт все требования App Store Review Guidelines (Section 4.2/5.1) и Google Play Console.
Сравнение подходов к WebView
| Подход | Куки-хранилище | Автозаполнение OTP | Совместимость с iOS 12+ |
|---|---|---|---|
| SFSafariViewController | Общее с Safari | Да (SMS AutoFill) | Полная |
| WKWebView | Изолированное | Только с oneTimeCode |
Не полная |
| Custom Tabs (Android) | Общее с Chrome | Да (Autofill) | — |
Пример обработки webhook на сервере (Python/Flask)
@app.route('/webhook/karta-pokupok', methods=['POST']) def webhook(): data = request.json status = data.get('status') order_id = data.get('order_id') if status == 'approved': update_order_status(order_id, 'paid') elif status == 'rejected': update_order_status(order_id, 'failed') return 'OK', 200 Процесс работы
- Заключаем партнёрский договор с Картой покупок.
- Получаем тестовые credentials.
- Разрабатываем серверный модуль (создание заявки, webhook).
- Встраиваем мобильную часть (WebView флоу, deeplink-обработка).
- Тестируем с тестовыми данными карты.
- Запускаем в production.
Ориентиры по срокам
Разработка модуля «под ключ» занимает от 2 до 4 рабочих дней с момента получения API-ключей. Организационная часть (договор) — вне оценки разработки. Стоимость рассчитывается индивидуально в зависимости от сложности существующего приложения.
Хотите добавить рассрочку в своё приложение? Свяжитесь с нами — оценим проект за один рабочий день. Опыт интеграции более 10 BNPL-продуктов за 5+ лет гарантирует решение даже нестандартных задач. Закажите интеграцию — получите консультацию инженера.