Vérification InAppPurchase & serveur séparé pour la logique du jeu

en général, vous semblez souffrir du problème des deux généraux qui était

le premier problème de communication informatique s'est avéré insoluble.

puisque partout dans votre protocole de communication un message peut être perdu (même l'accusé de réception ou l'accusé de réception ou le ...) vous ne pouvez pas être sûr à 100% que les deux parties de communication (l'appareil Utilisateur et votre server) ont convenu du même état. Vous pouvez seulement dire que sur une certaine probabilité l'information d'État a été échangé avec succès.

j'envoyais deux ACKs aller - retour et stocker l'achat si un nombre suffisant a obtenu creux. Citation de Wikipedia:

aussi, le premier général peut envoyer une marque sur chaque message disant qu'il est le message 1, 2, 3 ... of N. Cette méthode permettra au second général de savoir comment fiable le canal est et envoyer un nombre approprié de messages en arrière pour assurer une forte probabilité d'au moins un message étant reçu

pour la satisfaction du client je prendrais le risque en leur faveur - 1% des marchandises non livrées vous obtiendrez dans beaucoup de problèmes, mais 1% de perte de votre côté est acceptable.

considérant que vos gemmes sont une monnaie virtuelle, alors le type de produit naturel In-app doit être consommable , c'est-à-dire qu'ils ne sont pas des achats restaurables.

pour consommer un achat avec un achat Google Play vous appellerez consumePurchase . Sur iOS vous appellerez finishTransaction sur le SKPaymentQueue . Dans les deux marchés, l'achat de consommables restera actif jusqu'à ce qu'ils aient été consommés. Si l'utilisateur supprime l'application de leur appareil avant l'achat est consommé, ils seront en mesure de ré-installer, et de restaurer leurs anciennes non consommées achats.

entre-deux De l'achat initial, et la consommation est l'endroit où vous voulez mettre votre validation côté serveur. Lorsqu'un achat est effectué, envoyez le reçu ou le token à votre serveur, effectuez la validation et répondez en conséquence. L'application doit attendre une réponse valide du serveur avant de consommer la achat.

(notez que les achats consommés ne figureront pas dans la collection in_app sur un reçu iTunes. Ils ne sont présents que si l'achat n'a pas été consommé encore).

si le serveur est temporisé ou si la connectivité réseau est perdue, les achats resteront actifs et l'application devrait continuer à essayer d'envoyer les détails périodiquement jusqu'à ce qu'elle reçoive une réponse attendue.

achats pour les deux Google Play et iOS sont stockés localement de sorte que vous aurez juste besoin d'exécuter un processus qui recherche les achats non consommés une fois que la connectivité réseau est rétablie.

vous pouvez traiter l'approvisionnement de gemmes de la même manière qu'une banque traite les dépôts de chèques; le nouveau solde sera immédiatement mis à jour, mais le montant disponible ne correspondra pas jusqu'à ce que le chèque (ou dans votre cas une validation) est compensé.

un pseudo code pour clarifier le processus:

Purchase product or Restore purchases
While consumable purchases > 0
  Send purchase receipt to API
  If response is ok
    If purchase is valid
      Consume product
      Allocate gems
      Break
    Else
      Remove retroactive gem allocation
      Discipline the naughty user
      Break
  Else
    Retroactively allocate un-spendable gems
    Pause process until network is re-established
      Re-send receipt to API

Je n'ai pas beaucoup de connaissances sur android, mais après avoir lu votre post, je me suis vraiment intéressé à la recherche vivement et plus sur la façon dont le jeu comme clash Of clans en app purchase logic work et empêcher la liberté faux achats hacks .

après avoir fait quelques recherches, je voudrais partager mes pensées sur votre problème, vous pouvez le mettre en œuvre en suivant l'approche :

Faites votre achat d'application vérification entièrement en ligne. Par exemple, vous pouvez considérer le jeu clash Of clans.

Comment cela fonctionne:

1) charges de jeu, synchronisées avec le serveur. Connexion réseau requise, car la connexion réseau interrompt le téléchargement du jeu depuis le serveur.

2)L'Utilisateur a 10 gemmes, le serveur a aussi 10 gemmes.

3) les gemmes achetées par L'utilisateur, le serveur vérifient l'achat séparément pour les consommables achetés, les gemmes créditées pour le compte de l'utilisateur.

4) Si dans le cas où le réseau peut échouer, alors aussi le serveur peut vérifier l'achat et plus tard, il mettre à jour en compte de l'utilisateur, si elle est sur un périphérique.

5 ) cela vous aidera également à contourner de nombreux faux dans les piratages d'achat app comme liberté ( prévention ) et Lucky patcher .

Google api côté serveur afin de les vérifier ou de les obtenir détails d'achat et lorsque l'achat de côté de l'application et côté du serveur correspondent alors seulement vous créditez des gemmes ou des articles consommables dans le compte des utilisateurs.

pour plus d'informations sur les achats d'application et leurs préventions de piratage, vous pouvez visiter ces liens:

1) côté Serveur de vérification de l'achat in-app de la partie 1 et partie 2 .

2) Comment vérifier dans app purchase côté serveur de facturation .

3) de Vérifier l'achat via PHP .

4) Sécuriser l'achat in-app scénario sur le serveur web .

Espérons que cela pourrait vous conduire dans la direction où vous voulez aller, aussi j'aimerais entendre vos pensées sur le même.

vous pouvez essayer de restaurer les achats In App effectués avec un compte particulier.

la fonctionnalité est donnée uniquement pour ce cas où soit le paiement a été fait et l'utilisateur n'a pas reçu les éléments il a été promis ou quand il commuté l'appareil.

lors de la restauration de l'achat, vous recevrez le produit acheté de nouveau à partir du serveur iTunes et alors vous pouvez en conséquence notifier votre serveur.

quelques conseils:

1. L'utilisateur achète des gemmes avec IAP
2. PEI réussit
3. Internet décompose
4. mon propre serveur n'est pas notifié
5. l'utilisateur désinstalle l'application de son appareil

6. L'utilisateur peut alors installer l'application sur d'autres appareils:

   soit il a été facturé et il a obtenu les gemmes par quelque magie, ou il a été remboursé automatiquement, puisque les gemmes n'ont pas été reçues.

1. à l'étape 3, les renseignements sur les reçus sont stockés sur l'appareil de l'utilisateur. Si l'utilisateur désinstalle et réinstalle votre application, la réception d'informations seront perdues. Mais vous pouvez le restaurer; Apple parle de ce ici . Vous pouvez renvoyer un reçu restauré à votre serveur. À votre serveur, vous vérifiez que plus de Gemmes pour l'utilisateur afin qu'il puisse recevoir ce il devrait être.

2. il a été remboursé automatiquement, puisque les gemmes n'ont pas été reçues

   cela semble impossible avec IAP parce Qu'Apple ne permet pas à un utilisateur d'annuler leur achat. (Avec Google IAB, remboursement sont autorisés, plus sur ce ici )