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;
- unter Android die im Play Console aktivierten Verlängerungs-Benachrichtigungen, ohne die das Abo abbucht, ohne den Zugang zu verlängern.
Jeden Tarif mit einem Store-Produkt verknüpfen
Der Bereich erscheint, sobald zwei Dinge zutreffen: Der Kauf in der App ist im Schritt Funktionen aktiviert, und das Konto dieses Stores ist im Schritt Konten bereits verbunden. Er erscheint auch, bevor es überhaupt einen Tarif gibt, und sagt dann, dass noch keiner da ist: Die Tarife anzulegen ist der nächste Schritt, keine Voraussetzung dafür, den Bildschirm zu sehen.
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
Auf Android gibt es eine weitere Voraussetzung, und sie kommt von Google, nicht von hier: Play gibt das Anlegen
von Abos erst frei, nachdem eine Version der App hochgeladen wurde (ein interner Test genügt). Vorher antwortet
die Play Console, dass die App noch keine Abos hat, und verlangt einen Upload; die Schaltfläche „Im Store anlegen“
auf diesem Bildschirm läuft in dieselbe Regel. Hochzuladen ist die .aab aus dem Produktions-Build; die .apk aus
dem Test-Build dient dazu, sie auf einem Gerät zu installieren, nicht zum Veröffentlichen im Store.
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 |
Verlängerungs-Benachrichtigungen aktivieren (Android)
Das ist der Schritt, der entscheidet, ob sich Ihr Abo wirklich verlängert, und er wird leicht übersprungen, weil der erste Kauf auch ohne ihn funktioniert.
Über den Store gekaufter Zugang wird mit einer Frist gespeichert, nach dem Datum, das der Store selbst meldet. Was diese Frist jeden Monat weiterschiebt, ist eine Benachrichtigung, die Google Play bei jeder Verlängerung sendet. Ohne sie entsteht die schlechteste denkbare Konstellation: Google bucht bei Ihrem Kunden weiter jeden Monat ab, und sein Zugang endet nach dem ersten. Auch eine Erstattung entzieht den Zugang dann nicht mehr, wer also sein Geld zurückholt, nutzt die App weiter.
In der Play Console:
- Monetarisieren (Seitenmenü) → Monetarisierungs-Setup;
- nach unten zu Entwicklerbenachrichtigungen in Echtzeit;
- Echtzeit-Benachrichtigungen aktivieren ankreuzen;
- bei Themenname das Thema einfügen, das der Tab Anwendung anzeigt, mit einer Schaltfläche zum Kopieren daneben
(es beginnt mit
projects/); - speichern und Testbenachrichtigung senden klicken.
Unter Benachrichtigungsinhalt genügt die Option Nur Abos und stornierte Käufe, und sie ist die empfohlene.
Das Thema ist für alle Apps der Plattform dasselbe, und das ist Absicht: dort veröffentlicht ein Konto von Google selbst, per Berechtigung autorisiert, und nicht, wer den Namen kennt. Die Benachrichtigung erkennt Ihre App am Paketnamen.
Sie müssen niemandem mitteilen, dass Sie diesen Schritt gemacht haben. Die Testbenachrichtigung erreicht uns, der Tab Anwendung setzt also von selbst ein Häkchen mit dem Datum, sobald sie eintrifft. Solange dieses Häkchen fehlt, ist der Schritt nicht erledigt, ganz gleich was die Play Console beim Speichern angezeigt hat.
Schlägt der Testversand fehl, nennt Googles Fehler drei Ursachen (Namensformat, Cloud-Konfiguration, Berechtigung), und in der Praxis ist es fast immer die dritte: die Finanzberechtigungen des Dienstkontos, im Leitfaden Ihre Konten verbinden.
Unter iOS ist das Gegenstück automatisch: die Plattform empfängt Apples Benachrichtigungen bereits, ohne dass Sie etwas konfigurieren.
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.