Monaco Telecom

Im Hafen von Monaco liegen ganzjährig Yachten unterschiedlicher Größenklassen. Mit Saisonalität — von Grand-Prix-Wochenende bis Sommer-Hochbetrieb — schwankt die WLAN-Nachfrage zwischen „still" und „massiv". Was nicht schwanken sollte: das Erlebnis des Gastes. Wer ein WLAN-Ticket kaufen will, möchte das im Browser tun. Nicht beim Hafenmeister. Nicht morgen früh. Jetzt, in der Sprache, die er spricht.

Davor lag eine klassische manuelle Vergabe. Was nicht skalierte — vor allem nicht in Saison-Spitzen, wenn der Hafenmeister-Schalter ohnehin gut zu tun hat. Was zudem keine sauberen Self-Service-Daten produzierte für Buchhaltung, Steuer und kundenspezifische Wiederholungs-Käufe.

Eine Standard-Captive-Portal-Lösung mit „kostenfreiem WLAN" ist hier keine Option — Hafen-WLAN ist ein bezahlter Service, mit Tarifstaffeln und Mehrwertsteuer-Pflicht.

Eine End-to-End-Lösung von der Tarif-Auswahl im Browser bis zur Provisionierung im Ucopia-WLAN-Controller, gestützt durch eine Java-Spring-Boot-API, ein React-Frontend und eine konsequent GDPR-bewusste Datenhaltung.

Der Bestell-Workflow im Detail

1. Tarif-Auswahl: Der Gast ruft die SEPM-Refill-Webseite auf — über einen Registrierungs-Link im Captive-Portal-Detail oder direkt per URL. Das Frontend zeigt die verfügbaren Tarif-Pakete (Stunde / Tag / Woche / Monat).
2. Registrierung: Eingabe der Kontaktdaten + (optional) Captcha-Validierung gegen automatisierte Anfragen.
3. Persistierung: Customer-Daten gehen in die MariaDB, der Zahlungs-Prozess wird über die Ingenico-Direct-API initialisiert.
4. Ingenico Hosted Payment Page (vier Schritte): Auswahl der Zahlungsart → Eingabe der Karten-Daten → Bestätigung oder Ablehnung → Rückleitung zur Refill-Seite über eine Return-URL.
5. Confirm-Endpoint: Die Refill-Seite ruft /api/v1/sepm/confirm auf. Hier passieren in einem orchestrierten Schritt:
   • Customer-Daten aus MariaDB nachladen
   • Account-Name und Passwort generieren
   • Zahlungs-Status final mit Ingenico-API verifizieren
   • Nächste Rechnungsnummer vergeben
   • Tarif-Details aus der Konfigurationsdatei mt-packages.yml laden
   • Über die Ucopia-Deleg-API Account anlegen oder refillen (je nach gewähltem Refill-Modus)
   • Credentials-E-Mail an den Gast schicken
   • PDF-Rechnung erzeugen und zweite E-Mail senden
   • GDPR-Strategie auf den Customer-Datensatz anwenden (siehe unten)
   • Status-E-Mail an SEPM-Operator
6. Confirmation-Page: Anzeige der Zugangsdaten im Browser. Das Reload-Verhalten ist sauber idempotent — wer die Seite neu lädt, bekommt die Bestätigung, nicht eine zweite Buchung.

Die API stellt drei Public-Endpunkte bereit (packages, checkout, confirm) plus interne Endpunkte für Status-Monitoring und Customer-Verwaltung — inklusive eines deleteexpired-Endpunkts, der typischerweise per Cronjob täglich abgefragt wird.

Drei Refill-Modi für den Ucopia-Controller

Ucopia kennt drei Wege, einer Account-Identität neue Gültigkeit zu geben — wir haben alle drei abgebildet, weil unterschiedliche Hafen-Kontexte unterschiedliche Anforderungen haben:

Refill-Modus	Wie	Stärken	Schwächen
profile	Gültigkeit über Profil setzen	einfach	wenig flexibel, nicht kumulativ
account	Beim Anlegen direkt setzen	flexibel, einfach	nicht kumulativ
voucher	Gültigkeit über Voucher	nativ kumulativ	Voucher-Pakete müssen gepflegt werden

Default-Modus ist account — das passt für die meisten Hafen-Szenarien (einfach pflegbar, ausreichend flexibel). voucher empfiehlt sich für Szenarien, in denen Gäste während einer laufenden Gültigkeit nochmal nachkaufen wollen (kumulativ).

Customer-Daten unter GDPR-Regie

Die MariaDB hält Customer-Daten genau so lange, wie sie wirklich gebraucht werden — und der Operator entscheidet pro Lifecycle-Phase, wie mit den Daten umgegangen wird. Drei konfigurierbare Strategien stehen zur Wahl:

