In App Purchase (Apple) und In App Billing (Google)

Apple und Google: In-App-Käufe für Guthaben bei Mehrwertdiensten nutzen
Keine Kommentare

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 ein Mal die „alten“ Dienste von Google und Apple beleuchten und veranschaulichen, wie man virtuelles Geld aus In-App-Käufen bei Google und Apple verifizieren kann, um damit echtes Guthaben auf Mehrwertdiensten verwalten zu können.

Es geht um die Systeme In App Purchase (Apple) und In App Billing (Google). Diese Mechanismen wurden geschaffen, um die sogenannten 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, Gold oder ä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 Vorgehensweise ist derzeit üblich, um Apps wie Spiele scheinbar kostenlos anbieten zu können und die Kosten für Entwicklung und Betrieb der Software quasi durchs Hintertürchen mittels kostenpflichtiger Add-Ons wieder hereinzuholen.

Für das Beispiel 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, das 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 solcher Möglichkeiten, neue Extras für das Spiel im Spiel zu kaufen, so erhöht sich der Profit und allmählich rechnet sich eventuell sogar 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 (siehe Abbildung unten), die dem Benutzer zunächst mitteilen, um welchen Kauf es sich handelt und was dieser kosten soll.

apple-google-in-app-kauf

Ein Vergleich der Dialoge beim In-App-Kauf bei Apple und Google.

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 bezahlen. Durch Bestätigung 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.

DYF

In-App-Kauf: der grobe Ablauf

apple-google-in-app-kauf-prozess

Der In-App-Kauf im Überblick (zum Vergrößern klicken).

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 sogenannten 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 Abonnements gedacht ist, beispielsweise kauft man sich den Service von Spotify für einen Monat. Für dieses Abonnement 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, das wir verkaufen wollen, identifiziert, 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 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, den er seinen Kunden anbieten will, ist Dialout. Also der Anruf in das öffentliche Telefonnetz. Alle Gesprächsteilnehmer, die 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 zum Thema dieses Artikels, er nutzt die IAP- oder IAB-Schnittstelle des Smartphoneherstellers direkt nativ.

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 ein einfaches SSL-verschlüsseltes RESTful API mit C2M (Customer to Machine) Autorisierung und Authentifizierung und senden den Topup-Befehl einfach selbst. Denkste!! Diese Art von Aufladefunktion schreit nur nach Men-in-the-Middle-Attacken. Auch wenn es zunächst undenkbar scheint, das 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 (der selbe Entwickler wie bei der 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.

apple-google-in-app-kauf-verifizierung

Der Verifizierungsprozess im Überblick (zum Vergrößern klicken).

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. Dazu hier noch eine GUI für einen Live-Test. 
Für die Apple-Nachrichten gibt es wiederum ein API für die Prüfung des Kaufvorganges, und zwar unter https://sandbox.itunes.apple.com/verifyReceipt.

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 anzubieten. Die Implementierung ist dabei nicht üppiger als bei Payment-Service-Provider-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 Prozent des Kaufbetrages für die Bereitstellung des Dienstes. Daher ist bei einem Produkt mit einer Marge darunter dieser Service mit Vorsicht zu genießen.

Aufmacherbild: Conceptual view about checkouts or payments over Internet via Shutterstock / Urheberrecht: Sinisa Botas

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -