Abrechnungsfehler: Plan-Prüfungen und Webhook-Lücken schließen

Wie sich Billing-Enforcement-Bugs in der Praxis zeigen

Billing-Enforcement-Fehler treten auf, wenn Ihre Preisseite etwas sagt, das Produkt sich aber anders verhält. Ein Nutzer im Free-Plan klickt einen Button und kann plötzlich exportieren, Kollegen einladen oder teure Premium-AI-Credits verbrauchen, ohne zu bezahlen.

Das erste Anzeichen ist Inkonsistenz. Ein Kunde wird blockiert, ein anderer mit demselben Plan nicht. Der Zugriff ändert sich nach einem Refresh, Logout oder Upgrade-Versuch. Support-Tickets klingen plötzlich wie: „Es hat gestern funktioniert“, „Mein Kollege kann es, ich nicht“ oder „Ich habe upgegradet, aber es steht noch, dass ich gesperrt bin.“

Prototypen sind besonders anfällig, weil dort oft die langweiligen Schutzmaßnahmen übersprungen werden. Die erste Version verlässt sich vielleicht auf einen versteckten Button, eine Frontend-Prüfung oder ein einzelnes plan-Feld in einer User-Tabelle. Das wirkt in Demos ok, bricht aber sobald echtes Billing, Webhooks und echte Nutzer auftreten.

Enforcement ist es, jedes Mal vier Fragen zu beantworten, wenn eine wertvolle Aktion angefragt wird:

• Wer ist der Nutzer und zu welchem Account/Workspace gehört er?
• Welcher Plan und welche Add-ons sind gerade aktiv?
• Welche genaue Aktion versucht der Nutzer auszuführen?
• Sollte der Server sie erlauben (nicht nur die UI)?

Wenn diese Antworten unklar sind oder über zu viele Orte verteilt sind, tauchen Bugs auf. Ein klassisches Beispiel: Jemand fügt einen neuen „Pro-only“-Endpoint hinzu, vergisst aber die gleiche Prüfung in einem Hintergrundjob, der ihn aufruft. Die UI versteckt das Feature, aber der Endpoint ist direkt oder indirekt erreichbar.

Wenn Sie ein AI-erstelltet SaaS-Prototyp (Lovable, Bolt, v0, Cursor, Replit) geerbt haben, sind solche Lücken üblich. FixMyMess findet oft fehlende Plan-Prüfungen in ein oder zwei kritischen Pfaden sowie mindestens eine Stelle, an der Billing-Zustand angenommen statt verifiziert wird. Das reicht meist, damit bezahlte Features stillschweigend kostenlos werden.

Kartieren Sie die Stellen, an denen Zugriff durchgesetzt werden sollte

Die meisten Billing-Enforcement-Bugs entstehen, weil der Zugriff an einer Stelle geprüft wird und an der nächsten übersprungen. Der schnellste Weg, kostenlosen Zugriff auf bezahlte Funktionen zu stoppen, ist, jede „kostenpflichtige Aktion“, die ein Nutzer auslösen kann, zu kartieren und sicherzustellen, dass jeder Pfad dieselbe Regel trifft.

Beginnen Sie mit kostenpflichtigen Aktionen in Nutzersprache: „CSV exportieren“, „Kollegen einladen“, „Bericht ausführen“, „Wasserzeichen entfernen“. Übersetzen Sie dann jede in die tatsächlichen Ausführungspfade: die API-Route, jeden Hintergrundjob, den sie queuet, und alle UI-Pfade (auch versteckte Buttons), die noch die API aufrufen können.

Setzen Sie Prüfungen zuerst auf dem Server. Die UI kann Buttons verstecken, aber ihr kann nicht vertraut werden. Wenn ein Endpoint aufgerufen werden kann, muss er bei jedem Aufruf Berechtigungen validieren.

Systeme, die in Ihre Karte gehören

Schreiben Sie jedes System auf, das Entitlements berührt, auch wenn der Code chaotisch ist:

• App-Datenbank (User-, Org/Workspace-, Subscription- oder Entitlement-Tabellen)
• Auth-Schicht (Sessions, JWT-Claims, Rollen)
• Billing-Provider (Pläne, Subscriptions, Rechnungen)
• Webhooks und Event-Verarbeitung (inklusive Retries und Verzögerungen)
• Caches/Queues (alles, das veralteten Zugriff ausliefern kann)

