Wiederherstellbare Abonnementstatus für ein SaaS

Ein Zahlungsanbieter kann eine Belastung verspätet bestätigen, dasselbe Ereignis mehr als einmal senden oder einen Vorgang nur teilweise verarbeiten. Daher sind „bezahlt“ und „hat Zugriff“ nicht gleichbedeutend. Wenn die Berechtigung eines Kontos direkt von der letzten Antwort einer Zahlungs-API abhängt, kann ein vorübergehender Fehler einen Kunden sperren, der tatsächlich bezahlt hat, oder einen anderen aktivieren, dessen Belastung letztlich fehlgeschlagen ist.

Bei Abonnementstatus in PHP-SaaS besteht das Ziel nicht darin, ein einzelnes Label in einer Tabelle zu speichern. Es geht darum, einen wiederherstellbaren Prozess aufzubauen: Jede Entscheidung muss über einen Nachweis, einen Verantwortlichen, einen gültigen Übergang und eine Möglichkeit zur Abstimmung verfügen, wenn neue Daten eintreffen.

Die Produktregeln vor dem technischen Modell definieren

Das Datenmodell löst keine geschäftlichen Unklarheiten. Bevor Entitäten oder Webhooks entworfen werden, müssen Produkt, Finanzen und Betrieb vereinbaren, was in jeder relevanten Situation geschieht.

• Registrierung: Wird Zugriff gewährt, bevor die erste Zahlung bestätigt ist, nach einer Autorisierung oder erst nach der Abwicklung?
• Verlängerung: Wann beginnt die Kulanzfrist, und welche Funktionen bleiben während dieser Zeit erhalten?
• Zahlungsausfall: Gibt es automatische Wiederholungsversuche, Benachrichtigungen, teilweise Einschränkungen oder eine vollständige Sperrung?
• Kündigung: Endet der Zugriff sofort oder erst am Ende des bereits vertraglich vereinbarten Zeitraums?
• Erstattung oder Streitfall: Erfordert dies eine sofortige Sperrung, eine manuelle Prüfung oder einen Widerruf, sobald ein Ergebnis bestätigt wird?
• Reaktivierung: Stellt sie exakt den vorherigen Tarif wieder her, erzeugt sie einen neuen Geschäftszyklus oder erfordert sie eine betriebliche Validierung?

Außerdem ist es sinnvoll, eine vom Kunden angeforderte Kündigung von einer wirksamen Kündigung zu unterscheiden. Erstere drückt eine Absicht aus; letztere verändert das künftige Zugriffsrecht. Werden sie vermischt, entstehen verwirrende Benutzeroberflächen und schwer korrigierbare Automatisierungen.

Vertrag, Abrechnung und tatsächlichen Zugriff trennen

Eine wartbare Architektur bildet mindestens vier Konzepte ab. Das Konto identifiziert den Inhaber und dessen Mitglieder. Der kommerzielle Vertrag beschreibt Tarif, vereinbarten Preis, Verlängerungsdatum und die Kündigungsentscheidung. Der Abrechnungszyklus stellt eine konkrete Verpflichtung für einen Zeitraum, ihren Betrag und ihr Ergebnis dar. Schließlich konkretisieren die aktivierten Berechtigungen, was das Konto innerhalb des Produkts tun darf.

Diese Trennung verhindert, dass ein Zahlungsanbieter zur einzigen Quelle der Wahrheit für das gesamte SaaS wird. Ein Zyklus kann ausstehend sein, während der Vertrag aufgrund einer Kulanzfrist weiterhin gilt. Gleichzeitig kann ein Konto Lesezugriff behalten, aber keine neuen Ressourcen erstellen dürfen. Berechtigungen ermöglichen es, diese Entscheidung auszudrücken, ohne eine falsche Binärität zwischen aktiv und inaktiv zu erzwingen.

In PHP kann eine Anwendung einen Autorisierungsdienst bereitstellen, der eine lokale Projektion von Berechtigungen abfragt, etwa canCreateProject oder canExportData. Diese Projektion wird aktualisiert, wenn sich geschäftliche oder abrechnungsbezogene Fakten ändern; sie muss den Anbieter nicht bei jeder Anfrage aufrufen. Dadurch werden Latenz, externe Abhängigkeit und die Verteilung von Bedingungen über Controller, Queues und geplante Aufgaben reduziert.

