In-App Verkäufe als Guthaben für Mehrwertdienste

Beispiel

Der grobe Ablauf

Für beide Anbieter, Google und Apple, ist es möglich sich die Liste der verfügbaren Produkte zu einer App vom Server zu laden. Angelegt werden sie über die App Einstellungen. Für jedes Produkt wird eine eindeutige ID vergeben. Dabei ist es wie immer empfehlenswert die Reversedomain des Anbieters und einen Suffix zu wählen; bspw. de.entwickler.race.engine. Bei Google ist es nun möglich, einen genauen Kaufbetrag für das Produkt zu definieren. Apple grenzt den Spielraum hier etwas ein und lässt nur die Auswahl von Tiers zu, welche den Wert des Produktes in Staffeln definiert. Bei der Abfrage aller Produkte zu einer App erhalten wir nun also eine Liste der ID’s, welche potentiell gekauft werden können. Dabei unterscheiden beide Anbieter noch einmal in Produkte und Mieten, also Managed In-App Products und Subscriptions. Das rührt daher, dass diese Art Kauf für bspw. Abonnements gedacht ist. Beispielsweise kaufe ich mir den Service von Spotify für einen Monat. Für dieses Abo kann die App nun bei jedem Start prüfen, ob das Abo noch gültig ist. Wenn nicht, kann sie entweder den Nutzer dazu auffordern, das Abo zu verlängern oder dies sogar automatisch erledigen, sofern der Nutzer dem vorher zugestimmt hat.

Aufladen

Nehmen wir einmal das Beispiel einer Telefonie-App. In dieser können die Nutzer untereinander kostenlos telefonieren und chatten. Dies funktioniert direkt über die Datenverbindung, was den Anbieter dennoch die Bereitstellung der nötigen SIP-Infrastruktur kostet. Diese Nebenkosten geht er aber gerne ein, denn der eigentliche Dienst, welchen er seinen Kunden anbieten will, ist Dialout. Also der Anruf in das öffentliche Telefonnetz. Alle Gesprächsteilnehmer, welche nicht diese App benutzen, können nur über die echte Telefonnummer erreicht werden. Dieser Service kostet Terminierungsgebühren. Für ein ganz normales Telefongespräch zur Oma muss der Nutzer der App also bezahlen. Dafür benötigt er Guthaben auf seinem Konto. Dieses kann er über direkte Zahlungsanbieter in der App aufladen, dort wird es voraussichtlich wieder Paypal, Sofortüberweisung oder eine Wirecard-Schnittstelle geben. Oder, und dies führt uns zurück zu diesem Artikel, er nutzt die IAP- oder IAB-Schnittstelle direkt nativ des Smartphoneherstellers. Dabei haben wir als Herausgeber und Entwickler aber nun ein gravierendes Problem. Die Verifizierung einer Zahlung, bislang hier immer der Kauf eines Produktes genannt, wird NUR serverseitig bei Apple oder Google vorgenommen. Der Anbieter, also wir, erhalten niemals Auskunft über einen getätigten Kauf aus unserer App heraus. Wie können wir also nun in unserer Telefonie-Cloud einem Konto Guthaben aufbuchen ohne den Trigger zu erhalten, dass der Inhaber des Kontos gekauft hat? Zur Lösung dieses Problems wenden wir einen kleinen Umweg an. Die App meldet sich bei unserem Server und informiert uns über die Aufladung des Kontos. Dabei verwenden wir eine einfache SSL verschlüsselte RESTful API mit c2m (customer to machine) Autorisierung und Authentifizierung und senden den Topup-Befehl einfach selber. Denkste!! Diese Art von Aufladefunktion schreit nur nach Men-in-the-middle Attacken. Auch wenn es zunächst undenkbar scheint die API und auch noch den verschlüsselten HTTP-Request zu knacken, so ist auf dem Server dennoch nicht klar, ob die Zahlung wirklich verifiziert ist.

Verifizierung

Die Lösung dieses Problems ist die Antwortnachricht des Anbieters. Hier erhalten wir einen verschlüsselten String mit allen Informationen aus dem Kauf. Diese Nachricht senden wir aus der App einfach weiter an den Server. Der Server (selber Entwickler wie die App in diesem Fall wir) hat ebenfalls den Key zur Hand und ist damit in der Lage die Nachricht zu entschlüsseln und die Werte auszulesen. Die App sendet also die relevanten Nutzerdaten, die ID des gekauften Vouchers (Produkt 5 Euro bspw.: {“amout”: 5.00, “id”: “de.entwickler.voucher.five”}) und die Nachricht an unseren Server.

Fazit

Für die maximale User Experience kann es wünschenswert sein, zusätzlich zu den üblichen Zahlungsdienstleistern ebenfalls die hauseigenen Boardmittel von Apple und Google mit anzubieten. Die Implementierung ist dabei nicht üppiger als bei PSP1-APIs. Der Entwickler muss natürlich sein Developer-Konto um die Kaufoptionen für App-Kunden erweitern und die hohen Provisionen für Google und Apple in Kauf nehmen. Diese können unter Umständen den Business-Case zerstören. Üblicherweise nehmen beide im Durchschnitt 30% des Kaufbetrages für die Bereitstellung des Dienstes. Daher ist bei einem Produkt mit einer Marge darunter dieser Service mit Vorsicht zu genießen.

--

--

Meine Freunde rufen mich Mitch - ich bin passionierter Softwareentwickler und Vater. https://palmomedia.de

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Palmer

Michael Palmer

Meine Freunde rufen mich Mitch - ich bin passionierter Softwareentwickler und Vater. https://palmomedia.de