Abonnement als In-App Kauf (Auto-Renewable)

[RWarnecke]

Hallo zusammen,

hat jemand schon eine App mit einem Abonnement In-App Kauf und automatischer Verlängerung erfolgreich in den Apple AppStore gebracht ? Wenn ja, wo und wie muss Information zu der automatischen Verlängerung platziert werden ? Eine Beispiel-App aus dem AppStore wäre echt super. Ich kämpfe da nämlich gerade mit Apple drum, die wollen eine meiner Apps nicht durchlassen.

Kann mir da jemand weiterhelfen ?

[mensch72]

Wir realisieren unsere InAPP Service Verwaltung selbst als simple HTML Views, das funktioniert so für Android und IOS bei uns 100% identisch. Abo's und/oder "InAppOrders" wickeln wir selbst Server seitig per PayPal-Api ab. Weder Google noch Apple haben sich bisher beschwert, das wir in unserer nativ App einen simplen HTMLviewer für beliebigen serverseitig gesteuerten Inhalt anbieten.

Als TestAccount für Apple stellen wir ein Login, welches im AddOn eine nahezu identische Funktionalität zu einer auch native in der App realisierten Funktion bietet und darstellt.
Denn genau das ist unser Argument, warum wir diesen Weg gehen... so können wir einzelnen Kunden oder Gruppen )vorab) neue Funktionen wenn es sein muss auch mit mehreren Updates pro Tag in der App bieten, ohne das wir die App selbst im AppStore ständig "für alle" aktualisieren müssen, bis wir diese dann endgültig native in der App realisieren.

Apple ist ja nicht dumm, die wissen sehr wohl, das wir Login abhängig so wenn wir wollen quasi alles dynamisch pro Kunde personalisieren können, also auch per Abo gezielt Funktionalität aktivieren&deaktivieren können... das hat den Review unserer Apps aber bisher nicht negativ beeinflußt.

[RWarnecke]

Den Aufwand wollte ich mir ersparen, da ja Apple für mich die ganze Abrechnung macht, wenn ich von denen die Abo-Funktion nutze. Deshalb ist das für mich keine Alternative.

[Rollo62]

Interessant das es geht und Apple sich nicht querstellt

[mensch72]

für eine AuftragsApp eines Kunden, der auch keine Rechnungen selbst stellen will, realisieren wir gerade die Lösung von "DigitalRiver/shareit" (https://www.mycommerce.com/de/solutions/pricing.html) serverseitig per WebInterface, womit in der App dann per HTMLviewer der AppKunde seine Bestellung direkt auslösen und die Zahlung samt Rechnung dort extern abwickeln kann.

Die "Ware" ist dann ein live erzeugter und ausgelieferter QRcode (der sogar auf der Rechnung stehen könnte). Wenn der AppKunde diesen QRcode "wie auch immer" in der App einliest (Zwischenablage, Kamera, PNG/JPG-Import,..), dann schaltet sich in der App die gekaufte Funktion frei. Es gibt 1:1 Installation-Codes, die nur auf exakt auf einem Gerät gehen, bzw. Account und/oder Zeit Codes, die auf allen Geräten pro Kundenaccount mit oder ohne Ablaufzeit funktionieren.

Vorteil der QRcodes ist, das es damit auch offline per Papierausdruck funktioniert... es gibt durchaus Bereiche und Anwendungen wo es sicherheitstechnisch unmöglich ist, auf diesen Geräten Apps mit "Online Abrechnugszwang" einzusetzen. Und wenn Apple oder sonstwer nach dem "warum" fragt, dann ist genau diese Offlinefähigikeit gewollt ohne jeglichen Rückkanal "das" Argument.

Wenn man InApp-Käufe etwas weiter denkt, kommt man zu InApp-BonusSystemen... ich verschicke z.B. in Werbe/Einladungsmails für eine Messe InApp-Gutscheine als QRcodes, diese haben aber eine GeoLocation inkludiert und werden erst gültig&aktiviert, wenn derjenige auch am gewünschten Ort ist und die App dort benutzt... all sowas geht mit den AppStore/PlayStore direkt nicht. Da sowohl Apple als auch Google dieses wissen und die eh mehr mit ihren 30% vom Massengeschäft mit wenig Aufwand sehr gut leben, tollerieren die solche externen "Mehrwertlösungen", solange der AppKunde einen direkten Vorteil davon hat.

[Darlo]

Zitat von mensch72:

Wir realisieren unsere InAPP Service Verwaltung selbst als simple HTML Views, das funktioniert so für Android und IOS bei uns 100% identisch. Abo's und/oder "InAppOrders" wickeln wir selbst Server seitig per PayPal-Api ab. Weder Google noch Apple haben sich bisher beschwert, das wir in unserer nativ App einen simplen HTMLviewer für beliebigen serverseitig gesteuerten Inhalt anbieten.

Als TestAccount für Apple stellen wir ein Login, welches im AddOn eine nahezu identische Funktionalität zu einer auch native in der App realisierten Funktion bietet und darstellt.
Denn genau das ist unser Argument, warum wir diesen Weg gehen... so können wir einzelnen Kunden oder Gruppen )vorab) neue Funktionen wenn es sein muss auch mit mehreren Updates pro Tag in der App bieten, ohne das wir die App selbst im AppStore ständig "für alle" aktualisieren müssen, bis wir diese dann endgültig native in der App realisieren.