1. Keep — Daten bleiben, Wiederholungs-Käufer werden erkannt, Statistik wertbar
2. Anonymize — Daten werden anonymisiert, nur statistische Auswertung möglich
3. Delete — Daten werden gelöscht, kein Reload der Bestätigungsseite mehr möglich

Die Wahl liegt beim SEPM-Betreiber, nicht im Code. Konfigurations-Eintrag, kein Migrations-Skript.

Zwölf Service-Konfigurations-Felder, die einen Unterschied machen

Die mt-settings.yml der API steuert das Verhalten in einem Detail-Niveau, das den Unterschied zwischen „läuft im Standardfall" und „läuft auch in Edge Cases" macht:

• Sprache: Mehrsprachiges Frontend (DE / EN / FR — letzteres als regionale Pflicht im Monégassischen Kontext)
• Tarif-Logik: Pakete in mt-packages.yml, mit Möglichkeit zur Profil- oder Voucher-Abbildung
• E-Mail-Templates: Credentials, Rechnung, Status — pro Sprache
• Rechnungs-PDF-Templates: SEPM-Branding, Mehrwertsteuer-Ausweis, fortlaufende Nummerierung
• Ingenico-Authentifizierungs-Modus: SALE oder andere — direkter Pass-Through zum Zahlungsprovider
• Ucopia-Verbindung: Endpunkt der Deleg-API, Credentials, Connection-Pool

Container-First mit Kubernetes-Skalierung

Backend und Frontend sind separat in Docker paketiert und orchestriert über Kubernetes / OpenShift. Das Saisonalitäts-Argument ist hier nicht akademisch: Während Grand-Prix-Wochen oder Sommer-Hochbetrieb skalieren die API-Pods elastisch — außerhalb der Saison läuft das System auf Minimalbesetzung. Keine Hardware-Investition für die Spitze, kein Hardware-Leerlauf in der Nebensaison.

• Aus Concierge-Schalter wird Self-Service. Der Hafenmeister kann sich auf das konzentrieren, wofür er da ist.
• Mehrsprachigkeit ohne Reibung. Internationale Klientel — französisch, englisch, italienisch, deutsch — bekommt das Bestellverfahren in der eigenen Sprache.
• Saison-Spitzen werden über K8s-Skalierung absorbiert. Keine Reserve-Hardware, kein Performance-Bruch.
• GDPR-Compliance ist Konfiguration, nicht Codebase-Eingriff. Operator wählt Keep/Anonymize/Delete je nach Use Case.
• Drei Refill-Modi decken unterschiedliche Geschäftsmodelle ab — Hafen-Tarife sind nicht überall gleich.
• Confirmation-Reload-Idempotenz vermeidet doppelte Buchungen und Doppel-Belastungen — strukturell, nicht „durch Vorsicht".

• Wir betreiben den Ucopia-WLAN-Controller nicht. Das macht Monaco Telecom als Operator selbst.
• Wir verarbeiten keine eigene Identität jenseits der Zahlungsdaten. Wer mit gültiger Karte bezahlt, bekommt Zugang. Punkt.
• Wir machen kein eigenes Customer Care. Kunden-Rückfragen gehen an Monaco Telecom. Wir liefern Status-Mails und API-Status-Endpunkte für die internen Operations-Teams.
• Wir wählen nicht aus, welche Tarife aktuell verfügbar sind. Das steht in mt-packages.yml, gepflegt vom Operator.

Der Aufbau funktioniert überall dort, wo öffentliches WLAN als bezahltes Service-Element angeboten werden soll und der Captive-Portal-Operator eine Self-Service-Lösung mit echter Zahlungs-, Buchhaltungs- und Compliance-Tiefe braucht — Marinas, Häfen, Flughäfen, Messen, Festivals, Co-Working-Spaces, Hospitality-Ketten, Stadien, Touristen-Anlaufpunkte, Bus-/Bahnhöfe.

Das Muster: Branded Captive Portal mit Mehrsprachigkeit → Tarif- und Voucher-Logik → Zahlungs-Integration über Ingenico (oder Saferpay / Stripe / vergleichbar) → Anbindung an Ucopia-Controller über Deleg-API → MariaDB als minimaler Datenhalter unter GDPR-Konfiguration → Container-Deployment über K8s mit elastischer Saison-Skalierung.

Die SEPM-Lösung ist seit 2021 produktiv. Das Muster ist seitdem mehrfach in Variation wiederverwendet worden — andere Zahlungsprovider, andere Sprachen, andere Hafen- und Verkehrs-Kontexte.