Wenn Sie das Gesamtbild sehen, wählen Sie eine einzige Quelle der Wahrheit für Entitlements und bleiben Sie dabei. Für die meisten SaaS-Apps ist das ein Entitlement-Record in der eigenen Datenbank, der „was dieser Workspace gerade darf“ darstellt, von Webhooks aktualisiert und bei wichtigen Aktionen verifiziert.

Ein häufiger Prototyp-Fehler: Plan-Prüfungen sind über Frontend-Code, ein paar API-Routen und einen Webhook-Handler verteilt. Das Ergebnis ist inkonsistenter Zugriff und schwer reproduzierbare Lecks. Ein einzelnes Entitlement-Modell plus ein gemeinsamer serverseitiger Guard schließt die meisten Lücken schnell.

Schritt für Schritt: Plan-Prüfungen reparieren, damit bezahlte Funktionen gesperrt bleiben

Billing-Enforcement bricht, wenn Regeln verstreut sind. Ein Endpoint prüft den Plan, ein anderer vertraut einem UI-Flag, ein dritter vergisst überhaupt zu prüfen. Die Lösung ist simpel: Zentralisieren Sie die Entscheidung und verwenden Sie sie überall wieder.

1) Finden Sie jede Stelle, die eine kostenpflichtige Aktion auslösen kann

Erstellen Sie ein Inventar von Server-Routen und Hintergrundjobs, die etwas Wertvolles tun: Daten exportieren, Kollegen einladen, Limits entfernen, Berichte erzeugen, Premium-AI-Aufrufe nutzen und Admin-Aktionen. Wenn es Daten ändert oder Geld kostet, braucht es ein Gate.

Fügen Sie dann einen Guard an einer Stelle hinzu, den alle kostenpflichtigen Routen nutzen. Schreiben Sie die Prüfungen nicht in jedem Handler neu.

2) Verlegen Sie alle Zugriffsentscheidungen auf den Server

Behandeln Sie alles vom Client als Hinweis, nicht als Wahrheit. UI-Flags wie isPro, Werte in localStorage und versteckte Buttons sind leicht zu fälschen. Der Server sollte basierend auf Ihren gespeicherten Entitlements entscheiden.

Ein praktisches Muster ist, „was erlaubt ist“ aus einer Funktion zu berechnen, die ein Entitlement-Record verwendet. Free darf Dashboards sehen, aber nicht exportieren. Pro darf exportieren. Der Schlüssel ist, dass jeder Endpoint dieselbe Entscheidung nutzt.

Eine kleine Checkliste für den Guard:

• Laden Sie den Nutzer und sein aktuelles Entitlement-Record aus Ihrer Datenbank.
• Berechnen Sie allowedFeatures in einer Funktion (keine ad-hoc-Prüfungen in mehreren Dateien).
• Standardmäßig blocken, wenn Daten fehlen oder unklar sind.
• Geben Sie eine klare Fehlermeldung zurück: was wurde blockiert und warum.
• Loggen Sie die Entscheidung mit Nutzer-ID und Entitlement-Version.

Klare Fehler helfen dem Support („Export erfordert Pro. Ihr Plan ist Free.“). Sie machen Logs auch durchsuchbar, wenn jemand sagt: „Ich habe bezahlt, aber es steht trotzdem gesperrt.“

3) Fügen Sie ein paar Tests hinzu, die Lecks früh erkennen

Halten Sie es einfach. Drei Tests reichen: ein Free-User wird geblockt, ein zahlender User ist erlaubt, und ein User mit fehlenden Entitlement-Daten wird geblockt. Diese drei fangen viele Revenue-Lecks, bevor sie in Produktion gelangen.

Wenn Sie ein AI-generierten SaaS-Prototyp geerbt haben, beginnen Teams wie FixMyMess oft damit, diese Guards zu zentralisieren, weil das Lecks stoppt, ohne einen kompletten Rewrite zu erzwingen.

Webhooks: mit fehlenden, doppelten und späten Events umgehen

