BillingMeld: Warum der Server die Käufe überprüfen sollte, nicht die App

Der Kauf innerhalb einer mobilen Anwendung scheint für den Nutzer meistens einfach zu sein. Er drückt auf die Schaltfläche, bestätigt die Zahlung, erhält Zugriff auf eine Funktion oder ein Abonnement — und erwartet, dass alles danach automatisch funktioniert.

Für den Entwickler beginnt hinter dieser Schaltfläche jedoch ein wesentlich komplexerer Prozess. Es muss der eigentliche Kauf bestätigt werden, Verlängerungen, das Ende des Abonnements, Rückerstattungen, Operationenreviews, Gerätewechsel und Unterschiede zwischen Apple- und Google-Shops berücksichtigt werden.

Das Hauptproblem entsteht, wenn der Server anfängt, die Client-Anwendung als alleinige Wahrheit zu betrachten.

Wenn die App meldet: «Kauf erfolgreich», öffnet der Server den Zugriff und orientiert sich an diesem einmalig erhaltenen Status. Doch der Lebenszyklus des Kaufs endet hier nicht.

Ein Abonnement kann verlängert werden, automatische Verlängerung kann deaktiviert werden, eine Zahlung kann rückerstattet oder die Transaktion vom Shop widerrufen werden.

Deshalb bestätigt bei BillingMeld nicht die App, sondern der Server den Kauf.

Der Kunde informiert, aber entscheidet nicht allein

In der Architektur von BillingMeld ist die mobile App nicht die Hauptquelle für Kaufinformationen.

Der Kunde kann Daten über den abgeschlossenen Vorgang übermitteln, doch das ist nur die Grundlage für die Überprüfung. Die endgültige Entscheidung trifft die Server-Komponente von BillingMeld, die die Informationen über die Infrastruktur von Apple oder Google überprüft.

Dies ist ein grundsätzlicher Unterschied.

Die App auf dem Telefon kann mit veraltetem Status arbeiten, rechtzeitig keine Änderungen erhalten oder Informationen übermitteln, die bereits nicht mehr dem aktuellen Kaufstatus entsprechen.

Außerdem darf der Kunde nicht selbst entscheiden, ob ihm ein kostenpflichtiger Zugang zusteht.

BillingMeld prüft beispielsweise:

• Ob ein solcher Kauf tatsächlich existiert;

• Ob er sich auf die richtige App und das richtige Produkt bezieht;

• Ob die bezahlte Periode aktuell aktiv ist;

• Ob eine Verlängerung stattgefunden hat;

• Ob die automatische Verlängerung deaktiviert wurde;

• Ob eine Rückerstattung erfolgt ist;

• Ob eine Operation widerrufen wurde;

• Ob die bezahlte Periode noch andauert.

Damit wird die Nachricht des Kunden nicht mehr zum Nachweis des Kaufs, sondern zum Anlass, den tatsächlichen Status zu überprüfen.

Einheitliche Quelle der Wahrheitsaussage für Server

Angekoppelte Dienste müssen nicht gleichzeitig die vollständigen Integrationsprozesse mit Apple und Google umsetzen.

Sie wenden sich an BillingMeld und erhalten einen bereits normalisierten Kaufstatus.

Zum Beispiel: Zugriff aktiv, bezahlte Periode abgelaufen, Verlängerung bestätigt, automatische Verlängerung deaktiviert oder Kauf widerrufen.

Das ermöglicht eine klare Verantwortungszuweisung.

Apple und Google sind die Quellen des Status der jeweiligen Shop-Operation. BillingMeld überprüft diese Daten, bringt sie in ein gemeinsames Modell und speichert den aktuellen Status. Das Abschlussprodukt entscheidet dann anhand des Status von BillingMeld, ob Zugriff besteht.

Für Produkt-Server bedeutet dies einen einheitlichen Vertrag statt mehrerer unabhängiger Integrationen.

