In App Purchases Documentation

My post is related to: IAP on iOS and Android.

We have finalized our V1 of the IAP documents with the hope that it will enable many Thunkable developers to integrate IAP with their apps. If this plan is successful, it allows Thunkers to start or strengthen a business with with their app ideas by allowing monetization of in-app content.

What I am trying to do is:
Gather as much feedback as possible: both good and negative. This will allow us to refine and strengthen the docs with the end goal being a complete guide using/incorporating IAP into any kind of app and making the process as painless or simplified as possible.

1 callout from me is that these docs may not be 100% complete. They are based on my experience and exploration as it related to implementing IAP into one of my own apps on the store. Where you find gaps in the knowledge or anything that’s confusing, I encourage you to ask for me to fill it in!

A Brief Overview of In-App Purchases in Thunkable


Cannot reach the document.

1 Like

gimmie a minute. Somehow I messed things up when we published! they are moved


The docs have been moved into the correct location!

@mephjl @martint @tatiang @ethosworkfi @bradofalltrades


Really cool! Thank you! I’ll start going over the manual bit by bit in the coming days.

Just a quick comment right at the beginning. The color of links is a bit too bright, almost impossible to see.


Huh, I’ve been just reading through the whole set (again, since I gave it a preliminary look a while ago). It’s a handful (although, I want to thank you, again, for the extensive work too).

Let me just come back to my earlier suggestion – it would be really helpful if you could set up a sample project in the tutorial alongside the instructions. I don’t mean an actual sample project, but rather an example in the text. Like, say, you would have a game called “Beaver the Barbarian”, with items to purchase, and you could then walk the reader through this setup throughout the guide.

Like I noticed myself wondering already in the beginning what would a typical product id look like. Then you could say here something like “here we will create an upgraded sword item that the Beaver the Barbarian could buy as a one-time purchase and let’s give this purchase a good id that matches the content, such as…” and so forth. I don’t mean that it should be idiotic, but if you could walk us through something like this, it would give coherence for the guide as it’s a bit long, after all.

How would this sound to you? :slight_smile:

EDIT. Also, with the sample codes, I see bits and pieces here and there that I would probably need to be changed to match my own project (like package names etc). But I don’t have any instructions for this. So, in fact, it’s not so simple as it might seem at outset; that I can just copy-paste the code etc. Maybe I can figure these steps out on my own, but it would just be so much better if you could really indicate the steps, down to detail, the reader needs to take to modify this to her own project (this could be achieved by utilizing an example such as the one I described above). Naturally, you can’t give all the answers, but with an example it would be easy to see what needs to be changed to tailor the instructions to your own needs.

So, as it stands now, the guide is excellent but I feel that it leaves too much for the reader to figure out on herself when converting it to own needs, so it starts becoming a bit too hard to access. :confused:


Two more things, I’d like to be addressed if possible:

  • If I include passwords / API keys etc. for the payment procedure within the app, can they be reverse engineered, or if there is such a risk, how should I secure them from this? Naturally, this is always a challenge with apps, but particularly so with payments. So could you also include easy instructions for this in the tutorial? And/or should I set up some restrictions on the cloud side to guard against any malicious attempts?

  • I see you have screenshots from the new editing interface, but I (and probably many others too) use the old interface (as it has some features the new doesn’t, for instance). Could you include screenshots / instructions for the old interface too?

This was a handful on my part now, but I’m sure if the IAP guide will be really accessible to Thunkers, it will create a lot of new value for many and also make the platform a lot more interesting to new ones. :slight_smile:

1 Like

ping @jared

So, here’s a newly edited version of my yesterday’s numerous thoughts, suggestions, and questions on the matter:


It seems that server log function blocks are missing from the tutorial, and the logging part might also be missing from the cloud side (unless you count the logging function for Google Cloud, which is there). However, the bigger question to my mind is do we really need the logging part as of now, as it tends to make the blocks & cloud code more complicated. I’d advocate for using merely regular alerts on the app side to indicate successes / problems with the process.


