Abos in der App verkaufen
In der App, die aus einem Store installiert wurde, kassiert der Store, nicht Ihr Zahlungsanbieter. Dieser Leitfaden erklärt, wie Sie jeden Tarif Ihrer App mit einem Produkt im App Store oder bei Google Play verbinden, und warum der Abo-Knopf manchmal nicht erscheint.
Warum es in der App anders ist
Auf der veröffentlichten Website läuft das Abo über den Anbieter, den Sie verbunden haben (Stripe, Mercado Pago, Pagar.me). In der aus einem Store installierten App ist das für digitale Inhalte ein Verstoß gegen die Regeln beider Stores, und die Strafe ist die Entfernung der App.
Deshalb weicht die Plattform in der App nie auf den Zahlungsanbieter aus. Entweder es gibt den Kauf über den Store, eingerichtet und bereit, oder die App zeigt den stummen Zustand. Ein Knopf, der den Store öffnet und scheitert, ist schlimmer als gar kein Knopf.
Der Store behält eine Provision auf jeden Verkauf, und beide Programme haben je nach Umsatz und Abodauer unterschiedliche Stufen. Sehen Sie vor der Preisfestlegung in die offiziellen Seiten von Apple und Google Play.
Was bereit sein muss
- die native App veröffentlicht oder zumindest im Tab App eingerichtet;
- der Kauf in der App im Schritt Funktionen aktiviert;
- die Tarife Ihrer App bereits angelegt (was der Tab Daten Tarife nennt und was die App verkauft);
- die Prüf-Zugangsdaten: auf iOS der In-App-Purchase-Schlüssel, auf Android das Play-Dienstkonto;
- jeder Tarif mit einem Store-Produkt verknüpft, worum es im Rest dieses Leitfadens geht.
Jeden Tarif mit einem Store-Produkt verknüpfen
Im Tab App zeigt der Abo-Bereich die Tarife Ihrer App neben dem, was der Store wirklich hat, immer ein Store zur Zeit (Google Play und der App Store sind getrennte Kataloge: in einem verknüpft zu sein sagt nichts über den anderen). Jeder Tarif trägt einen Zustand:
| Zustand | Was er bedeutet |
|---|---|
| kein Produkt | der Tarif ist mit nichts im Store verknüpft |
| im Store nicht gefunden | hier ist eine Kennung gespeichert, aber der Store kennt sie nicht |
| angelegt, aber nicht verkäuflich | das Produkt existiert und ist noch nicht kaufbar (Entwurf, ohne Preis, ohne Prüfung) |
| verkäuflich | bereit: die App darf diesen Tarif verkaufen |
Nur verkäuflich erlaubt den Kauf. Diese Unterscheidung zählt: bei Google antwortet die API erfolgreich, während der Basistarif noch ein Entwurf ist, und der Kauf scheitert dann auf dem Gerät mit "Artikel nicht verfügbar".
Bei Google Play
Zwei Aktionen, je nachdem, wo Sie angefangen haben:
- Im Store anlegen: die Plattform legt das Produkt an und aktiviert den Basistarif für Sie. Prüfen Sie vor dem Bestätigen die Kennung unter "Wird angelegt als";
- Mit vorhandenem Produkt verknüpfen: wenn Sie den Katalog in der Play Console schon aufgebaut haben, geben Sie Produkt- und Basistarif-Kennung an. Die Plattform prüft und zeigt die Unterschiede zwischen Ihrem Tarif und dem Store (Preis, Zeitraum), ohne für Sie zu entscheiden.
Im App Store
Hier legt die Plattform das Abo nicht an, und das ist keine Grenze von uns: Apple verlangt, dass das erste Abo zusammen mit einer App-Version eingereicht wird, in einer Abo-Gruppe, mit Preisen je Region und mit Prüfung.
Der Weg führt über das Anlegen in App Store Connect und das Verknüpfen hier:
- in App Store Connect die App öffnen und zu Monetization → Subscriptions gehen;
- eine Abo-Gruppe anlegen (die Gruppe erlaubt dem Kunden den Wechsel zwischen Tarifen darin);
- das Abo anlegen, mit Kennung, Laufzeit und Preis;
- alles ausfüllen, bis der Status Ready to Submit lautet;
- auf der Seite der App-Version, im Abschnitt der In-App-Käufe, das Abo auswählen und beide zusammen zur Prüfung einreichen;
- nach der Freigabe zurück in den Tab App und den Tarif mit der Kennung verknüpfen.
Das gilt für das erste Abo. Sobald eines in der Gruppe freigegeben ist, können weitere allein eingereicht werden.
Kennungen sind dauerhaft
In beiden Stores lässt sich die Kennung eines Produkts nach dem Anlegen weder umbenennen noch wiederverwenden. Bei Google Play lassen sich Abo, Basistarif und Angebot nicht einmal löschen: sie bleiben für die Berichte für immer.
Deshalb warnt der Bildschirm vor dem Anlegen, und deshalb weigert er sich, eine Variante zu erfinden, wenn die Kennung schon vergeben ist: dann ist Verknüpfen richtig, nicht ein zweites Anlegen.
Der In-App-Purchase-Schlüssel (iOS)
Die Prüfung eines Kaufs auf iOS nutzt einen anderen Schlüssel als den, der Builds sendet. Er wird unter Users and Access → Integrations → In-App Purchase erzeugt und im Abo-Bereich selbst verbunden.
Ohne ihn würde der Store auf dem Gerät kassieren und die Prüfung danach ablehnen: Geld bewegt, nichts freigegeben, und der Kunde mit einem Beleg in der Hand. Deshalb bleibt die App ohne diesen Schlüssel stumm, statt zu verkaufen.
Der Abo-Knopf erscheint nicht: warum
Der Server entscheidet das an genau einer Stelle, und immer, um einzuschränken, nie um zu erweitern. Jeder Grund ist eine fehlende Einstellung, und alle lassen sich beheben:
| Was fehlt | Was zu tun ist |
|---|---|
| der Kunde hat bereits ein aktives Abo | nichts: anderswo erneut zu kassieren wäre eine zweite Abbuchung |
| die App hat keine native Version | den Tab App einrichten |
| der Kauf in der App ist nicht aktiviert | die Funktion im Schritt Funktionen aktivieren |
| die Plattform dieses Geräts ist nicht aktiviert | iOS oder Android im Schritt Stores aktivieren |
| die Prüf-Zugangsdaten fehlen | den In-App-Purchase-Schlüssel (iOS) oder das Dienstkonto (Android) verbinden |
| der Tarif existiert nicht | die Tarife Ihrer App im Tab Daten prüfen |
| der Katalog ist nicht bereit | den Tarif mit einem verkäuflichen Produkt im Store verknüpfen |
Kündigung und Erstattung
Ein Store-Abo kündigt der Kunde im Store, nicht in Ihrer App: so ist es bei beiden und daran lässt sich nichts ändern. Verlängerungen, Kündigungen und Erstattungen erreichen uns über die Benachrichtigungen des Stores, und der Zugang des Kunden wird daraus angepasst.
Eine praktische Folge auf Android: ein Kauf, den die App nicht bestätigt, wird von Google nach drei Tagen automatisch erstattet. Die Plattform bestätigt ihn, sobald die Prüfung besteht, der normale Weg deckt das also ab; meldet ein Kunde eine Erstattung ohne Grund, sieht man dort zuerst nach.
Das Gerät entscheidet nie
Gut zu wissen, weil es mehrere Antworten des Systems erklärt: die Transaktionskennung, die die App zurückgibt, ist eine Behauptung, kein Beweis. Alles, was Geld bewegt (welches Produkt, von wem, bis wann, noch aktiv), wird beim Store mit den Zugangsdaten des App-Inhabers erfragt.
Das verhindert, dass ein gefälschter Beleg bezahlten Zugang freischaltet, und es ist auch der Grund, warum ein Kauf zwischen der Annahme im Store und der Freigabe in der App einige Sekunden braucht.