Webhooks sind nicht garantiert. Sie können verspätet ankommen, doppelt, außer der Reihenfolge oder gar nicht. Wenn Ihre App annimmt „wir haben den Webhook erhalten, also ist der Zugriff korrekt“, werden Sie weiter Billing-Enforcement-Bugs sehen.

Behandeln Sie Webhooks als Benachrichtigung über eine Änderung, nicht als die Änderung selbst. Ihre App muss jetzt in der Lage sein zu beantworten: „Was darf dieser Kunde gerade?“, auch wenn das letzte Event verzögert ist.

Webhook-Verarbeitung sicher und vertrauenswürdig machen

Beginnen Sie damit, das Event zu verifizieren. Prüfen Sie die Signatur des Providers, lehnen Sie nicht vertrauenswürdige Payloads ab und schalten Sie Features nicht allein auf Basis eines Webhook-Felds frei. Cross-checken Sie gegen Ihren aktuellen Kundenstatus.

Machen Sie Handler idempotent. Wenn dasselbe Event zweimal verarbeitet wird, sollte das Ergebnis identisch sein.

Eine kurze Checkliste, die die meisten Revenue-Lecks verhindert:

• Verifizieren Sie Signaturen und lehnen Sie fehlschlagende Requests ab.
• Speichern Sie eine Event-ID und ignorieren Sie Duplikate, die Sie bereits verarbeitet haben.
• Wenden Sie Änderungen nur an, wenn das Event neuer ist als das, was Sie gespeichert haben.
• Prüfen Sie das aktuelle Subscription-/Entitlement-Status, bevor Sie Zugriff gewähren.
• Loggen Sie Fehler mit genug Details, um später sicher replayen zu können.

Mit außer-der-Reihenfolge und fehlenden Events umgehen

Außer-der-Reihenfolge-Events sind bei Upgrades, Refunds und Stornierungen üblich. Nutzen Sie Timestamps (oder Sequenznummern, falls vorhanden) und vergleichen Sie mit Ihrem gespeicherten Zustand. Wenn ein älteres „Trial gestartet“-Event nach „paid canceled“ ankommt, überschreiben Sie nicht den neueren Zustand.

Für fehlende Events bauen Sie einen sicheren Retry-Pfad: Queue den Webhook, retry die Verarbeitung und alert, wenn die Retries fehlschlagen. In Prototypen, die diese Schutzmaßnahmen überspringen, kann ein verlorenes Event dazu führen, dass bezahlte Features Tage lang geöffnet bleiben.

Eine gute Regel: Webhooks aktualisieren Ihre Records, aber Ihr Produkt entscheidet basierend auf Ihren eigenen aktuellen Entitlements, nicht auf dem letzten Webhook, den Sie zufällig erhalten haben.

Race-Conditions bei Upgrades und Downgrades

Race-Conditions sind ein einfacher Weg, wie Billing-Enforcement-Fehler entstehen. Sie treten auf, wenn zwei Teile Ihrer App gleichzeitig einen Kundenplan lesen oder schreiben und einer veraltete Daten sieht. Das Ergebnis ist meist kostenloser Zugriff (oder zufällige Sperren) genau dann, wenn jemand den Plan ändert.

Ein häufiges Muster: Der Nutzer klickt auf Upgrade, die UI schaltet sofort auf „Pro“, aber die serverseitige Zugriffskontrolle liest noch den alten Plan aus der Datenbank (oder dem Cache). Wenn Ihre API dem UI-Status vertraut, erhält der Nutzer bezahlte Funktionen bevor etwas bestätigt ist. Wenn die API alten Zustand liest, zahlt der Nutzer, sieht aber weiterhin „gesperrt“, bis ein Refresh alles korrigiert.

Eine Lösung ist, jede Planänderung durch einen einzigen Backend-Path zu zwingen. Lassen Sie nicht zu, dass UI, Webhook-Handler und ein nächtlicher Cron-Job unterschiedlich in dieselben Entitlement-Felder schreiben. Wählen Sie einen Owner für Entitlements und lassen Sie alles andere darüber laufen.

Es hilft auch, Zustände aufzuteilen, damit die App ehrlich sein kann, was gerade passiert:

