Інтеграція рассрочки Карта покупок в мобільному додатку
«Карта покупок» — білоруський продукт рассрочки, який магазини підключають для збільшення середнього чека. На відміну від російської Халви, тут немає окремого мобільного приложения у емітента — потік повністю через WebView-форму та серверне API.
Як влаштований потік
Користувач вибирає «Оплатити в рассрочку» → ваш сервер створює заявку через API Карти покупок, отримує URL платіжної форми → мобільний додаток відкриває URL в SFSafariViewController (iOS) / Custom Tabs (Android) → користувач вводить дані карти й підтверджує → редирект на successUrl/failUrl → webhook на ваш сервер про фінальний статус.
Нюанс: форма Карти покупок використовує OTP-підтвердження через SMS. В SFSafariViewController SMS AutoFill (iOS 12+) працює штатно — Safari пропонує вставити код з повідомлення. В звичайному WKWebView це теж працює при правильно виставленому contentType = .oneTimeCode у формі. Убеждаємося, що не блокуємо JavaScript в WebView.
Розрахунок та відображення умов
API надає еndpoint розрахунку рассрочки: передаємо суму, отримуємо доступні періоди (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 з трьома спробами перед показом помилки користувачу.
Процес
Підключення партнерського договору → тестові credentials → серверний модуль (створення заявки, webhook) → мобільна частина (WebView потік, deeplink-обробка) → тестування з тестовими даними карти → production.
Ориєнтири по терміам
2–3 дні з момента отримання API-ключів. Організаційна частина (партнерський договір) — вне оцінки розробки.