Es ist nicht mehr notwendig, in jedem Service eigene Regeln für den App Store oder Google Play zu implementieren und dann verschiedene Formate, Events und Stati an eine gemeinsame Logik anzupassen.

Warum man dem Kunden nicht vollständig vertrauen sollte

Die Client-App läuft auf dem Gerät des Nutzers.

Sie kann geschlossen, neu gestartet, aus einem Backup wiederhergestellt, später aktualisiert oder auf einem anderen Gerät gestartet werden. Sie kann längere Zeit mit veraltetem Status arbeiten oder ein Ereignis gar nicht erst erhalten, das nach der ursprünglichen Transaktion eingetreten ist.

Selbst ohne jegliches Eingreifen des Nutzers ist dies kein zuverlässiger Endstatus für den Abonnementstatus.

Beispielsweise kann ein Nutzer ein Abonnement abschließen und Zugang erhalten haben. Später wird die Transaktion rückgängig gemacht oder der Shop widerruft den Vorgang.

Wenn der Server nur die ursprüngliche Meldung des Kunden kennt, wird er die Kauf-Informationen weiterhin als gültig ansehen.

In einer anderen Konstellation kann der Nutzer die automatische Verlängerung deaktivieren. Das bereits bezahlte Zeitfenster bleibt dennoch bis zum Ende aktiv.

Wenn das System nur den primitiven Zustand «Abonnement vorhanden / Abonnement nicht vorhanden» nutzt, läuft es Gefahr, den Zugang zu früh zu sperren oder ihn nach Ablauf fälschlicherweise offen zu lassen.

BillingMeld basiert auf einer anderen Logik: Der Kunde bestätigt seine Rechte nicht selbst. Es meldet nur Ereignisse, während der Server den tatsächlichen Status des Kaufs bestimmt.

Kauf ist kein Einzelereignis

Eine der häufigsten Fehler in der Billing-Architektur ist die Betrachtung des Kaufs als einmaliges Ereignis.

In Wirklichkeit hat ein Kauf einen Lebenszyklus.

Zunächst entsteht eine Operation. Dann wird sie vom Shop bestätigt. Für das Abonnement beginnt die bezahlte Periode. Später kann es zu einer weiteren Verlängerung kommen.

Der Nutzer kann die automatische Verlängerung deaktivieren, aber das Abonnement weiterhin bis zum Ende der bereits bezahlten Periode nutzen.

Beim nächsten Verlängerungsversuch kann die Zahlung scheitern.

Es ist auch möglich, eine Rückerstattung zu erhalten.

In Einzelfällen kann die Transaktion widerrufen werden.

Ein Erfolg allein sagt nicht mehr aus, dass der Kauf noch aktiv ist.

Der Server muss wissen, was aktuell passiert.

Widerruf eines Kaufs bleibt nicht unbemerkt

Besonders bei Rückerstattungen und Widerrufen zeigt sich die Notwendigkeit einer serverbasierten Architektur.

Der ursprüngliche Kauf war vielleicht völlig korrekt, der Nutzer hat bezahlt und Zugang erhalten.

Doch später ändert sich der Status der Operation.

Wenn BillingMeld die Änderungen erhält, aktualisiert es den eigenen Kaufstatus und prüft bei Bedarf die Daten erneut im Shop.

Das angeschlossene Service arbeitet danach mit dem neuen Status weiter.

Damit vertraut die App nicht mehr ewig auf die Aussage, dass der Kunde vor Wochen oder Monaten einmal erfolgreich gekauft hat.

Wenn der Shop die Rechte nicht mehr für gültig hält, spiegelt BillingMeld dies im Status wider.

Abonnement kündigen und Zugriff beenden sind nicht dasselbe

Hier besteht ein wichtiger Unterschied.

Wenn der Nutzer die automatische Verlängerung deaktiviert, bedeutet das nicht automatisch, dass der Zugriff sofort entzogen wird.