Übergänge, Verantwortliche und Nachweise modellieren

Vermeiden Sie ein einziges Feld status mit Werten, die bei auftretenden Vorfällen hinzugefügt werden. Besser ist es, Status pro Aggregat und erlaubte Übergänge zu deklarieren. Beispielsweise kann ein Abrechnungszyklus von open zu payment_pending, paid, failed, refunded oder disputed wechseln. Nicht jeder Übergang ist umkehrbar, und nicht jeder Akteur darf ihn ausführen.

Jede Änderung muss Datum, Ursprung, gegebenenfalls externe Kennung und Nachweis speichern. Der Ursprung kann eine interne Anweisung, ein validierter Webhook, eine Abstimmungsabfrage oder eine autorisierte manuelle Aktion sein. Eine Supportkorrektur darf den Verlauf nicht stillschweigend überschreiben: Sie muss als eigene Entscheidung mit Grund und verantwortlichem Bearbeiter protokolliert werden.

Priorität bei widersprüchlichen Informationen

Definieren Sie, welcher Nachweis Vorrang hat. Ein Weiterleitungsbildschirm nach der Zahlung sollte keinen Zyklus bestätigen: Er dient der Information des Nutzers, nicht als endgültiger Nachweis. Ein signierter und verifizierter Webhook liefert in der Regel ein besseres Signal, kann jedoch verspätet eintreffen. Eine authentifizierte Abfrage beim Anbieter während der Abstimmung kann fehlende Ereignisse klären. Wenn zwei Quellen voneinander abweichen, muss das System in eine Prüfung oder einen definierten ausstehenden Status wechseln, statt willkürlich die zuletzt eingetroffene Information zu wählen.

Verspätete, doppelte und unvollständige Ereignisse verarbeiten

Der Empfang eines Ereignisses muss idempotent sein. Speichern Sie eine stabile Kennung des externen Ereignisses sowie einen Hash oder eine Referenz der relevanten Nutzlast. Wenn es erneut empfangen wird, antworten Sie, ohne die geschäftliche Wirkung zu wiederholen. Das ist besonders wichtig, wenn ein Zahlungsereignis die Ausstellung eines Dokuments, die Verlängerung des Zeitraums oder eine Benachrichtigung auslöst.

Die Verarbeitung muss Empfang und Anwendung trennen. Validieren Sie zuerst Signatur, Schema und Herkunft; speichern Sie danach das empfangene Ereignis dauerhaft; verarbeiten Sie schließlich eine Aufgabe, die versucht, den Übergang anzuwenden. Wenn der Prozess nach dem Persistieren des Ereignisses abstürzt, kann eine Queue oder ein Wiederherstellungsprozess ihn fortsetzen. Wenn er vor dem Persistieren fehlschlägt, muss die Abstimmung die Abweichung entdecken, indem sie die internen Zyklen mit der externen Quelle vergleicht.

Ereignis empfangen → Validierung → dauerhafte Speicherung → idempotente Anwendung
                                      ↓
                              Wiederholung oder Abstimmung

Gehen Sie nicht von einer Zustellreihenfolge aus. Eine Erstattung kann vor einer verspäteten Bestätigung der ursprünglichen Zahlung eintreffen. Die Regeln müssen den aktuellen Status, die Vorgangsreferenzen und die bekannte Reihenfolge bewerten und unmögliche oder mehrdeutige Fälle in einer Prüfqueue belassen. Blind „das zuletzt empfangene Ereignis“ anzuwenden, ist eine häufige Ursache für falsche Berechtigungen.

Abstimmung und Berechtigungen als kontrollierte Projektion

Die regelmäßige Abstimmung ist kein Patch; sie ist Teil des Designs. Sie muss zu lange offene Zyklen, außerhalb des Systems bestätigte Zahlungen, gespeicherte aber unverarbeitete Ereignisse, doppelte externe Referenzen und Berechtigungen finden, die nicht dem geltenden Vertrag entsprechen. Wird eine Abweichung erkannt, protokollieren Sie den Befund und wenden Sie einen nachvollziehbaren Übergang an, anstatt Felder direkt zu aktualisieren.

