Gaming-Plattformen und Software, die POLi unterstützen


1) Schlüsselthese

POLi ist auf Kassenebene (Payment Gateway/Orchestrator) und nicht auf Ebene des Spieleanbieters angebunden.
Ob die Website POLi unterstützt, wird durch die Zahlungsintegration der Casino-Plattform bestimmt und nicht durch diejenigen, deren Slots (NetEnt, Pragmatic, Playtech usw.) gehostet werden.
Funktionale POLi-Abdeckung - nur Einzahlungen. Die Auszahlung erfolgt über alternative Methoden (Banküberweisung, Karten, Wallets).
Gerichtsbarkeiten: In Australien wurde der POLi-Betrieb eingestellt (September 2023), Online-Casinos/Slots für australische Kunden sind durch Bundesgesetz (IGA 2001) verboten; in Neuseeland ist POLi weiterhin in Betrieb und kann von lizenzierten Betreibern unterstützt werden.

2) Arten von Spielplattformen, bei denen POLi technisch unterstützt wird

1. Browser-Casinos (Web-Client):
  • Unterstützung über die Hosted Payment Page (HPP) oder einen Redirect/App-Switch zu einer Online-Bank.
  • Kompatibel mit SPA/SSR-Frameworks (React/Vue/Next/Nuxt) bei korrekter Konfiguration von Redirect-Urls und Verarbeitung des Return-Status der Transaktion.
  • 2. Native iOS/Android-Apps (für NZ):
    • Zwei Muster: In-App-Webview (integrierte Kasse) oder App-Switch/Deep-Link zur Banking-App/zum Browser mit Rückkehr zum Casino nach URL-Schema.
    • Der korrekte Umgang mit Universal-Links/Android-Intents und Timeouts ist erforderlich.
    • 3. Desktop-Clients (selten):
      • Verwenden Sie einen eingebauten Browser/externe Umleitung. Whitelists für Callback-Domains erforderlich.
      • 4. White-Label/Turnkey-Casino-Plattformen:
        • Wenn der Payment Orchestrator der Plattform einen Anschluss an POLi hat und der Betreiber in NZ arbeitet, ist POLi sofort verfügbar (HPP oder Server-to-Server über API).

        💡Wichtig: Gaming-Engines und Content-Anbieter (Slots, Live-Casinos) diktieren keine POLi-Unterstützung; Sie sind von der Zahlungslogik isoliert.

        3) POLi-Integrationsmuster

        Redirect/HPP (am häufigsten):
        • Das Casino sendet eine Anfrage → der Benutzer geht zur Bankseite → authentifiziert sich/2FA → kehrt zur Return\_ url zurück → die Kasse erhält einen erfolgreichen/erfolglosen Status.

        Minimale PCI-Verpflichtungen, hohe Stabilität.
        Server-zu-Server + Kundenumleitung (Hybrid):
        • Der Casino-Server erstellt eine Zahlungssitzung beim POLi-Anbieter, das Frontend führt den Benutzer durch die Umleitungen; Bestätigung des Status - Webhook.

        Praktisch für Idempotenz und genaue Abstimmung.
        Der vollständige API-Ansatz wird selten verwendet (aufgrund der Bankautorisierung geht der Benutzer immer noch zur Bank).

        Kritisch: korrekte Implementierung von Webhook/notify\_ url, Idempotenz, Neuverarbeitung von Status bei Netzwerkausfällen.

        4) Kompatibilität mit Casino-Software und Infrastruktur

        Frontend: alle modernen Frameworks; Es ist wichtig, den CSP einzuhalten, SameSite/Lax für Cookies in der Umleitungskette korrekt zu konfigurieren.
        Backend: kompatibel mit typischen Stacks (Node/Java/PHP/.NET). Sie benötigen Warteschlangen für asynchrone Status, Retrays und Audit-Protokolle.
        Payment Orchestrators/Gateways: Die POLi-Unterstützung wird durch das Vorhandensein eines Connectors bestimmt. Wenn der Orchestrator es hat - das Einschalten an der Kasse läuft darauf hinaus, Merchant und Callback-Urls einzurichten.
        KYC/AML/Behavioral Analytics: unabhängig von der Einzahlungsmethode; Trigger für Füllvolumen/Häufigkeit funktionieren für POLi gleich.
        Mobile SDKs: normalerweise nicht erforderlich; ein korrekter Betrieb des App-Switches und eine Rückgabe per Deeplink genügen.

        5) UX und Sicherheit

        2FA und SCA sind auf der Seite der Bank. Die App sollte die Kassensitzung bis zur Rückgabe „live“ halten (Timeout ≥ 5-10 Minuten).
        Anti-CSRF: Generieren Sie einen einmaligen Zustand vor der Umleitung und überprüfen Sie ihn nach der Rückgabe.
        Webview-Tropfen: Wenn der Benutzer das Bankfenster „geschlossen“ hat, zeigen Sie „Zahlung fortsetzen „/“ eine andere Methode auswählen “.
        Klare Zustände: processing → success/fail → next step * für fail - geben Alternativen (Karte, Bank-Transfer, PayID in AU für legale Dienstleistungen).
        Reconciliation: Führen Sie einen vollständigen Abgleich von Transaktionen auf Merchant-Referenzen und Bankberichten durch; Speichern Sie alle Status mit genauen Zeitstempeln.

        6) POLi Einschränkungen

        Nur Einlagen. Abhebungen über POLi werden nicht unterstützt.
        Die Limits werden von der Bank und dem Betreiber festgelegt, nicht von POLi.
        Keine wiederkehrenden Abschreibungen. Jede Zahlung wird manuell vom Benutzer initiiert.
        Abhängigkeit von der Verfügbarkeit der Internetbank. Geplante Arbeit der Bank = vorübergehende Ausfälle.

        7) Regionale Besonderheiten und rechtlicher Kontext

        Australien (AU):
        • Der Betrieb von POLi wurde eingestellt (September 2023).
        • Online-Casinos/Slots für AU-Bewohner sind durch das Bundesgesetz Interactive Gambling Act 2001 verboten.
        • Für legale Produkte (Buchmacher, Lotterien usw.) werden Alternativen verwendet: PayID/Osko, Bankkarten, Apple Pay/Google Pay.
        • Neuseeland (NZ):
          • POLi funktioniert; lizenzierte Betreiber können es an der Kasse anbieten.
          • Anforderungen: lokale Lizenz, KYC/AML, korrekte Integration von Weiterleitung und Webhooks, klare Grenzen und eine verantwortungsvolle Spielpolitik.

          8) Checkliste für Plattformbesitzer (NZ)

          1. Konfigurieren Sie return\_ url/notify\_ url, aktivieren Sie idempotency.
          2. Implementieren Sie Webhook-Retrays und verzögerte Statusverschiebung.
          3. Letzte Bildschirme einschalten: Erfolg/Ausfall/unbekannt, mit CTA (Wiederholung/Alternative).
          4. Testszenarien: Stornierung in der Bank, Timeout, Kommunikationsabfall, geschlossene Webview.
          5. Festlegen von Einzahlungslimits in der Benutzeroberfläche und Validierung auf dem Client/Server.
          6. Rückgaberichtlinie aktualisieren: Rückgaben erfolgen über den Operator, nicht POLi.
          7. Bereiten Sie eine operative Rekonstruktion vor: tägliche Berichte, Statusvergleich, manuelle Analyse umstrittener Zahlungen.
          8. Konfigurieren Sie die Protokollierung (payment\_ id, user\_ id, bank\_ ref, redirect/return time, result 2FA, webhook latency).
          9. Führen Sie einen UAT/Pentest der Zahlungsströme und Audits durch.
          10. FAQ zur Kasse hinzufügen: "Warum ist die Zahlung nicht erfolgt? „, „Wo ist der Scheck? „, „Was ist die Grenze? ».

          9) Was hat keinen Einfluss auf die POLi-Unterstützung

          Eine Reihe von Slot-Anbietern/Live-Casinos.
          Das Site/App-Framework als solches (bei korrekter Konfiguration von Weiterleitungen/Sitzungen).
          Das Bonusschema (Aktivierung/Promotion-Code) ist eine Geschäftslogik, keine Zahlungsinfrastruktur.

          10) Endergebnis

          POLi ist eine Kassen-/Zahlungs-Orchestrator-Integration, die mit Web-Casinos, mobilen Anwendungen und White-Label-Plattformen kompatibel ist. Es bietet schnelle Einzahlungen durch Bankumleitung und Webhooks, unterstützt jedoch keine Auszahlungen und unterliegt den Grenzen der Bank/des Betreibers. In Australien wird die Methode aufgrund der Gesetzgebung nicht mehr verwendet und ist auf Online-Slots nicht anwendbar; in Neuseeland bleibt eine Arbeitslösung mit korrekter technischer und rechtlicher Anpassung.