We are giving the purchased item on step 6, suppose that the app disconnects before step 7, and the purchase remains in a pending state. When the user loads the game again ProcessPurchase(step 4) the app sends the same receipt(step 6), and on step 7 the app server sends the app a duplicated receipt message, then the app does step 8 that works fine.
But what happens If the user doesn’t load the game for a few days, the purchase is going to be declined and after that, he can load the game again and is going to have the purchased item is that correct?
I don’t believe you want to award the product in Step 6? I believe it would be Step 9. Are you doing server side product fulfillment? You would want to test your scenario.
Yes, I am doing server-side product fulfillment, Step 9 is between Unity IAP and App Store, I guess I can do it after calling ConfirmPendingPurchase on Step 8, but if I do that is also possible to have server or connection problems, in that case, the user would not get the purchase but would we charge, defeating the propose of this flow, is that correct?
Thanks for the help.
Can you elaborate “we charge”? IAP transactions are handled by the respective stores. To understand your flow better, I assume you associate these purchases with a game user login, correct? So if I bought a product on the Android version of the game, I would also own it on the iOS version? If you are doing server-side fulfillment, I believe you want to acknowledge on the server with the Google API, so no need to call ConfirmPendingPurchase on the client. And an exception in the flow as you suggest should not defeat the purpose for the general case. At any rate, I would encourage you to test your flow.
I mean that If we do the fulfillment after ConfirmPendingPurchase the user would be charged but if there is a server error after that he would not get the item.
You are right in your assumption that when a user login would own it on Android and IOS on our game. Making the acknowledge on the server and not calling ConfirmPendingPurchase on the client makes sense. I didn’t saw a flow on unity documentation doing that. Can you confirm that flow is supported by Unity IAP?
I am confused about why our use case is different than the doc flow "Saving purchases to the cloud "and how would avoid the issue that I described if doesn’t do acknowledge on the server.
May I ask, where did you obtain that flow diagram? It doesn’t look like a cloud save flow. It looks more like server-side receipt validation flow (only).
That is a bit different flow and would not work across device types. For your scenario, you typically would acknowledge on the server not the client. Again, please test to confirm.
Ok, thanks, I saw this related [thread]( Unity IAP doesn't consume consumable acknowledged purchases page-1), so can you confirm previously was not supported doing the acknowledge on the server-side but now is supported starting from Unity version 3.2.3? You should probably add that to the documentation since is a lite confusing, I just don’t understand in what scenario the flow “Saving purchases to the cloud” would work, is always going to have those issues.
I suspect it would work for Google only or iOS only, but not both. Agreed on the documentation! And I’m not clear what issues you are referring to, you haven’t stated an error or otherwise. I personally have not implemented server-side save and is why I’m encouraging you to test. You are suggesting an error flow when the success flow has not been confirmed yet.
The flow “Saving purchases to the cloud” on the documentation is not for server-side save? I am probably missing something.
On testing yes sure I will test it but there are a lot of possible situations that can happen if you combine ios and android, delayed credit cards validations, wrong receipts, network problems, server problems, etc and since is a really crucial feature I just don’t want a case fall to the cracks. Furthermore, it can work fine now and on a new IAP update break since I don’t know if is the intended case of the library, is really bad if this breaks.
Is important to know-how is the intended use case flow of unity IAP for fulfillment on the server-side, it seems a pretty normal use case for the library.
The documentation appears to need updating was my point, apologies on the confusion. You are discussing error conditions, my suggestion is to get the expected flow working first. How are you acknowledging the purchase on the server with the Google API (for example), as in the link you shared? They are not using ConfirmPendingPurchase is my understanding, that is done on the server. For my understanding of your design, I suspect you are using a hash of the username as a primary key in a database on your server? I must admit that I have not tested server side save, so I may ask for other forum members to hopefully chime in here. This feature is on our roadmap.
My current flow is just returning PurchaseProcessingResult.Complete on onProcessPurchase, it works fine but not ideal because the server may have an error when doing the fulfillment, that’s why I wanted to change the implementation to the suggested flow on the doc of “Saving purchases to the cloud” I thought that was for our situation on server-side save. So if the documentation is no longer valid, I will wait until is updated before changing that or is confirmed by the unity team that is supported. Thanks!
@MatL It is supported, please try it. That diagram does not reflect server side acknowledge and is what 3.2.3 addresses. If you are not calling a store API as mentioned in the thread you linked, then the image is accurate. And again, how are you doing the fulfillment across multiple devices and possible OS’s per user? I had asked if you are using a username hash. Also, instead of rolling your own solution, you might consider PlayFab or ChilliConnect cloud save options.
I am doing the fulfillment using the user id, that is generated the first time that the user logs into the game, he then has an option of creating an account for having the purchases on other devices. Thanks, we will do the acknowledges on the server and remove it from the client if is supported.
It looks that I had a mistaken concept that caused this confusion, for example on android you need to acknowledge and consume a purchase. So the referenced flow seems accurate and applies to our case. You acknowledge the purchase on step 7 and make the fulfillment, from that moment the purchase is not going to be declined, and after that, you do Step 8 that consumes the purchase.