• Payment started (Checkout erstellt)
• Payment confirmed (Provider meldet bezahlt)
• Entitlement granted (Ihr System hat Zugriff gesetzt)
• Entitlement revoked (Downgrade wirksam)

Um doppelte Writes zu verhindern, fügen Sie einen kurzlebigen Lock oder eine Versionsprüfung am Kundenrecord während Plan-Änderungen hinzu. Speichern Sie z. B. eine entitlements_version. Beim Anwenden eines Upgrades schreiben Sie nur, wenn die Version der erwarteten entspricht, und inkrementieren Sie dann. Wenn sie sich geändert hat, retryen Sie mit frischen Daten.

Konkretes Beispiel: Ein Nutzer upgradet, und gleichzeitig „fixt“ ein Cron-Job Subscriptions indem er gestern’s Plan resynct. Ohne Lock oder Versionscheck kann der Cron-Write zuletzt landen und das Upgrade rückgängig machen. Die UI zeigt vielleicht Pro während die API ihn als Free gated, oder umgekehrt.

Wenn Sie ein AI-generiertes Prototype geerbt haben, ist das ein häufiger Befund: mehrere Plan-Writes, keine einzige Quelle der Wahrheit und Zugriffschecks, die davon abhängen, wer das Rennen gewinnt.

Machen Sie Entitlements zu einem sauberen, konsistenten Datenmodell

Die meisten Billing-Enforcement-Bugs beginnen mit verstreuter Wahrheit. Ein Teil der App prüft einen Plan-String im User-Record. Ein anderer prüft ein Flag beim Billing-Provider. Ein dritter prüft, ob eine Subscription existiert. Wenn diese nicht übereinstimmen, bekommen Leute entweder bezahlte Features kostenlos oder zahlende Kunden werden blockiert.

Beheben Sie das, indem Sie ein einzelnes Entitlement-Record erstellen, das Ihre App als Quelle der Wahrheit behandelt. Speichern Sie es in einer Tabelle (oder einem Dokument) und aktualisieren Sie es per Webhooks und verifizierten Checkout-Resultaten. Fügen Sie Timestamps hinzu, damit Sie nachvollziehen können, was wann geändert wurde.

Ein praktisches Entitlement-Record enthält üblicherweise:

• Aktueller Plan (free, pro, team)
• Subscription-Status (active, trialing, past_due, canceled)
• Period start und period end (Erneuerungsdatum)
• Entitlement-Version und updated_at (für Debugging und Replay)
• Grace-Policy und grace_until (falls Sie Grace erlauben)

Definieren Sie Grace-Perioden in klarer Sprache und kodieren Sie sie ins Modell. Zum Beispiel: Lesezugriff für 3 Tage nach fehlgeschlagener Zahlung erlauben, aber Exporte und kostenpflichtige API-Calls sofort blocken. Ziel ist, „was erlaubt ist“ an Status und Zeit zu binden, nicht an einen Haufen Einzelfall-Conditionals.

Entscheiden Sie außerdem, was bei fehlgeschlagenen Zahlungen passiert. Sofortige Sperre ist die einfachste Option. Limitierter Zugriff kann Churn reduzieren, aber nur, wenn er konsistent im ganzen Produkt angewandt wird.

Behandeln Sie Admin-Overrides als erstklassige Daten. Sie werden oft zur versteckten Ursache von Billing-Bugs, weil niemand sieht, warum ein Nutzer entsperrt ist. Protokollieren Sie, wer das Override gesetzt hat, wann und warum. Fügen Sie ein Ablaufdatum für temporäre Freischaltungen hinzu. Machen Sie Override-Status in Ihrem Admin-UI sichtbar. Loggen Sie Entitlement-Entscheidungen (zumindest im Debug-Modus), damit Sie Allow/Deny ohne Rätselraten erklären können.

Wenn Sie ein AI-generiertes Prototype geerbt haben, finden Sie häufig 3–5 konkurrierende Entitlement-Quellen. Das Zusammenführen ist meist der schnellste Weg, Lecks zu stoppen, ohne die ganze App neu zu schreiben.

Randfälle, die häufig Revenue durchlassen

Billing-Enforcement-Bugs leben selten im Happy-Path. Sie zeigen sich, wenn Nutzer ihre Meinung ändern, Accounts teilen oder Timing-Probleme auftreten, die Ihr Prototyp nie gesehen hat.

