Интеграция POLi в мобильные приложения казино

1) Контекст и ограничения

Функционал POLi: только депозиты; вывод — через иные методы (банк-трансфер/карта/кошелёк).
Юрисдикции:

• Австралия: операции POLi прекращены (сентябрь 2023); онлайн-казино/слоты для резидентов AU запрещены (IGA 2001).
• Новая Зеландия: POLi доступен на лицензированных площадках; мобильная интеграция релевантна.
• Вывод: ниже — техническая схема для рынков, где использование разрешено (NZ и иные легальные юрисдикции).

2) Архитектурные варианты подключения

A. Redirect / Hosted Payment Page (HPP) — базовый стандарт

Клиент → касса создаёт сессию оплаты → редирект в банк (браузер/банк-приложение) → возврат по `return_url` → подтверждение через вебхук/поллинг.
Плюсы: минимальные PCI-требования, устойчивая модель, меньше рисков.
Минусы: зависит от корректной обработки app-switch и возвратного deeplink.

B. Server-to-Server + redirect (гибрид)

Сервер создаёт платёж у провайдера POLi, мобильный клиент лишь инициирует редирект; итоговый статус приходит вебхуком.
Плюсы: чёткая реконцилияция, удобные ретраи, идемпотентность на бэкенде.
Минусы: больше серверной логики.


3) Пользовательский поток (mobile UX)

1. Касса → выбор POLi.
2. Ввод суммы → создание сессии оплаты (txn\_id, state/nonce, срок жизни).
3. App-switch: открываем банк (или браузер с интернет-банком).
4. Логин/2FA в банке → подтверждение перевода.
5. Возврат по `return_url`/deeplink в приложение → экран результата.
6. Бэкенд получает вебхук и финализирует депозит; клиент запрашивает статус по `txn_id` (pull-подтверждение) на случай задержек вебхука.

4) iOS-специфика

Используйте ASWebAuthenticationSession или SFSafariViewController для браузерного шага; прямой WKWebView реже подходит из-за куки/редиректов.
Universal Links для `return_url`; обработка в `scene(_: continue: )`.
Таймауты сессии ≥ 10 мин, фоновый режим не обязателен, но сохранение состояния кассы — обязательно.
Если банк открывается как отдельное приложение — обеспечьте дружелюбный back-to-app сценарий и повторное получение статуса при возврате.

5) Android-специфика

Предпочтительно Custom Tabs для веб-потока; для банк-приложений — intent filters и проверенные App Links для `return_url`.
Обработка результата — через deeplink-активити; повторный запрос статуса при `onResume()`.
Не храните состояние оплаты в `Activity`; используйте ViewModel/репозиторий, переживающий конфигурационные изменения.
Фолбэк на системный браузер при недоступности банка/приложения.

6) Безопасность интеграции

TLS везде, запрет незащищённых протоколов. iOS ATS / Android Network Security Config — включены.
CSRF/Replay-защита: одноразовый `state`/`nonce`, сверка на возврате.
Идемпотентность: idempotency-key на создание оплаты; повторная обработка вебхуков — безопасна.
Вебхуки: подпись, фиксированные исходящие IP (если доступно), ретраи с экспоненциальной паузой, дедупликация по event\_id.
Логи: не логируйте банковские логины/OTP; маскируйте PII; храните: `txn_id`, время редиректа/возврата, коды статусов.
Root/Jailbreak-сигналы: мягкое предупреждение и блок высокорисковых операций по бизнес-правилам.
Защита возвратных URL: белый список `return_url` на стороне провайдера и приложения.

7) Обработка статусов и ошибкостойкость

Статусы: `processing` → `succeeded`/`failed`/`unknown`.
Если пользователь закрыл банк/браузер — показывайте экран «Продолжить оплату / Выбрать другой метод».
При `unknown`: не блокируйте игрока — держите заказ в «ожидании», повторно опросите бэкенд, дождитесь вебхука.
Стандартизируйте коды ошибок (банк недоступен, лимит, аутентификация, отмена пользователем, таймаут).
Учитывайте дробные подтверждения (банк списал, мерчант ещё не обновился) — объясняйте это в UI.

8) Реконцилияция и финансы

Ежедневная сверка: отчёты провайдера POLi ↔ ваша БД (по `merchant_ref`, сумме, валюте, времени).
Отдельная очередь на «рассинхроны»; ручные кейсы — в бек-офис туллинге.
Для бонусов «на депозит» — начислять после `succeeded`; для `processing`/`unknown` — ставить hold.

9) UX-практики кассы (mobile-first)

Видимая полоса прогресса и таймер «Сеанс банка истечёт через …».
Чёткая копия на кнопках: «Перейти в банк», «Подтвердил — вернуться в приложение».
Ясные суммы/валюта, моментальная валидация лимитов до редиректа.
Сохранение черновика депозита; повторное открытие сессии при восстановлении приложения.
Доступность: VoiceOver/TalkBack-лейблы, достаточный контраст, Dynamic Type/FontScale.

10) Лимиты, KYC/AML, ответственность

Лимиты задают банк и оператор, а не POLi; показывайте доступный диапазон до начала оплаты.
KYC/AML не зависят от метода — проверки на объём/частоту срабатывают одинаково; высокие риски — ручная верификация.
Политика ответственной игры: лимиты депозитов/паузы доступны и при POLi; добавьте быстрые ссылки на управление лимитами в кассе.

11) Региональные особенности и фичефлаги

AU: отключите POLi на уровне фичефлагов/билда; показывайте дисклеймер (сервис недоступен; онлайн-казино запрещены).
NZ: разрешить POLi; список банков/лимитов подтягивать из конфигурации (remote config).
Геофенсинг, локализация валют/форматов, серверные allow-lists мерчантов по стране.

12) Тест-матрица и QA

Банки: минимум по одному кейсу на каждый крупный банк и по типам 2FA (SMS, пуш, токен).
Платформы: iOS/Android, актуальные мажорные версии, тёмная/светлая тема, разные локали/языки.
Сценарии сбоев: отмена в банке, истёкшая сессия, разрыв сети, закрытие webview, неверный deeplink, повтор вебхука.
Нагрузочные: пиковые часы, задержки вебхуков, массовые ретраи.

13) Мониторинг и операционка

Метрики: конверсия кассы, CTR «Перейти в банк», средний `time-to-funds`, доля `unknown`, частота ретраев вебхука, отказ банка по причинам.
Алерты: таймаут вебхуков, всплеск `failed` по одному банку, рост `unknown` > порога.
Ранбук инцидента: переключение приоритета методов, сообщить пользователям, форс-поллинг статусов, пост-мортем.

14) Что интеграция не делает

Не добавляет вывод средств.
Не обходит лимиты банка или оператора.
Не заменяет процедуры KYC/AML и ответственной игры.

Итог

Интеграция POLi в мобильные приложения строится вокруг безопасного redirect/HPP с корректным app-switch, надёжной обработкой возвратного deeplink, подтверждением через вебхуки и строгой идемпотентностью. Ключ к стабильности — прозрачные статусы, дружелюбные сценарии восстановления и полноценная реконцилияция. В Австралии POLi недоступен и неприменим к онлайн-слотам; в Новой Зеландии метод остаётся рабочим и даёт пользователям быстрые депозиты при корректной технической и правовой настройке.