Différencier l'achat initial et le "ré-achat" gratuit dans StoreKit / Achat In-App

Depuis le guide StoreKit:

Si l'user tente d'acheter un produit non consomptible ou un abonnement renouvelable qu'il a déjà acheté, votre application reçoit une transaction régulière pour cet article, et non une transaction de restauration. Cependant, l'user n'est plus facturé pour ce produit. Votre application doit traiter ces transactions de manière identique à celles de la transaction d'origine.

Cela présente un énorme problème dans une application sur laquelle je travaille. Nous avons concédé sous licence une grande quantité de contenu d'un éditeur en vente via un achat embedded. Ils exigent que chaque fois que nous vendons une partie de ce contenu (c'est-à-dire que l'user nous paie), notre server appelle une API sur leurs servers pour signaler la transaction. C'est à des fins comptables et finalement utilisé pour déterminer combien nous les payons à la fin du mois, selon notre accord avec eux.

J'ai lu plusieurs suggestions sur SO et ailleurs pour appeler restoreCompletedTransactions assez fréquemment et maintenir une compréhension locale, sur l'appareil, de ce que l'user a déjà acheté afin qu'ils ne puissent pas être autorisés à l'acheter à nouveau. Cela me semble être quelque chose qui devrait pouvoir être implémenté du côté server. Cependant, les reçus que nous recevons des servers Apple sont exactement les mêmes pour un achat et un ré-achat, comme promis par le guide StoreKit.

Si les callbacks de paiement de StoreKit ne peuvent pas être considérés comme un mécanisme comptable valide dans ce type de situation («vous avez été payé» vs «vous n'avez pas été payé»), quelles sont les autres informations en time réel sur le trafic des transactions? Je ne pense pas que l'éditeur avec qui nous travaillons sera heureux si nous leur disons que nous devons attendre 45 jours après la fin du mois pour get le montant REAL payé d'iTunes Connect.

J'ai récemment examiné le même problème. Dans mon cas, je voulais mettre en œuvre un suivi précis des revenus en utilisant le suivi des applications mobiles pour suivre les revenus générés par les différentes campagnes d'acquisition de clients.

Heureusement, il existe un moyen de le faire. Il convient de noter que SKPaymentTransactionStatePurchased vs SKPaymentTransactionStateRestored dépend uniquement de l'action d'initialisation, par exemple si vous avez initié une restauration ou un (ré) achat, de sorte que cela ne fonctionne pas.

Qu'est-ce que fonctionne à la place vérifie pour SKPaymentTransaction.originalTransaction qui sera != nil pour les restaurations et les ré-achats. Ce dernier est malheureusement un comportement indéfini ( docs ). Je considérerais un contrôle nul juste assez cependant.

Une autre option consiste à valider la transaction-réception des transactions avec SKPaymentTransactionStatePurchased et à vérifier que la propriété original_transaction_id dans le reçu validé returnné correspond à transaction_id .

Les mauvaises nouvelles sont: Dans la version iOS actuelle (4.3.x), il n'y a aucun moyen de faire la distinction entre un achat et un ré-achat de produits non-consommables.

Pour faciliter la situation, je reorderais deux choses:

Premier

Après un achat réussi, stockez l' product identifier du produit acheté dans NSUserDefaults sur l'appareil. Vous pouvez ensuite masquer les produits déjà achetés auprès de l'user et ainsi gérer une situation de ré-achat.

Les NSUserDefaults sont sauvegardés par iTunes lorsque l'user synchronise son appareil. Ainsi, vos informations d'achat stockées ne sont pas perdues lorsque l'user obtient un nouvel appareil.

Seconde

Stockez datatables de réception avec l'identifiant de l'appareil sur votre server. Analysez l'identifiant du produit et l'identifiant de l'appareil.

Si vous recevez un autre reçu avec la même combinaison d'identificateur de produit et d'ID d'appareil, associez-le à un nouvel achat. Au less, cela vous permettrait de couvrir la plupart des cas de re-buy.

En supposant qu'un user d'iPhone ordinaire change son appareil tous les 1-2 ans, vous couvrirez au less la plupart des cas de re-buy et peut-être que Apple va résoudre ce problème à l'avenir.

J'ai une solution,

Configurez le produit en tant que consommable. Cela permettra de résoudre le problème – (Ils exigent que chaque fois que nous vendons une partie de ce contenu (c'est-à-dire que l'user nous paie)).
Ensuite, vous devez implémenter une logique dans l'option d'achat de produit. C'est d'une manière que, une fois que l'user achète un produit, l'option d'achat doit être supprimée, sinon l'user peut heureusement aller acheter et perdre de l'argent une fois de plus pour le même produit dans le même appareil. vous pouvez utiliser NSUserdefaults à cette fin.

Merci,