Ігрові платформи та софт, що підтримують POLi

1) Ключова теза

POLi підключається на рівні каси (payment gateway/оркестратор), а не на рівні ігрового провайдера.

Чи підтримує сайт POLi - визначається платіжною інтеграцією платформи казино, а не тим, чиї слоти (NetEnt, Pragmatic, Playtech тощо) розміщені.

Функціональне охоплення POLi - тільки депозити. Виведення коштів виконується альтернативними методами (банківський переказ, карти, гаманці).

Юрисдикції: в Австралії операції POLi припинені (вересень 2023), онлайн-казино/слоти для австралійських клієнтів заборонені федеральним законом (IGA 2001); в Новій Зеландії POLi продовжує працювати і може підтримуватися ліцензованими операторами.

2) Типи ігрових платформ, де POLi технічно підтримується

• Підтримка через Hosted Payment Page (HPP) або редирект/апп-світч в інтернет-банк.
• Сумісно з SPA/SSR-фреймворками (React/Vue/Next/Nuxt) при коректному налаштуванні редирект-урлів і обробці поворотного статусу транзакції.

• Два патерни: in-app webview (вбудована каса) або app-switch/deep link в банківський додаток/браузер з поверненням в казино за схемою URL.
• Потрібна коректна обробка universal links/Android intents і таймаутів.

• Використовують вбудований браузер/зовнішній редирект. Потрібні whitelists для callback-доменів.

• Якщо у платіжного оркестратора платформи є конектор до POLi і оператор працює в NZ - POLi доступний «з коробки» (HPP або сервер-к-серверу через API).

3) Патерни інтеграції POLi

• Казино відправляє запит → користувач йде на сторінку банку → проходить автентифікацію/2FA → повертається на return\_ url → каса отримує успішний/неуспішний статус.

Мінімум PCI-зобов'язань, висока стабільність.

• Сервер казино створює платіжну сесію у провайдера POLi, фронтенд веде користувача по редиректам; підтвердження статусу - вебхуком.

Зручно для ідемпотентності і точної звірки.

Повний API-підхід використовується рідко (через банківську авторизацію користувач все одно переходить в банк).

Критично: коректна реалізація webhook/notify\_ url, ідемпотентність, повторна обробка статусів при мережевих збоях.

4) Сумісність з ПЗ та інфраструктурою казино

Фронтенд: будь-які сучасні фреймворки; важливо дотримуватися CSP, коректно конфігурувати SameSite/Lax для cookie в ланцюжку редиректів.

Бекенд: сумісно з типовими стеками (Node/Java/PHP/.NET). Потрібні черги для асинхронних статусів, ретраї та логи аудиту.

Платіжні оркестратори/шлюзи: підтримка POLi визначається наявністю конектора. Якщо оркестратор його має - включення в касі зводиться до налаштування мерчанта і callback-урлів.

KYC/AML/поведінкова аналітика: не залежать від методу депозиту; тригери на обсяг/частоту поповнень працюють однаково для POLi.

Мобільні SDK: зазвичай не потрібні; досить коректної роботи app-switch і повернення по deeplink.

5) UX і безпека

2FA і SCA - на стороні банку. Додаток повинен тримати сесію каси «живий» до повернення (таймаут ≥ 5-10 хвилин).

Анти-CSRF: перед редиректом генеруйте одноразовий state і перевіряйте його після повернення.

Падіння webview: якщо користувач «закрив» банківське вікно, показуйте «відновити платіж «/» вибрати інший метод ».

Ясні статуси: processing → success/fail → next step*; для fail - дати альтернативи (картка, банк-трансфер, PayID в AU для легальних сервісів).

Реконциліяція: проводьте повну звірку транзакцій по мерчант-референсах і банківських звітах; всі статуси зберігати з точними таймштампами.

6) Обмеження POLi

Тільки депозити. Виведення коштів через POLi не підтримується.

Ліміти задаються банком і оператором, а не POLi.

Немає рекурентних списань. Кожен платіж ініціюється вручну користувачем.

Залежність від доступності інтернет-банку. Планові роботи банку = тимчасові відмови.

7) Регіональні особливості та правовий контекст

• Операції POLi припинені (вересень 2023).
• Онлайн-казино/слоти для жителів AU заборонені федеральним законом Interactive Gambling Act 2001.
• Для легальних продуктів (букмекери, лотереї тощо) використовуються альтернативи: PayID/Osko, банківські картки, Apple Pay/Google Pay.

• POLi функціонує; ліцензовані оператори можуть пропонувати його в касі.
• Вимоги: локальна ліцензія, KYC/AML, коректна інтеграція редиректу і вебхуків, чіткі ліміти і політика відповідальної гри.

8) Чек-лист для власників платформ (NZ)

1. Налаштувати return\_ url/notify\_ url, включити ідемпотентність.

2. Реалізувати ретраї вебхуків і відкладену розсинхронізацію статусів.

3. Увімкнути фінальні екрани: успіх/відмова/невідомо, з CTA (повтор/альтернатива).

4. Протестувати сценарії: скасування в банку, таймаут, падіння зв'язку, закритий webview.

5. Прописати ліміти депозиту в UI і валідацію на клієнті/сервері.

6. Оновити політику повернення: повернення виконуються через оператора, а не POLi.

7. Підготувати операційну реконциліяцію: щоденні звіти, порівняння статусів, ручні розбори спірних платежів.

8. Налаштувати журналювання (payment\_ id, user\_ id, bank\_ ref, час редиректу/повернення, результат 2FA, webhook-латентність).

9. Провести UAT/пентест потоків оплати та аудиту.

10. Додати FAQ в касу: "Чому не пройшов платіж? «, «Де чек? «, «Який ліміт? ».

9) Що не впливає на підтримку POLi

Набір провайдерів слотів/лайв-казино.

Фреймворк сайту/додатку як такої (при коректному налаштуванні редиректів/сесій).

Схема бонусів (активація/промокод) - це бізнес-логіка, не платіжна інфраструктура.

10) Підсумок

POLi - це інтеграція каси/платіжного оркестратора, сумісна з веб-казино, мобільними додатками і white-label-платформами. Він забезпечує швидкі депозити за рахунок банківського редиректу і вебхуків, але не підтримує виведення і підпорядковується лімітам банку/оператора. В Австралії метод більше не використовується і непридатний до онлайн-слотів через законодавство; у Новій Зеландії залишається робочим рішенням при коректному технічному і правовому налаштуванні.