Nous développons une application qui utilise le modèle IAP de l'abonnement non renouvelable. Lors du test du processus d'achat d'abonnement dans la boîte à sable, nous voyons deux messages avec des boutons 'Acheter' apparaissent. P>
Le premier message est affiché avec les informations du produit: "Voulez-vous acheter un abonnement pour $ xx.xx?" P>
Après avoir cliqué sur "Acheter" pour le premier message, un deuxième message (avec un autre bouton d'achat) s'affiche: "Vous avez déjà acheté cet abonnement. Appuyez sur acheter pour le renouveler ou l'étendre. " P>
Est-ce que ce comportement normal iTunes / Sandbox de ré-achat d'abonnements non renouvelés après avoir expiré? Est-ce que iTunes vous oblige à appuyer deux fois sur un bouton "Acheter"? P>
3 Réponses :
Peut-être que vous l'avez acheté et il n'a pas expiré. Ou peut-être a peut-être été acheté dans un appareil différent, mais vous en avez toujours ancien. Quand il a essayé d'acheter son constaté que celui déjà acheté a donc demandé de s'étendre. IAP est lié à Apple ID. P>
Une chose que vous pourriez essayer (bien que je ne sois pas sûre que Apple va aimer cela) crée un tas de produits identiques dans le magasin (disons 48 produits identiques, mais avec des identifiants différents: abonnement1, abonnement2, ..., abonnement48) . Ensuite, lorsque vous devez prolonger l'abonnement, vous venez de choisir le prochain abonnement. De cette façon, l'utilisateur n'obtiendra pas ce message ennuyeux. Avec 48 produits différents, vous devriez être bon pendant 4 ans. Espérons qu'au moment où Apple a sa santé intellectuelle :) p>
C'est un peu boiteux, me donnant -1 sans prendre la peine de faire un commentaire. Nous sommes obligés de penser à de telles solutions maladroites par les politiques hostiles du développeur d'Apple. C'est Apple qui devrait avoir le -1. Si vous exécutez un service avec des abonnés mensuels et que vous êtes tout soudainement obligé d'utiliser des abonnements non renouvelables et que vous devez cliquer sur Acheter deux fois, il peut être assez frustrant.
Joris, je comprends vraiment votre frustration, et vous avez au moins suggéré un moyen de gérer cette question même si c'est une sorte de hack. +1 Upvote pour vos suggestions.
J'ai vérifié le comportement d'Evernote en prolongeant leurs sous-marins non Renweing et il semble que ce soit le comportement que nous ne pouvons pas éviter. P>
J'ai rencontré le même problème avec des sous-marins non renouvelables + mkstorekit et j'ai pensé qu'il a quelque chose à voir avec mes paramètres d'abord, mais je ne pense pas qu'il n'y ait rien que nous puissions faire à ce sujet.
p>
p>
Désolé d'avoir cogné une question antique, mais j'ai une question concernant ce comportement: cela vous facturera-t-il encore à nouveau pour l'abonnement, même si vous obtenez cette boîte de dialogue?
J'ai le même problème. J'utilise Mkstorekit et je me demande si ses processus internes sont tout à fait corrects. Je reçois ce message à la fois pendant et après une sous-expire. Frapper l'achat n'apparaît pas de prolonger le sous non plus. Je suis aussi proche de rouler ma propre solution ...
Comment gérez-vous un abonnement non -wing avec mkstorekit pls clarifiez? Cela signifie beaucoup pour moi // est-ce que sont considérés comme des consommables à mkstorekit
Je me demande aussi pourquoi cela dit "déjà acheté". Doc affirme que les sous-marins consommables et non renouvelables sont presque identiques et peuvent acheter plusieurs fois, alors pourquoi ce comportement? Est-ce un bug de sandbox? Pouvez-vous clarifier maintenant?
Est-il raisonnable pour nous un achat de consommable plutôt qu'un abonnement non renouvelable? Avec un achat de consommable, tout comme abonnement non renouvelable, le développeur peut enregistrer la date d'expiration sur leur serveur.