Trial- vs Paid-Regeln können auf überraschende Weise kollidieren. Ein häufiger Fehler ist, isTrialActive zuerst zu prüfen und frühzeitig zurückzugeben, selbst nach einem Upgrade. Das kann Trial-Limits auf bezahlte Nutzer anwenden oder schlimmer: Trial-Zugriff gewähren, der permissiver ist als bezahlter Zugriff. Machen Sie „paid schlägt trial“ zur expliziten Regel.

Downgrades sind ein weiteres leises Leck. Wenn Sie Features nur beim Login sperren, kann ein Nutzer einen offenen Tab behalten und nach dem Downgrade weiter bezahlte Features nutzen. Dasselbe passiert bei zu langen Caches. Wenn ein Plan sich ändert, braucht Ihre App einen schnellen Weg, Zugriffe neu zu prüfen (oder gecachte Zugriffe zu invalidieren), bevor sensible Aktionen ausgeführt werden.

Refunds und Chargebacks benötigen eine klare Policy für Zugriff und Daten. Wenn Sie nichts tun, könnten Sie nach Rückbuchung unbegrenzten Zugriff gewähren.

Ein paar chaotische Fälle, die Sie testen sollten:

• Zwei aktive Subscriptions (Nutzer hat zweimal abonniert oder ohne Kündigung den Plan gewechselt)
• Workspace- vs User-Billing-Mismatch (ein Mitglied erbt versehentlich den Plan des Owners)
• Rollen-Bypass (Admins haben vollen Zugriff selbst im Free-Plan)
• Alte „grandfathered“-Flags, die aktuelle Planprüfungen überschreiben
• Manuelle Rechnung als bezahlt markiert, ohne Entitlements zu aktualisieren

Ein häufiges Szenario: Der Team-Owner upgradet und downgradet sofort, und ein Webhook kommt verspätet an. Wenn Ihre App beim Upgrade entsperrt, aber beim Downgrade nie wieder sperrt, bleiben Features offen.

Häufige Fehler und Fallen zum Vermeiden

Billing-Enforcement-Bugs passieren meist, weil Regeln an zu vielen Stellen leben und nicht alle übereinstimmen. Ein Prototyp kann in der UI sauber aussehen, während das Backend immer noch kostenpflichtige Endpoints erlaubt.

Der schnellste Weg, Revenue zu leaken, ist Zugriffskontrolle als Frontend-Problem zu behandeln. Buttons und Bildschirme sind leicht mit direkten API-Calls, gespeicherten Requests oder einfachen Skripten zu umgehen.

Häufige Fehler:

• UI-only Gating: Feature in der App verstecken, aber den Plan auf dem Server nie prüfen.
• Verstreute Plan-Prüfungen: Verschiedene Dateien nutzen verschiedene Regeln (Plan-Name hier, Price-ID dort, Trial-Logik irgendwo anders).
• Blindes Vertrauen in Webhook-Payload-Felder: Plan-Status aus einem Event akzeptieren, ohne ihn gegen Ihre Records zu prüfen.
• Keine Webhook-Sicherheit: Retries, Duplikate oder Out-of-Order-Events ignorieren und versehentlich Zugriff wieder freigeben.
• Gemischte Umgebungen: Dev-Keys in Produktion (oder umgekehrt), so dass Sie die falschen Daten „fixen“ und der Bug wiederkehrt.

Ein weiterer Klassiker: Ein Nutzer upgradet, die UI zeigt Pro, aber das Backend liest einen alten gecachten Plan für 10 Minuten. Dieses Fenster reicht, um Exporte oder andere kostenpflichtige Aktionen zu erzeugen.

Wenn Sie AI-generierten Code geerbt haben, sind diese Probleme oft in kopierten Prüfungen eingebettet. Das Konsolidieren der Logik in einer serverseitigen Entitlement-Prüfung und das Härten der Webhook-Verarbeitung reduzieren die Chance, dass der Bug nach dem nächsten Refactor zurückkommt.

Bevor Sie veröffentlichen, machen Sie zwei einfache Tests:

