Игровые платформы и софт, поддерживающие 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-платформами. Он обеспечивает быстрые депозиты за счёт банковского редиректа и вебхуков, но не поддерживает вывод и подчиняется лимитам банка/оператора. В Австралии метод более не используется и неприменим к онлайн-слотам из-за законодательства; в Новой Зеландии остаётся рабочим решением при корректной технической и правовой настройке.