Zum Inhalt springen
← Alle Beiträge

11. September 2026

Deine App schaltet sich selbst frei

Der Kauf-Dialog meldet Erfolg, die App schaltet Pro frei. Damit entscheidet die App selbst, wer bezahlt hat. Umgehen lässt sich das in Sekunden.

Der Kauf ist durch, die App zeigt “Erfolg” und schaltet die Bezahl-Funktionen frei. Der Nutzer sieht sofort, was er gekauft hat. Das fühlt sich richtig an.

Genau daran hängt das Problem. Die App hat gerade selbst entschieden, dass jemand bezahlt hat.

Was die KI dir gebaut hat

Wenn du eine KI nach einer Bezahl-Funktion fragst, merkt sich die App den Kauf oft direkt auf dem Gerät des Nutzers. Ein kleiner Merker, etwa “hat bezahlt: ja”. Beim nächsten Start liest die App den Merker und schaltet frei.

Das läuft. Der Testkauf funktioniert, die Freischaltung bleibt, das Feature ist fertig.

Nur steht der ganze Beweis für die Zahlung auf dem Gerät des Nutzers. Und dort kann er ihn ändern.

Der Test dauert zehn Sekunden

In jedem Browser lässt sich der Merker von Hand umstellen. Dafür braucht es keine Hacker-Kenntnisse und kein Werkzeug. Wer weiß, wo er hinschauen muss, setzt den Merker auf “ja”, lädt die Seite neu und hat alles offen. Ohne einen Cent zu zahlen.

Frag deinen Entwickler oder die KI direkt: “Wenn ich den Merker für die Bezahlung selbst umstelle, ist Pro dann offen?” Die Antwort sagt dir, wie es um deine App steht.

Die zweite Variante: die App schreibt in die Datenbank

Manchmal gibt es ein Backend, und die App trägt dort selbst ein, dass der Nutzer bezahlt hat. Das sieht sicherer aus, weil eine Datenbank dahintersteckt. Es ändert nichts. Die App schreibt, und was die App schreiben darf, kann jeder Besucher mit etwas Geschick genauso schreiben.

Die Information “hat bezahlt” gehört dem Server. Die App liest sie und trägt sie nie selbst ein.

Wie es richtig läuft

Der Server weiß, wer bezahlt hat, weil der Zahlungsanbieter es ihm meldet (der Post davor erklärt, worauf es dabei ankommt). Die App fragt den Server: “Darf dieser Nutzer Pro?” Der Server antwortet, und die App richtet sich danach.

Nach einem Kauf setzt die App deshalb nichts selbst. Sie fragt den Server noch einmal. Der Kauf-Dialog ist nur das Signal, dass sich etwas getan hat. Bewiesen ist erst, was der Server bestätigt.

Ein Punkt wird gern übersehen: Es reicht nicht, einen Knopf auszugrauen. Wenn der Export-Button gesperrt ist, der Export dahinter aber jeden bedient, ist die Sperre nur Dekoration. Jede bezahlte Funktion prüft die Berechtigung selbst, dort, wo sie ausgeführt wird.

Wo es trotzdem klemmen kann

Niemand fragt bei jedem Klick den Server. Die App merkt sich die Antwort für eine Weile. Dafür brauchst du drei Entscheidungen:

Wie lange gilt die Antwort. So lange läuft ein gekündigtes oder erstattetes Abo weiter. Wenige Minuten sind in Ordnung. Eine Woche ist eine Woche Gratis-Zugang nach der Kündigung.

Was passiert bei Ablauf. Kommt keine frische Antwort mehr, fällt die App auf die kostenlose Version zurück. Ohne Ablaufdatum bleibt eine einmal erteilte Freischaltung für immer.

Was gilt offline. Ein zahlender Nutzer im Zug soll seine App benutzen können. Der letzte bekannte Stand gilt bis zum Ablaufdatum, danach ist Schluss. Bei Jahresabos gilt eine Obergrenze, sonst läuft eine App elf Monate ohne Serverkontakt.

Wo das gesammelt liegt

Server-Freischaltung, Prüfung an jeder bezahlten Funktion, Ablaufzeiten: Das hängt zusammen, und keine dieser Stellen meldet sich von selbst, wenn sie fehlt. Dazu kommt, was erst im echten Betrieb auftaucht. Was passiert bei einer Rückerstattung mitten im Abo-Zeitraum? Wie laufen Testphase und erste Abbuchung auseinander? Ab wann gilt ein Abo als gekündigt?

Der Payment-Guide stellt das geordnet zusammen.

Diese Woche reicht eine Frage an deine App oder deinen Entwickler: Wer entscheidet bei uns, ob jemand bezahlt hat? Lautet die Antwort “die App selbst”, weißt du, was zu tun ist.

Michael Schreier
Michael Schreier

Diplom-Informatiker · 25 Jahre Entwicklung · LinkedIn

paymentsicherheitvibe-codingentitlement
praxis-guides
$ guide --open "Payment & Web-Checkout Best Practice"
[i] Bezahlung steht einmal richtig: Web-Checkout und In-App-Payment sauber getrennt, Store-Gebühren umgangen wo die Regeln es zulassen, keine Neuimplementierung ein Jahr später.

PDF plus Beispiele · 239 € inkl. MwSt. (200,84 € netto) · framework-unabhängig

Payment & Web-Checkout Best Practice
Michael Schreier

Fragen zum Thema?

Schreib mir — ich freue mich auf den Austausch.