Hi. There definitely will be a similar thread in the forum, but I couldn’t find anything which might help me to understand the workflow of IAP in some cases.
I’m trying to verify the purchase on the server-side. So on PurchaseResult, I should return status Pending.
Q1: I’m running coroutine before returning status. In that coroutine, I’m sending a request to the server-side to verify the purchase. And if it’s ok I’m calling ConfirmPendingPurchase(p). Is this correct workflow(about coroutine)?
Q2: If the server sends a bad response, what I should do in that case with purchase status? There is no method like “RejectPendingPurchase”
Thanks.
I suppose there will be other questions by the process, and I will be grateful if someone can be in direct contact with me(FB, Discord, Hangout…), so I can get the answers quickly. (I will not spam with easy questions, I promise )
There is a very nice image of how the server-validation workflow should be in this thread:
Q1: yes, a coroutine is fine. I’m doing the same in my Asset Store asset (Simple IAP System) and yield until the web request completes.
Q2: depends on what your fallback should be. Do you want to deny purchases if the your validation server is unreachable? Do you always want to grant purchases, but only deny them in case the App Store tells the receipt is fake?
In my validation logic, ConfirmPendingPurchase is always called, so that the receipt is not getting validated more than once. Then the local outcome is based on the response received from either the validation server or App Store.
In the case that your server finds a bad receipt, you return Complete from ProcessPurchase , but don’t award the product to the user. You might want to pop up a dialog to the user also.
@Baroni1 - about Q2. Yes, I want to validate the purchase from the server-side because hackers can simulate the purchase, and get content without paying.
@JeffDUnity3D hm, that makes sense. So if the server sends a bad response, then I will not give the item to the user, and the user will not lose money(because of the fake transactions), otherwise - all will work great.
@art1997 I might suggest that you just use the built-in Receipt Validator and validate server side only if necessary. You’ll spend a lot of time on server stuff, and not so much time available to make a great game!
My questions on Q2 were not really directed at why you want to use receipt validation, but what you want to do in these cases I meant that you can be more strict about denying purchases, or more forgivable. It fully depends on your principles on hacking players.
But like JeffD wrote, server side receipt validation is not really that necessary in most cases. If you’re not implementing a subscription based revenue model, you can easily get along with local validation.
)