Der aktuelle bezahlte Zeitraum kann weiterhin gelten.

BillingMeld sollte die Info speichern, dass die automatische Verlängerung deaktiviert wurde, gleichzeitig aber noch das Ende des bezahlten Zeitraums kennen.

Nur nach Ablauf dieses Zeitraums endet der Zugriff, sofern kein neues bestätigtes Verlängerungsereignis vorliegt.

Dies ist ein Beispiel dafür, warum ein einfaches boolesches `subscription = true` für eine saubere Abrechnung nicht ausreicht.

Der Status des Abonnements ist immer an Zeit und Lebenszyklus-Ereignisse geknüpft.

Verlängerung ist ebenfalls eine eigene Prüfung

Ein Abonnement endet nicht durch die erste Zahlung.

Der Server muss erkennen, ob eine weitere Verlängerung stattgefunden hat und ob die nächste bezahlte Periode tatsächlich vom Shop bestätigt wurde.

BillingMeld verfolgt solche Änderungen und aktualisiert den Status des Abos entsprechend.

Ist die Verlängerung bestätigt, bleibt der Zugriffsrecht bestehen.

Wenn die nächste Abrechnung ausbleibt oder der Shop die nächste Periode nicht mehr bestätigt, sollte die Systemlogik den Zugriff nicht allein anhand der Annahme verlängern.

Für den Nutzer wirkt das natürlich, als würde der Zugang so lange bestehen, wie die bezahlte Abonnementdauer reicht.

Für Entwickler bedeutet das, dass die Logik der Verlängerung nicht in jedem App individuell neu geschrieben werden muss.

Beispielszenario

Der Nutzer abonniert in einer mobilen App.

Der Client erhält die Kaufinformationen und übermittelt die notwendigen Daten an BillingMeld. Dieses Ereignis allein gilt noch nicht als endgültige Bestätigung des Kaufs.

BillingMeld prüft die Transaktion im entsprechenden Shop.

Wenn App Store oder Google Play den Kauf bestätigt und der Status den Produktregeln entspricht, speichert BillingMeld den aktiven Anspruch.

Das verbundene Service bietet dem Nutzer anschließend die bezahlten Funktionen an.

Der Status lebt weiter unabhängig von der ursprünglichen Kundenmeldung.

Fährt das Abonnement fort, berücksichtigt BillingMeld die neue bezahlte Periode.

Bei Deaktivierung der automatischen Verlängerung bleibt der aktuelle Zeitraum bis zum Ende gültig.

Bei Rückerstattung oder Widerruf ändert sich der Status erneut.

Das App arbeitet in diesem Modell nicht mit einer eigenen, unabhängigen „Wahrheit“ über den Kauf, sondern mit dem von BillingMeld bestätigten Zustand.

Was bei Gerätewechsel passiert

Das Server-Modell ist besonders nützlich, wenn Nutzer das Gerät wechseln oder die App neu installieren.

Das Recht auf einen Kauf sollte nicht nur dann bestehen, wenn das konkrete Gerät bei einer erfolgreichen Transaktion „gesehen“ wurde.

Und eine Neuinstallation darf das bestätigte Recht des Nutzers nicht vernichten.

Wenn der Kaufstatus auf Serverseite verbunden mit einer bestätigten Shop-Operation ist, kann das neue Gerät den aktuellen Status vom Server erhalten.

Dies ist eine weitere Begründung, warum die Zugriffskontrolle nicht ausschließlich im mobilen Client stattfinden sollte.

Was das für Entwickler bedeutet

Für Teams, die mehrere mobile Apps veröffentlichen oder gleichzeitig mit iOS und Android arbeiten, wird das Billing sehr schnell zu einer eigenen Infrastruktur-Aufgabe.

Sie müssen berücksichtigen:

• Unterschiedliche Datenformate von Apple und Google;

• Bestätigung des ursprünglichen Kaufs;

• Verlängerungen von Abonnements;

