1

I am implementing in app purchases for a few consumables products called GEMS. My app has its own server which keeps tracks of user information, including the gem count.

I am concerned about the following situation:

User A logs in the app and purchases a few gems. The app sends a transaction to the App Store. App receives transaction state as 'Purchased'. The app sends a request to server to update the gem count in the DB. At this point the server call fails and the User A will not be awarded any gems and hence the transaction could not be set as 'completed'.

At this point User A logs out and User B logs in. Since the previous transaction was not completed, the app, when relaunched, will receive this transaction and will again try to send a request to the server to award the user the purchased gems. But now the gems will be incorrectly awarded to the user B instead of A via my server call.

Now, how can I differentiate the said transaction to be of user A instead of B? Will I have to handle this locally on the app side; ie storing a unique transaction identifier against the user id? In that case how will I differentiate a previous pending transaction vs a new transaction.
Is server side receipt validation a solution? Even so, the receipt will not contain custom information regarding the actual user app account which made the request.

iqra
  • 1,061
  • 1
  • 11
  • 18
  • This doesn't sound like a case you would really need to worry about. If the user changes their account before their purchase has been credited, that is their issue. The correct iTunes account is charged and an account that the customer controls has received the purchase. – Paulw11 Apr 14 '20 at 11:07
  • But this is a valid concern. Regardless the user controls the account or not, the appropriate user should be given the goods – iqra Apr 15 '20 at 07:44

0 Answers0