The sequence of presenting different steps is a bit awkward as you really can’t implement the steps following them from the very beginning. And some steps are even missing, such as being explicit about creating different Web APIs for different platforms. This becomes very clear if you try to do one concrete thing, such as begin by implementing one-time purchases for Android, which I’d advocate to be the first lesson (as an example), and then add details to this later on. If you do this (one-time purchases for Android), the sequence should be something like the following:

  1. Prepare all the required blocks and functions on Thunkable at the same time, beginning from the very beginning, i.e. from creating the needed variables, and continue from there. I might also recommend avoiding utilizing separate functions as it makes learning a bit cumbersome, even though coding-wise it’s naturally elegant. Also, for the blocks (and the code with the cloud), as noted, I’d leave out the logging part and rather replace it with basic alerts on the app side. Also, as noted, there’s a need to be more explicit about steps along the way such as creating the Web API (for Android calls in this case).

  2. Create a closed testing on Play Store and publish app to there. Also include testers & licencing for them.

  3. Create a test item on Play Store & include it on the IAP component on Thunkable.

  4. Create the Google Cloud backend, preferably without the logging part as this would make it simpler. Also, you should indicate exactly what parts of the codes for the cloud should be changed to match the user’s own info, such as the user’s package name.

  5. Make a test purchase & restore the purchase with the app. For this you should test if the blocks really work currently. I was able to do a test purchase alright, but not the Get Purchase History, which might have been my fault or maybe there’s something wrong with the block, indeed. So, could you please try out that the block is actually working currently? Following your example, my app crashed with this block, and with further, simplified testing, I merely got an empty [ ] response with the block. I’m using the old editing interface, if this makes any difference.

Furthermore, I just heard from @muneer that this block might not work for one-time purchases yet, only for subscriptions. But that the team said earlier that enabling the Get Purchase History block for one-time purchases was in the works. As the tutorial seems to take it for granted that it will work for all kinds of purchases, I was wondering if the block has been upgraded now to work for one-time purchases too? And if it doesn’t work for one-time purchases (only for subscriptions), after all, will this be addressed anytime soon? It would be really good if it worked for all kinds of purchases, as without it, things such as restoring purchases to the user become way more complicated and would involve some kinds of cloud functions (which are beyond my skill level to create…).


Small detail, but important if you follow the example given (which is the easiest thing to do in the beginning), is that it seems that the property “removeAdsTransactionId” of stored variable storedPurchaseInfo is utilized here and there, but in the beginning this property is introduced merely as “removeAdsTransaction”. So I guess it should be corrected to “removeAdsTransactionId” when it’s introduced.