• Ende der bezahlten Periode;

• Deaktivierung der automatischen Verlängerung;

• Rückerstattungen;

• Widerruf von Transaktionen;

• Neuinstallationen;

• Gerätewechsel;

• Wiederherstellung von Käufen;

• Änderungen des Status ohne Nutzerbeteiligung.

BillingMeld kapselt diese Logik in eine separate, spezialisierte Ebene.

Produkt-Server arbeiten mit diesem System über einen einheitlichen Vertrag und müssen nicht alle Eigenheiten der einzelnen Shops eigenständig interpretieren.

Das reduziert doppelte Codemengen und verringert die Gefahr, dass verschiedene Apps eines Unternehmens einen Zahlungsablauf unterschiedlich verstehen.

Der Beleg ist nicht mehr alles, sondern der aktuelle Anspruch

Mich hat an dieser Architektur am meisten der Übergang von der Überprüfung eines einzelnen Kaufs zum Kontrolle des aktuellen Statuses interessiert.

Der Beleg an sich sagt noch nicht aus, ob der Nutzer die bezahlte Funktion heute noch nutzen darf:

Ob ein erfolgreicher Kauf stattgefunden hat, ob das Abonnement aktiv ist, ob die automatische Verlängerung deaktiviert wurde, ob die bezahlte Periode abgelaufen ist, ob ein Verlängerungsversuch bestätigt wurde, ob eine Rückerstattung vorliegt oder die Transaktion widerrufen wurde.

Der Fokus verschiebt sich von der Beleg- und Kundenantwort auf den echten Nutzerstatus, der anhand des bestätigten Kaufstatus ermittelt wird.

Genau dieses Status-Update übermittelt BillingMeld an die Services.

BillingMeld als Grenze zwischen Shops und Produkten

Aus dieser Sicht entsteht eine klare architektonische Trennung.

Auf der einen Seite stehen App Store und Google Play mit ihren Formaten, Events, Regeln und Lebenszyklen.

Auf der anderen Seite - Apps und interne Dienste, die meist nur eine einfache Frage beantworten müssen: Welche Rechte sind aktuell beim Nutzer?

Dazwischen liegt BillingMeld.

Es empfängt die Shop-Daten, überprüft sie, bringt sie in ein eigenes Modell und liefert das bereits normalisierte Ergebnis an die restliche Infrastruktur.

Dadurch müssen Produkte nicht alle internen Eigenheiten jeder Zahlungsplattform kennen.

Warum das für den Nutzer wichtig ist

Idealerweise sollte die richtige Billing-Architektur für den Nutzer überhaupt nicht sichtbar sein.

Wenn der Kauf bestätigt ist und die bezahlte Periode läuft, sollte der Zugriff funktionieren.

Wenn der Nutzer die automatische Verlängerung deaktiviert hat, sollte die bereits bezahlte Zeit nicht vorzeitig enden.

Bei einer erfolgreichen erneuten Verlängerung sollte der Zugriff bestehen bleiben.

Wenn das Magazin Rückgabe oder Widerruf bestätigt, sollte das System den Anspruch korrekt anpassen.

Bei Gerätewechsel oder Neuinstallation sollte der Nutzer nicht manuell nachweisen müssen, dass der Kauf besteht.

Die vereinfachte Regel lautet:

Der Kunde meldet den Kauf, das Magazin ist die externe Quelle für den Status, BillingMeld überprüft und normalisiert diese Daten, und die restlichen Dienste treffen Entscheidungen basierend auf den bestätigten Informationen von BillingMeld.

Deshalb ist BillingMeld mehr als nur ein Zahlungsmodul.

Es ist eine serverseitige Vertrauensschicht zwischen mobilen Apps, den Apple- und Google-Shops sowie den Produkten, die exakt wissen müssen, welche kostenpflichtigen Rechte einem Nutzer in diesem Moment zustehen.

Mehr Infos zum Projekt: billingmeld.de.