Reputation: 122
I've read quite a bit about in-app-purchase for iOS, including all of apple's documentation and didn't find anything regarding making the purchase from the backend server.
The piece of puzzle that bothers me is the situation when a user made a purchase on iOS and after it's done, the application got a receipt. It sends it to the backend server for verification and custom logic right when the user lost his internet connection. What happens next is the user sees an apple's dialog saying "Purchase completed" while the goods haven't arrive to the application (It's consumable virtual currency in my case).
So I was thinking a clean solution would be to just communicate with the backend server for it to make the purchase, and if internet connection was lost, no purchase is done (could be done in several communication steps).
What do people do in the case of the situation I described above? Showing a dialog to the user saying "Communicating with server" just for him to see any progress while retrying to send the receipt to the backend server?
I would love some best practice tips around this.
Some information: My backend server is .NET 4.5 WCF web service
Upvotes: 0
Views: 1930
Reputation: 26385
The answer is simple: NO.
It's because purchases are made by using your Apple ID and Apple doesn't want you to share these credentials.
You should care by yourself about all the things that can go wrong while communicating/validating the receipt.
Remember also that a user can restore his previous purchases restoring transactions, since your purchases are consumable type you should take care about invalidating already consumed receipt.
You can implement a system like that:
If the client never receive a validated response due to error or timeout, you can retry the operation or keep in the queue for a further check informing the user that there was an error.
Upvotes: 1