Also, as @muneer pointed out earlier in a different thread (In App Purchase help - #7 by namitnagar), I’m wondering if you should first get the products info before proceeding with a purchase, at least @muneer said it was mandatory for Android. Currently, you don’t have this not reflected with the blocks as far as I can tell.


As noted already, the guide should be more explicit about creating different Web API’s for different platforms, just wanted to highlight this again.


In terms of security, I’m worried about the possibility of reverse engineering of the app & man-in-the-middle attacks. Particularly troubling to me seems to be the fact that you’re including App Store app password with the app. Shouldn’t this password be rather on the cloud side (overall, isn’t the whole point of using your own server in the middle to control such things)? So I’d modify the Cloud code to reflect this (contain the app password there instead of the app side).

Overall, I’d urge to think through other such issues. As this concerns the payment structure, I’d really emphasize being careful here with these matters. Also, it would be good to address the question of what kinds of limitations you should impose on your cloud functions on the cloud side (for example, besides limiting use cases, can you also limit the usage?).


About the cloud code, moreover, as noted in passing already, the tutorial doesn’t indicate where the user should modify the code to her own case (i.e. change package names etc.). So this should be addressed.


As I already noted in my previous message, as to layout, the color for the links in the tutorial is light grey, which makes them hard to read. Hoping this was changed. Also, as I noted before, as many Thunkers are using the old editing interface, it wouldn’t hurt to have screenshots from this side too if there are differences with the two interfaces (usually not in this case, but good to keep in mind).


So, that’s it. I’m really looking forward to implementing IAP and I’m really happy for all the great work done on the tutorial, but there’s still some way to go. Hopefully these things would be cleared soon, as we’re so close to getting IAP actually working for most Thunkers, which would obviously be a huge, huge boost for everyone on the platform.

I would also be very happy if someone like @muneer could participate and help out here and share your full experience, from A to Z, with implementing the IAP (including details such as your cloud code etc) if in any way possible. That would be awesome. :slight_smile:


The very first reason why I have not yet participated is because I quickly glanced through the guide and have not taken it point by point.

The other reason/reasons for the same is that:

  • I took the Google Apps Script approach and the guide is based on GCP (Google Cloud Platform) which Google recommends, therefore I do not want to make any comments before I actually go and do it myself.
  • The guide uses Service Account which is again recommended by Google, but in my implementation, I chose the OAuth method.
  • The guide implements the Billing Library and I selected the API end points.

With all these differences I would not comment right away before walking through the guide and creating the IAP function in one of my apps using the steps in the guide.

1 Like

Looking forward to it! :slight_smile:

1 Like

I know there’s a lot of feedback here from @ethosworkfi and this feedback from @muneer is important too. I want to say I don’t like the approach of using code at all. SO,
I took the time this week to develop a nocode approach I’ll be sharing this or next week!

If anyone wants to test with me *hint hint * I’d love some extra eyes on the process.

For @ethosworkfi if you’d like, perhaps we can arrange a time next week to meet and chat more about your ideas here!

The reality is: if the guides is too complex or not clear, the instructions need to change and the current docs can be a reference doc (which it pretty much is at this point). I need to ensure it’s easily digestible for the community!


Hi there,

Sure, I’d love to chat with you and I can also help you with the nocode testing, although my next week is a bit busier than this one, so cannot make promises, but I’ll help you if I just can.

In any case, eventually I’ll be able to try out pretty much everything, and as before, I’ll try to offer you the best feedback I can. I think getting the IAP to work for Thunkers (finally, after a long wait) is really a common cause as it pretty much decides whether projects will be financially sustainable in the long run or not (or at least gives a fair shot at this).

I might also be a good candidate because even though I have a somewhat solid background from Thunkable development, I’m not a coder after all, so for example all kinds of Cloud integrations are just new to me – and thus, I can perhaps look at the process from such a perspective that will resonate with many other Thunkers too (who are not coders either). So I really need instructions that are clear and concrete – for instance, if someone says to me that I should consult a manual on some cloud functions and then set them up, this really doesn’t get me anywhere. :slight_smile:

Just message me if you have any suggestions for the chat time & for the help with the testing. I’m living in Finland, which is 7 hours ahead of East Coast time, and further so with the West Coast naturally, so hope we could take this into account. :slight_smile:

However, let me just already say that my biggest concerns / questions are pretty much listed here now, so if you could just provide with some answers, this would help me a lot. Such as, is Get Purchase History block even working for one-time purchases etc. Naturally, the landscape might change a bit if your nocode solution will help to address some of these questions.

My biggest hope for now is that I could do one-time purchases for Android, and have a complete process (with verification/restoration) for this in an easy, reliable and hacker-proof way, so if your nocode solution (or whatever you do next) could particularly help to address this, it would be a great place to start. Of course, I want to do iOS too, and subscriptions would be awesome as well, but if I could just start with this, it would already be a great leap for me. :slight_smile:

Once again, big thanks for all the marvelous work @jared & also for your kind help @muneer

1 Like

Count me in.


I saw a sneak peak of this yesterday and it looks very exciting!


By the way, just commenting here in passing that @muneer also tried out the Get Purchase History block for one-time purchases and it doesn’t work. :confused: Just returns [ ] as I discovered. This is a bit problematic as it makes hard to do things such as restore purchases. But I guess this will be fixed soon (?), as the block seems to be working for subscriptions and it really doesn’t seem to make sense why it couldn’t work for one-time purchases too. And the blocks in @jared 's manual were also build around the notion that it would work for all kinds of purchases.

1 Like

Yes, I can confirm that. It was first reported in October '21 while testing the IAP feature. However, My workaround was to get the purchase info at the time of making the purchase and save it to Firebase.

1 Like

Any news on this? Ping @jared :slight_smile:

Particularly, the Get Purchase History block is where I’m currently stuck in. I also created a GitHub ticket about it: Get Purchase History block not working for one-time purchases · Issue #1140 · thunkable/thunkable-issues · GitHub

Still waiting to make my millions. :smiley:

1 Like

Not yet. Chatting with our lead engineer Friday about this topic.


Thanks for the update @jared ! :slight_smile: Very good to hear about the chat. I’d also appreciate if you kept us posted here regarding what’s happening, what’s been implemented on the platform etc.

For me, naturally, the most pressing issue is getting the Get Purchase History block functioning for one-time purchases, as without it, I really need to delay the implementation of IAP altogether.

So, just to give you more details, I tried the Get Purchase History block for Android and at least with Android, it didn’t work for one-time purchases, but I haven’t tried it with iOS. So at least for Android, it’s not working currently, as described. But if and when you get the block working (even for Android, but preferably for both platforms ofc), it would be great if you could tell us about it here, so I’d have the green light to proceed, as otherwise I’m just in a waiting mode for it.

The second biggest thing would naturally be figuring out the whole process better (themes such as questions/suggestions relating to your guide; how to implement the backend the best way, such as could it run via Xano, etc), which you’re working on already I guess (which is marvelous).

So, overall what I’m saying is that I’m really eager to proceed with this, and I’m hoping things move on soon and please keep us posted & inform us if we can be of any help to you. :slight_smile:

1 Like

And me.


So to update the crew here.

I spoke with the lead engineer today, he will be adding an ability to create non-consumable android purchases. That will be the addition of a toggle on the one time purchase block.

In addition, we will work on the purchase history. It will also be modified such that It can return all purchases. There’s a weird discrepancy in what the android store returns versus what the iOS store returns when we ask for the same information. We’re looking into how we can make the Black return the right data and we think we have it figured out. Hopefully we can test it next week and have it live as well.

At this time it does not return all purchases and only returns non-consumable or subscription purchases from android.