Apple ist ja nicht dumm, die wissen sehr wohl, das wir Login abhängig so wenn wir wollen quasi alles dynamisch pro Kunde personalisieren können, also auch per Abo gezielt Funktionalität aktivieren&deaktivieren können... das hat den Review unserer Apps aber bisher nicht negativ beeinflußt.

Oh, das ist gefährlich. Apple will dagegen verstärkt vorgehen. Bleibt nur zu hoffen, dass das zunehmende verweigern der App Stores von Apple, auch von renomuerten Anbietern, etwas bewirkt und die Politik hier liberaler wird.

[RWarnecke]

Ich finde eure Ideen ja von der Theorie her echt klasse, aber es beantwortet mir leider nicht meine Eingangsfrage. Ich möchte keine eigenen Rechnungen stellen und ich möchte es dem Anwender so einfach wie möglich machen ein Abonnement für die App abzuschließen. Das heißt, er soll keinen QR-Code einscannen müssen oder sonstige Sachen machen. Dazu ist bis jetzt nur der AppStore mit seinen Abos im Stande. Und ja mir ist es auch egal, dass Apple 30% bekommt. Ich brauche einfach nur die Hilfestellung, wo ich die Informationen für die automatische Verlängerung des Abonnements innerhalb der App platzieren muss ? Eine App aus dem AppStore würde mir schon reichen, wo dieses erfolgreich umgesetzt ist, dass ich mir das dort abschauen kann und somit meine App durch die Prüfung bekomme.

[mensch72]

..."Ich möchte keine eigenen Rechnungen stellen und ich möchte es dem Anwender so einfach wie möglich machen ein Abonnement für die App abzuschließen. Das heißt, er soll keinen QR-Code einscannen müssen oder sonstige Sachen machen."...

Die entscheidende Frage ist, hast du einen eigenen frei programmierbaren (Web)Server im Internet, der "immer" von deiner KundenApp bei Bedarf erreicht werden kann&darf?
(wie geschrieben: im aktuellen Projekt haben wir uns für WorstCase notfalls auf Papier druckbare QRcodes entschieden, weil es da zusätzlich sicherheitstechnisch eben auch 100% "offline" funktionieren muss)

Wenn ja, kannst du statt QRcodes zu erzeugen, auch per TCP/IP Request von deiner App an deinen Server den aktuellen/"neuen" LicState anfragen und abholen, bzw. dein Server kann deiner App (zusätzlich) eine PushNotification zum "WakeUp" und zugleich auch im Klartext lesbare "Kaufbestätigung" senden... das alles benötigt NULL Nutzerinteraktion(wenn du App und/oder Server seitig es dir selbst so programmierst!) , erfüllt aber so nebenbei alle aktuell in der EU gültigen Vorschriften zur (End)Verbraucherinformation bei InApp Käufen und das ganz besonders bei Abschluss von InApp-ABOs!

Apple weiß genau, das ihr aktuelles AppStore Payment für Abschluss von InApp-Abo's nicht 100% EU konform ist... daher tollerieren die durchaus bewußt App's, welche das über andere Dienstleister und "eigene" Lizenz/Optionsverwaltung selbst lösen.

Wegen aktueller Umfirmierung ist unsere alte "TestApp", die im Prinzip nix anderes wie ein LoginDialog mit einem dann zur Verfügung stehendem FullScreen-HTMLviewer war, aktuell aus dem AppStore heraus gefallen.
Wenn wir eine DUNS für unsere neue Rechtsform haben und Apple die App wieder so im Store aufnimmt, bekommste gerne eine TestLogin wo du echte Käufe/Abos für je 0,20€ durch spielen kannst. Ohne Erstattung!... die abgerechneten Transaktionen sind und bleiben echt, aber die Abo's wiederholen sich zum Test immer nur ein einziges mal... so testen wir auch selbst


Apple ist relativ offen für direkte Fragen!
Schreib denen ein paar Sätze zu deinem Wunsch/Problem und sag denen offen in "welcher Richtung" du eine Lösung suchst. Wir haben so das nennen wir es geduldete Konzept mit online&offline "server side controled content" via HTMLviewer quasi absegnen lassen.
Solltest du es "nur" per AppStore lösen wollen, dann geben die dir sicher auch Hinweise und nennen dir vergleichbare Apps im Store, wo das schon so funktioniert wie du es möchtest.
Solange Apple nicht das Gefühl hat, das man den nur die 30% nicht gönnt, sind die durchaus informativ&kooperativ

[Zacherl]

Zitat von RWarnecke:

Eine App aus dem AppStore würde mir schon reichen, wo dieses erfolgreich umgesetzt ist, dass ich mir das dort abschauen kann

