Інтеграція 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.
Логи: не логуйте банківські логіни/ОТР; маскуйте 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 недоступний і непридатний до онлайн-слотів; у Новій Зеландії метод залишається робочим і дає користувачам швидкі депозити при коректному технічному і правовому налаштуванні.