Die Projektion der Berechtigungen muss explizite Regeln haben. Beispielsweise kann ein geltender Vertrag mit einem überfälligen Zyklus innerhalb der Kulanzfrist wesentliche Funktionen beibehalten; nach Ablauf der Kulanzfrist kann er Schreiboperationen entziehen. Wird eine verspätete Zahlung bestätigt, aktiviert das System die für den Tarif vorgesehenen Berechtigungen erneut und bewahrt den Verlauf der vorherigen Einschränkung.

Ein Berechtigungs-Cache kann nützlich sein, benötigt jedoch eine Invalidierung, wenn sich die Projektion ändert, sowie eine Gültigkeitsbegrenzung. Die kritische Autorisierung darf sich auch nicht nur auf im Browser gespeicherte Daten stützen. Der Server muss anhand der geltenden Berechtigung und des korrekten Geltungsbereichs von Konto, Nutzer und Ressource entscheiden.

Backoffice, Auditierung und Wiederherstellungstests

Das Supportteam muss Vertrag, Zyklen, externe Ereignisse, angewandte Übergänge, aktuelle Berechtigungen und manuelle Aktionen sehen können, ohne Datenbankeinträge zu bearbeiten. Es muss eine Abstimmung anfordern, ein sicheres Ereignis erneut versuchen und eine Prüfung eröffnen können. Korrekturen, die Zugriff oder Saldo verändern, erfordern unterschiedliche Berechtigungen, einen verpflichtenden Grund und einen Audit-Eintrag.

Testen Sie den Ablauf als Folge von Fehlern, nicht nur als korrekte Zahlung. Beziehen Sie bestätigte Verlängerung, unsichere Zahlung, Duplikate, Ereignisse außerhalb der Reihenfolge, Erstattung, Kündigung zum Periodenende und Reaktivierung ein. Prüfen Sie sowohl das Endergebnis als auch, dass kein Wiederholungsversuch zwei Zeiträume, zwei Dokumente oder eine doppelte Erweiterung der Berechtigungen erzeugt.

Ein hypothetischer Fall: Ein Zyklus läuft ab, die Belastung bleibt ausstehend und das Konto tritt mit eingeschränkten Berechtigungen in die Kulanzfrist ein. Der Bestätigungs-Webhook wird wegen einer vorübergehenden Unterbrechung nicht verarbeitet, das Ereignis bleibt jedoch gespeichert. Ein idempotenter Wiederholungsversuch bestätigt den Zyklus, verlängert den Vertrag und stellt die Berechtigungen wieder her. Wäre das Ereignis nicht eingetroffen, würde die Abstimmung den bestätigten externen Vorgang finden und mit ihrem eigenen Nachweis denselben Übergang erzeugen.

Warnsignale und Checkliste

Messen Sie Konten mit inkonsistentem Vertrag und inkonsistenten Berechtigungen, überfällige Zyklen ohne Entscheidung, unverarbeitete Ereignisse, ausgeschöpfte Wiederholungsversuche, durch die Abstimmung erkannte Abweichungen und die Häufigkeit manueller Änderungen. Ein Anstieg manueller Korrekturen weist üblicherweise auf unzureichende Regeln hin, nicht nur auf ein betriebliches Problem.

• Sind Vertrag, Abrechnungszyklus und Berechtigungen getrennte Entitäten?
• Hat jeder Übergang Akteur, Nachweis, Datum und Grund?
• Sind externe Ereignisse idempotent und werden sie vor ihrer Anwendung gespeichert?
• Gibt es eine Abstimmung, die unvollständige Vorgänge wiederherstellen kann?
• Werden Berechtigungen aus einer lokalen Projektion und nicht aus einer Zahlungsantwort in Echtzeit berechnet?
• Kann der Support mit Auditierung untersuchen und korrigieren, ohne direkte Änderungen in der Produktion?
• Decken die Tests Verzögerungen, Duplikate, Unordnung und Widersprüche ab?

Ein wiederherstellbares Modell beseitigt externe Fehler nicht. Es macht sie erkennbar, begrenzt und korrigierbar, ohne einen Abrechnungsvorfall in einen Verlust der Kontrolle über den Zugriff auf das Produkt zu verwandeln.