1. Rufen Sie den kostenpflichtigen API-Endpoint direkt aus einem Free-Account auf.

2. Replayen Sie dasselbe Upgrade-Webhooks zweimal, schicken Sie dann ein spätes Downgrade-Event und bestätigen Sie, dass der Zugriff im richtigen Zustand endet.

Schnelle Checks vor dem Relaunch

Vor dem Relaunch eines Prototyps führen Sie ein paar schnelle Checks durch, die die meisten Billing-Enforcement-Bugs finden. Sie beantworten zwei Fragen: Kann jemand bezahlten Wert bekommen, ohne zu zahlen, und können legitime Kunden geblockt werden?

Ein schneller Durchgang in unter einer Stunde mit einem Testnutzer und Ihren Logs:

• Versuchen Sie bezahlte Aktionen mit einem Free-Account, indem Sie die API direkt anrufen (nicht die UI). Wenn ein kostenpflichtiger Endpoint Erfolg zurückgibt, haben Sie ein Leck.
• Upgraden Sie einen Test-Account und aktualisieren Sie in einem neuen Gerät oder Inkognito-Fenster. Zugriff sollte schnell freigeschaltet werden und auch 10 Minuten später noch aktiv sein.
• Downgraden oder simulieren Sie eine fehlgeschlagene Zahlung, dann wiederholen Sie die gleichen kostenpflichtigen Aktionen. Sie sollten zuverlässig blockiert werden, selbst wenn die UI noch alte Buttons zeigt.
• Replayen Sie Billing-Webhooks. Handler sollten sicher mehrfach laufen und das Ergebnis sollte in den Logs klar erkennbar sein.
• Öffnen Sie einen internen Screen, der die aktuellen Entitlements, deren Quelle (Plan, Add-on, Trial) und den letzten Update-Zeitstempel zeigt.

Ein nützlicher Real-World-Test: Upgraden Sie einen Nutzer und starten Sie sofort einen großen kostenpflichtigen Job (Export, AI-Run, Bulk-Action). Wenn der Job startet bevor Entitlements aktualisiert sind, haben Sie eine Race gefunden. Fixes beinhalten meist, Entitlements serverseitig beim Aktionszeitpunkt zu prüfen und den Upgrade-Flow warten zu lassen, bis der neue Zustand bestätigt ist.

Prüfen Sie auch Ihr Logging. Wenn etwas schiefgeht, sollten Sie ohne Spekulation beantworten können: „Warum wurde diese Anfrage erlaubt/abgelehnt?“:

• Anfrage erlaubt/abgelehnt weil Entitlement X true/false war.
• Webhook Event-ID, Status (processed/skipped) und Grund.
• Alter vs neuer Entitlement-Zustand mit Timestamps.

Beispiel: Das Upgrade, das Features kostenlos aufsperrt

Ein häufiges Leck sieht harmlos aus: Ein Nutzer klickt Upgrade, sieht „Pro“ in der UI und nutzt sofort bezahlte Funktionen. Später stellen Sie fest, dass er nie tatsächlich bezahlt hat oder die Zahlung fehlgeschlagen ist, und trotzdem hatte er Zugriff.

Stellen Sie sich einen hektischen Moment vor (Launch, Promo-Mail oder Demo-Call). Ein Nutzer upgradet, während Ihre App unter Last steht, der Billing-Provider ist langsam, und Ihre App behandelt „Checkout gestartet“ als „jetzt Pro“.

Wo sich der Bug versteckt

Die UI schaltet basierend auf einem lokalen Flag auf Pro. Das Backend sieht aber weiterhin Free, weil das echte Entitlement erst aktualisiert wird, wenn ein Webhook ankommt.

Wenn Ihr Feature-Check Client-Status, einen gecachten Session-Record oder eine verzögerte DB-Lesung vertraut, kann der Nutzer durchrutschen.

Wie man ihn zuverlässig reproduziert

Oft reicht ein einfacher Ablauf:

• Öffnen Sie zwei Tabs eingeloggt.
• In Tab A klicken Sie Upgrade und schließen den Checkout ab.
• In Tab B refreshen Sie und rufen schnell eine kostenpflichtige Funktion auf (oder spammen den Action-Button).
• Fügen Sie eine Verzögerung in der Webhook-Verarbeitung hinzu (oder testen Sie in einer langsamen Umgebung) und beobachten Sie das Ergebnis.