Schau dir mal die 1Password App an. Dort geht das.

[RWarnecke]

Zitat von Zacherl:

Zitat von RWarnecke:

Eine App aus dem AppStore würde mir schon reichen, wo dieses erfolgreich umgesetzt ist, dass ich mir das dort abschauen kann

Schau dir mal die 1Password App an. Dort geht das.

Danke für den Hinweis, aber die haben den Hinweis auch nicht drin mit der automatischen Verlängerung. Habe Ihn zumindest nicht gefunden.

Zitat von mensch72:

..."Ich möchte keine eigenen Rechnungen stellen und ich möchte es dem Anwender so einfach wie möglich machen ein Abonnement für die App abzuschließen. Das heißt, er soll keinen QR-Code einscannen müssen oder sonstige Sachen machen."...

Die entscheidende Frage ist, hast du einen eigenen frei programmierbaren (Web)Server im Internet, der "immer" von deiner KundenApp bei Bedarf erreicht werden kann&darf?
(wie geschrieben: im aktuellen Projekt haben wir uns für WorstCase notfalls auf Papier druckbare QRcodes entschieden, weil es da zusätzlich sicherheitstechnisch eben auch 100% "offline" funktionieren muss)

Wenn ja, kannst du statt QRcodes zu erzeugen, auch per TCP/IP Request von deiner App an deinen Server den aktuellen/"neuen" LicState anfragen und abholen, bzw. dein Server kann deiner App (zusätzlich) eine PushNotification zum "WakeUp" und zugleich auch im Klartext lesbare "Kaufbestätigung" senden... das alles benötigt NULL Nutzerinteraktion(wenn du App und/oder Server seitig es dir selbst so programmierst!) , erfüllt aber so nebenbei alle aktuell in der EU gültigen Vorschriften zur (End)Verbraucherinformation bei InApp Käufen und das ganz besonders bei Abschluss von InApp-ABOs!

Apple weiß genau, das ihr aktuelles AppStore Payment für Abschluss von InApp-Abo's nicht 100% EU konform ist... daher tollerieren die durchaus bewußt App's, welche das über andere Dienstleister und "eigene" Lizenz/Optionsverwaltung selbst lösen.

Wenn ich das ganze umsetzen wollte, müsste ich meine App im Bereich InApp-Kauf komplett umschreiben und dazu auch noch den entsprechenden Webservice aufsetzen, der die ganze Kommunikation zwischen z.B. ShareIt und der App abwickelt.

Zitat von mensch72:

Wegen aktueller Umfirmierung ist unsere alte "TestApp", die im Prinzip nix anderes wie ein LoginDialog mit einem dann zur Verfügung stehendem FullScreen-HTMLviewer war, aktuell aus dem AppStore heraus gefallen.
Wenn wir eine DUNS für unsere neue Rechtsform haben und Apple die App wieder so im Store aufnimmt, bekommste gerne eine TestLogin wo du echte Käufe/Abos für je 0,20€ durch spielen kannst. Ohne Erstattung!... die abgerechneten Transaktionen sind und bleiben echt, aber die Abo's wiederholen sich zum Test immer nur ein einziges mal... so testen wir auch selbst

Danke für das Angebot. Werde vielleicht bei einer anderen App nochmal wegen Details auf Dich zukommen.

Zitat von mensch72:

Apple ist relativ offen für direkte Fragen!
Schreib denen ein paar Sätze zu deinem Wunsch/Problem und sag denen offen in "welcher Richtung" du eine Lösung suchst. Wir haben so das nennen wir es geduldete Konzept mit online&offline "server side controled content" via HTMLviewer quasi absegnen lassen.
Solltest du es "nur" per AppStore lösen wollen, dann geben die dir sicher auch Hinweise und nennen dir vergleichbare Apps im Store, wo das schon so funktioniert wie du es möchtest.
Solange Apple nicht das Gefühl hat, das man den nur die 30% nicht gönnt, sind die durchaus informativ&kooperativ

Wenn das alles mal so einfach wäre. Ich habe denen geschrieben, dass ich gerne dazu bereit bin diese Information in meine App aufzunehmen und das ich bis jetzt keine Beispiel-App gefunden habe, die es genauso macht wie Apple es vorschreibt und das Sie mir bitte eine Beispiel-App nennen möchten. Da kam nur ganz lapidar zurück, dass Sie mir keine Vorschläge/Hinweise gegeben könnten wie ich meine App zu designen habe. Ich habe mir jetzt eine Variante überlegt, die vom Design her nicht schön ist, sondern eher hässlich aber ich versuche damit erstmal in den AppStore zu kommen. Denn das Update zu der App muss raus, ich kann da nicht mehr lange mit rum experimentieren.

Ich werde berichten, wie es weitergeht mit Apple. Wenn jemand noch eine andere Beispiel-App hat, wo dieser Hinweis mit der automatischen Verlängerung innerhalb der App ist, kann den gerne hier posten.