Excellent news, thank you! Very happy to hear this. 
Please tell us when the new changes have been implemented. And in the meantime, indeed just tell if you want the help with the tutorial & backend testing.
I’m sure a fully working IAP, with somewhat easy setup & good documentation, will really be a gamechanger for Thunkable.
Hi! Playing around with IAP now. Can someone please explain to me what this option is for:
Use Cache History (Android Only)
Also, I have no idea what this means in the IAP Documentation: “For the fields in the return object, you can reference them here.” It is said a few times for the purchase blocks. Would anyone be able to help me understand what this refers to? I can’t seem to make sense of it. Thank you for helping me to understand.
It was an attempt to return all purchases from the android store. I’m not sure if it’s working or not yet. I need to complete testing
The following is from the docs we use to set this up:
Android Only.
A boolean that indicates whether or not you want to make a network request to sync expired/consumed purchases and those on other devices.
If set to true, this method returns purchase details only for the user’s currently owned items (active subscriptions and non-consumed one-time purchases). If set to false, it will make a network request and return the most recent purchase made by the user for each product, even if that purchase is expired, canceled, or consumed.
The return type if this is false is actually a subset of when it’s true. This is because Android returns a PurchaseHistoryRecord which only contains the purchase time, purchase token, and product ID, rather than all of the attributes found in the InAppPurchase type.
Default: true
Thanks for taking the time to respond and explaining to me. I hope it is useful for others wondering as well.
I’m taking baby steps at a time to take this IAP with just 1 product in my app and it’s definitely not easy for a noncoder. It’s like a jump from playing with Lego to robotics for me. Thank you for your help with these questions again. Here’s another one I have:
I see in the example, the top 2 field names begin with subscription. Does it change with a 1-Time purchase product?
Hey @hhuman
Great question.
I set those up initially to be specific to my 2 purchases I was testing with.
One was a subscription and the other was a 1-time purchase to remove ads.
I will be updating this more soon! I have discovered a more preferable way (for me) to track these items.
Moving forward, when I implement IAP, I will be storing all purchases on a user object (a row in my user Data table) stored in my cloud server. But it would be the same idea. this could easily be done with firebase.
This way, it will also be easier to restore purchases. I have put a lot of thought into that logic and plan to clean things up with some explanations soon!
Thank you for replying Jared. That’s exactly what I just did… however I combined both ways of storing the data. The way you showed in the above example with a saved variable and the receipt of the 1-time purchase transaction in firebase after the user signed in. Perhaps only the cloud way is necessary for restoring accounts. It took some time to understand what you put together in these examples but it’s working so far as I’m testing for iOS. Thanks again.
Are you using Firebase functions or did you go the Xano route?
Dear Jared, I used the Firebase blocks as shown in the picture attached. I just added it to the examples you showed. Going to trim away a bit now. I think the stored app variable for storing the transaction receipts as an object might become an app variable instead. Only thing is that this way might require the user to be online to check for the unlocked status of the app each time they boot it up to use the purchased functions. What is Xano route?? Please enlighten me some more. Still a little amazed at how smoothly it all went in testing from putting bits and pieces of info together from so many different places where you and the community have discussed IAP (as well as the links to various Apple and Android developer resources you provided). For sure, it could save weeks of hesitation for many to dive in once all of the documentation is gathered. The intense feeling of being lost the entire time was next level for me as a blockcoder. Big thanks for all making it possible though. IAP with Thunkable is just in time for me and my work! Peace be with us all!
You could probably limit this to weekly for subscriptions or after theyve been in the app for X amount of minutees or what4ever.
Thank you for this. The advice I needed. Working on this bit right now. Btw, I should mention that I’m only testing the IAP for 1 single item right now with iOS.
Ok, got the IAP done and tested for iOS version. Did it backwards from what I saw recommended in other posts. I have a question about the blocks for Android purchase acknowledgement. In the image below, should the highlighted block be the subPurchaseObject app variable instead? Thanks again for your help, bros and sistas!
Aaww man, just when I thought that was the last question I had, here comes another. It’s for Android purchase acknowledgement as well. I don’t understand why when the state is 0, we update the properties of the saved purchase information variable and remove the ads, but when the state is 1, we only post to the serverLog with a “Good to go” message. If both of these acknowledgements are good, then how come we’re doing different things? And how can they both be good? Thanks again for all of your help…