Wenn die kostenpflichtige Aktion erfolgreich ist bevor das Webhook Entitlements updated, haben Sie eine Lücke.

Praktische Fixes, die die Lücke schließen

Behandeln Sie Upgrades als Zustandsmaschine auf dem Server, nicht als UI-Umschaltung:

• Serverseitiger Guard: Jede kostenpflichtige Aktion prüft Server-Entitlements, nicht das Client-Plan-Label.
• Pending-Zustand: Wenn Checkout gestartet wird, setzen Sie einen Status wie pending_upgrade und halten kostenpflichtige Features gesperrt (oder erlauben nur begrenzten Preview-Zugriff).
• Idempotente Webhook-Verarbeitung: Dasselbe Event sicher zweimal verarbeiten und Out-of-Order-Events mit Event-ID und Timestamps ignorieren.

Zur Bestätigung wiederholen Sie den Zwei-Tab-Test und prüfen die Logs: kostenpflichtige Aktionen werden bis zur echten Aktivierung des Entitlements abgelehnt und danach erlaubt.

Wenn Sie ein AI-gebautes Prototype geerbt haben (Lovable, Bolt, v0, Cursor, Replit), tritt dieser Bug oft auf, weil der Plan an mehreren Stellen gespeichert wird. FixMyMess löst das typischerweise, indem alle Plan-Prüfungen getraced, auf eine Server-Quelle der Wahrheit gezogen und die Webhook-Logik gehärtet wird, damit „Pro“ wirklich nur bezahlt bedeutet.

Nächste Schritte: Revenue-Lecks schließen, ohne alles neu zu bauen

Schreiben Sie zuerst genau auf, welche Aktionen bezahlt sein sollten. Verwenden Sie einfache Begriffe: „Bericht exportieren“, „Kollegen einladen“, „Wasserzeichen entfernen“, „Premium-Modell nutzen.“ Diese Liste wird Ihre Checkliste.

Wählen Sie eine Stelle auf dem Server als Gatekeeper und lassen Sie alles darüber laufen. Wenn Ihre App Pläne in fünf Dateien prüft (oder nur in der UI), werden Sie eine Stelle übersehen.

Eine praktische Reihenfolge für die meisten Teams:

• Listen Sie kostenpflichtige Aktionen und fügen Sie einen serverseitigen Guard hinzu, den alle kostenpflichtigen Endpoints nutzen.
• Härten Sie die Webhook-Verarbeitung: Signaturen verifizieren, Events speichern und idempotent verarbeiten.
• Fügen Sie Retries für fehlgeschlagene Webhook-Verarbeitung hinzu und behandeln Sie späte Events so, dass Zugriff nicht inkonsistent wird.
• Stresstesten Sie Upgrades: langsame Netze, Doppel-Klicks und zwei Geräte, die gleichzeitig upgraden.
• Überprüfen Sie Downgrades und Refunds, sodass Zugriff zuverlässig kippt.

Bevor Sie Logik ändern, entscheiden Sie, welcher „Wahrheit“ Sie im Upgrade-Fenster vertrauen. Sie können Zugriff erst nach bestätigter Zahlung gewähren oder temporären Zugriff für kurze Zeit erlauben und ihn automatisch zurücknehmen, wenn die Zahlung nicht abgeschlossen wird. Beide Ansätze funktionieren, müssen aber konsistent sein.

Wenn Sie mit einem AI-generierten Prototype arbeiten, kommen Billing-Probleme oft zusammen mit anderen Problemen wie chaotischer Auth, offengelegten Secrets oder verwirrender Architektur. Wenn Sie eine zweite Meinung wollen: FixMyMess bietet Audits und Reparaturen für AI-generierte Codebasen an, inklusive Entitlement-Logik, Webhook-Härtung, Security-Hardening und Deployment-Prep.

FixMyMess bietet zudem ein kostenloses Code-Audit an, um zu zeigen, wo Zugriff durchläuft, und repariert Plan-Prüfungen sowie Webhook-Randfälle mit menschlicher Verifikation meist innerhalb von 48–72 Stunden.