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

Willkommen in der Mobile-Pay-World. Was ich damit sagen will?! Das Smartphone wird immer mehr zum Zahlungsmittel. Derzeit fliegen neue Produkte und Ideen aus allen Nischen der Softwaredienstleister. Auch Apple bietet jetzt mit Apple Pay die Möglichkeit, bargeldlos an Terminals zu bezahlen. Ich möchte hier einmal die “alten” Dienste von Google und Apple beleuchten und veranschaulichen, wie auch damit digitales Geld in Gutscheine oder Guthaben zur Nutzung von Mehrwertdiensten gewandelt und verifiziert werden kann.

Es geht um die Systeme In App Purchase (Apple) und In App Billing (Google). Diese Mechanismen wurden geschaffen, um “In App Käufe” zu ermöglichen. Gamer werden es am besten kennen. Für wenige Cents kann man sich Add-Ons wie Schwerter, Helme oder Gold und Ähnliches in den App Spielewelten aneignen. Apple oder Google bucht dabei den gewünschten Betrag von einem vorher verifizierten Zahlungsmittel des Mobilenutzers ab und transferiert diesen Betrag an den Betreiber (Entwickler) der App. Dabei erhalten Apple und Google üppige Provisionen. Diese Art ist derzeit üblich, um Apps wie Spiele scheinbar kostenlos anbieten zu können und die Kosten für Entwicklung und Betrieb der Software hinten herum durch kostenpflichtige Add-Ons wieder herein zu holen. Für bspw. Spiele funktioniert dieses Prinzip auch sehr gut. Nehmen wir an, wir entwickeln ein Autorennspiel. Dieses ist kostenlos in den Stores erhältlich. Der Spieler kann sich mit virtuellem Geld ein Auto kaufen, dieses neu lackieren und etwas aufmotzen. Anschließend fährt er damit Rennen gegen reale Gegner aus der Community. Er gewinnt und verliert. Verliert er zu häufig, braucht er dabei sein virtuelles Geld auf. Nun benötigt der Spieler aber einen leistungsstärkeren Motor. Dieser bedarf einer Summe X seines virtuellen Geldes, welches er aber bereits in den letzten Rennen verloren hat. Nun entschließt sich der Spieler den Motor für echtes Geld zu beschaffen. Die Kosten sind überschaubar, wenige Cents und er kann direkt weiter spielen. Jetzt haben wir als Herausgeber der APP zum ersten mal Profit gemacht. Verstecken wir viele dieser Möglichkeiten, neue Extras für das Spiel im Spiel zu kaufen, so erhöht sich dieser Profit und allmählich rechnet sich die Entwicklungszeit sowie der Betrieb unserer Server um das Spiel anbieten zu können.

Wie funktioniert der Kauf “In APP”?

Über einen Button wird das SDK von Apple (StoreKitSuite) oder Google (Google Wallet) geladen. Diese zeigen ziemlich ähnliche Dialoge an, welche dem Benutzer zunächst mitteilen, um welchen Kauf es sich handelt und was dieser kosten soll.

Beispiel

Im nächsten Schritt kann der Benutzer noch das Zahlungsmittel auswählen. Meist ist dies die bei Apple oder Google verifizierte Kreditkarte. Neuerdings kann man dort aber auch direkt über den Mobilfunkprovider oder weitere Zahlungsanbieter wie Paypal und ähnlichen bezahlen. Mit Bestätigen des Zahlungsmittels ist der Kauf bereits getätigt. Die App bekommt ein Verfiy-Signal, welches an unser Spiel zurückgegeben wird. Darauf können wir nun reagieren und das gewünschte Feature freischalten.

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.

Haben wir nun das entsprechende Produkt, welches wir verkaufen wollen, identifiziert, so können wir mit diesen Daten die Kaufmaske anzeigen. Bestätigt der Nutzer jetzt diesen Kauf, senden wir die Anfrage an den Verifizierungsserver des Anbieters. Anhand des Verifizierungs-Keys wird auf dem Server das Produkt und der Nutzer überprüft. Sind die Daten okay, antwortet der Server mit einem “Okay” in dem jeweiligen SDK Dialekt. Dies geschieht Synchron. Ist der Server also offline oder die Datenverbindung des Nutzers schwach, so kann es zu Problemen kommen. Dieses Offline-Problem wollen wir hier aber nicht näher betrachten. Zusätzlich senden beide Anbieter eine Signatur verschlüsselt durch den Key mit zurück an die App. Diese Signatur oder Nachricht kann dort dekodiert werden. Enthalten sind bspw. die Transaktions-ID und weitere Kaufrelevante-Informationen.

Hier endet das einfache Beispiel eines In App-Kaufes. Die App schaltet das Feature frei und der Nutzer zahlt mit seiner nächsten Kreditkartenabrechnung den Erhalt eines neuen Motors. Für diese Art von Kauf ist das Verfahren bestens geeignet. Jetzt kommen wir aber zum eigentlichen Thema, den Kauf von Guthaben für einen kostenpflichtigen Dienst.

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.

Der Server entschlüsselt die Nachricht mit dem Key und gleicht die enthaltenen Werte mit denen ab, welche die App zusätzlich mitgeliefert hat. Außerdem steht noch der Status der Transaktion in der Nachricht, so dass dort noch einmal klar sichergestellt werden kann, dass die Zahlung erfolgreich durchgeführt und nicht abgebrochen wurde. Erst jetzt ist klar, dass die Zahlung tatsächlich stattgefunden hat. Das Serverprogramm lädt dem Konto den verbuchten Betrag auf und bestätigt die Anfrage der App mit einem “Okay”. Die serverseitige Verifizierung ist damit abgeschlossen. So ist es ebenfalls möglich, In App-Käufe auch für Geldtransfer zu benutzen. Für Apple IAP https://gist.github.com/jamesstout/5073237 und Google IAB https://github.com/mitchobrian/google-play-in-app-billing-verification gibt es ein paar Beispiele für die serverseitige Verifizierung der Nachricht. Bei Google kann dies unmittelbar auf dem eigenen System durchgeführt werden. Für die Apple Nachrichten gibt es wiederum eine API zu finden unter https://sandbox.itunes.apple.com/verifyReceipt für die Prüfung des Kaufvorganges.

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.

Dieser Artikel ist outdated — geschrieben im Jahr 2015