License-Gate, kein Phone-Home-Spam

Lizenz-Validierung läuft einmal über einen Polar-Webhook und cached danach mit Refresh-Cycle. Conversion-Events triggern keine Lizenz-Checks. Bei Ablauf schaltet sich Beaconry graceful ab, ohne die Kampagnen-Daten hart abzuschneiden.

Wie Aktivierung funktioniert

1. Du kaufst eine Lizenz auf Polar. Polar gibt einen Key wie polar_li_* aus.
2. Du fügst den Key in Beaconry → Dashboard → Lizenz → Aktivieren ein.
3. Beaconry ruft Beaconrys zentralen License-Validator (Cloudflare Worker) einmal auf. Worker validiert den Key gegen Polars API, gibt das Aktivierungsergebnis zurück. Beaconry cached das Ergebnis lokal mit Refresh-Cycle-Timestamp.
4. Aktivierung fertig. Dashboard wechselt von "Inaktiv" auf "Aktiv".

Wie der Refresh-Cycle funktioniert

Beaconrys zentraler Worker abonniert Polar-Webhooks. Wenn auf Polars Seite ein Kunden-Event passiert (Lizenz aktiviert, Lizenz erstattet, Lizenz abgelaufen, Subscription verlängert), feuert Polar den Webhook an den Worker. Der Worker updated seine interne License-Datenbank in Sekunden.

Deine WordPress-Installation pingt den Worker einmal pro Tag für den Status. Falls der Cache frisch ist (vor max. ~1 Stunde im Worker aktualisiert), liefert Beaconry "Lizenz gültig" sofort. Falls auf Polar-Seite ein Statuswechsel passiert ist, holt deine Installation ihn innerhalb von max. 1 Stunde.

Vergleich: typische Phone-Home-Patterns pingen pro Event oder pro Page-View. Beaconry pingt einmal pro Tag, server-zu-server. Conversion-Events triggern nie einen Lizenz-Check.

Was bei Lizenzablauf passiert

Zwei Szenarien, sehr unterschiedliches Verhalten:

Szenario A: Lizenz abgelaufen (Verlängerung nicht bezahlt). Beaconrys Dashboard zeigt eine Warnung, sobald der Cache den Ablauf reflektiert. Tracking läuft 7 Tage Schon-Zeit weiter. Nach 7 Tagen stoppt der Server-Side-Dispatch, kein Event verlässt mehr WordPress. Bestehende Besucher und Form-Submissions sind nicht betroffen, nur die ausgehenden Plattform-Calls stoppen.

Szenario B: Lizenz von dir erstattet. Beaconrys Worker invalidiert die Aktivierung sofort beim Polar-Webhook. Deine Installation holt das innerhalb von 1 Stunde. Tracking stoppt, keine Schon-Zeit (du hast dein Geld zurück, der Trade ist symmetrisch).

In beiden Fällen löscht Beaconry nie deine Settings, nie deine Event-History im Logs-Tab, beeinflusst nie WordPress-Core oder andere Plugins. Frischen Key aktivieren, Tracking startet sofort wieder.

Was bei Validator-Unerreichbarkeit passiert

Zwei Resilienz-Schichten:

• Netzwerk-Ausfall auf Validator-Seite: Beaconry cached den letzten gültigen Lizenz-Status. Solange der Cache < 7 Tage alt ist, läuft Tracking weiter. Über 7 Tage hinaus geht Beaconry davon aus, dass die Lizenz abgelaufen sein könnte und schaltet auf Schon-Zeit-Verhalten.
• Netzwerk-Ausfall auf Kunden-Seite: WordPress kann den Validator nicht pingen. Beaconry nutzt den Cache-State, bis das Netzwerk wieder da ist oder der Cache die 7-Tage-Schwelle erreicht.

Netto-Effekt: kurze Ausfälle (Stunden, nicht Tage) beeinflussen Tracking nicht. Lang anhaltende Kunden-Netzwerk-Probleme triggern irgendwann die Schon-Zeit.

Privacy und Datenfluss

• Beaconrys zentraler Worker kennt nur deinen Lizenzschlüssel und die WordPress-Site-URL.
• Er weiß nicht, welche Events du feuerst, welche Plattformen du verbindest, welche Daten du sendest. Nichts davon verlässt deine WordPress-Installation, es geht direkt an die Plattform-spezifischen APIs.
• Deine Access-Tokens für Meta, TikTok, Google Ads, LinkedIn, GA4 bleiben verschlüsselt in deiner WordPress-Datenbank, gehen nie an Beaconrys Server.

Power-User-Hinweise

• BCNR_LICENSE_KEY in wp-config.php definieren, um den Key aus der Datenbank rauszuhalten.
• Konstante BCNR_LICENSE_DEBUG = true auf Staging nutzen, um die volle Validator-Antwort im Logs-Tab zu sehen.
• Das Dashboard zeigt letzter Refresh, nächster geplanter Refresh, Lizenz-Tier und Seat-Count. Falls etwas stale wirkt, klick Jetzt aktualisieren.