First of all, the Purchase Items is a list of all purchases made by the email address used in the mobile device.
This means that it starts simple for the first app but then goes to be complicated when you have more that a single app with In-App Purchase details.
So you need to be sure you are reading the correct purchase item and from their you need to poll the receipt from the App/Play Store to read the details of the purchase and read the expiry date. Compare the expiration date of the purchase with the current day to determine what to do next.
@muneer@jared@cassandra Thank you for your response.
Unfortunately Iām at a stoping point. Iām not a programmer nor do I have computer science schooling. The validating_receipts link is over my head.
Ultimately I need specific thunkable block examples of someone already doing these. Iāll have to chalk it up to a āwinā that I was able to figure out how to execute purchases on apple/android store. Perhaps that is enough for now.
I may learn more about Object blocks as they seem important here. Thank you again for your help.
One workaround, which is not a good way, I must admit, is to actually record the subscription in your own database (Google sheet, Airtable or Firebase) and record all relevant information you need such as subscription start time and compute the subscription end time.
Next time the user logs on to the app you need to read the data from your own database and decide if you open the premium services or not.
Of course this is not a good solution because App Store and Play Store allows users to cancel the subscription from the user account management not from your app and therefore you need to retrieve such information from the Store directly to know if the subscription is cancelled and if the Store has automatically renewed the subscription.
Can you or anyone provide the blocks to do this? Honestly I spent the whole weekend trying to figure this out. With nothing to show. @muneer@domhnallohanlon@cassandra
Getting the blocks to check if the user has an active subscription, yes or no. It not only would unblock me but it would enable me to launch my edu app made with thunkable and propel me into creating more! Thank you anyone and everyone thank you!
A good catch here. You are trying to use the Purchase History or Get Most Recent Active purchase and both gives you essential information and the receipt ID which you should query the AppStore and get the details of the purchase.
As of now, Thunkable does not have a block to retrieve that and I believe they should not attempt to make one as Apple/Google recommends that this should be done by a server service outside of the app.
For a server side code, you need to create that server side code and then the server you have chosen will have more or less instructions how to connect it to other apps/platforms.
Right, I get it as @muneer is saying ā you canāt verify the subscription status from the stores directly and instead you should record it and keep tabs on it on, say, Firebase. But, as @muneer also kindly pointed out, the stores allow for the user to cancel the subscription, which then doesnāt automatically inform the app and the connected backend, such as Firebase. So the user could activate the subscription, and the app would record this on Firebase, but if the user then cancelled the subscription from the store, the app/Firebase backend would have no clue about this.
How on earth do you then solve this problemā¦ There must be some way to do this, as evidently there are a ton of subscription apps out there. Does anyone have an idea.
Edit. Ah, it seems that youād need to utilize your own server to even confirm the subscription in the first place (didnāt read the thread carefully enough), i.e. to avoid the subscription of being cancelled. Well, I must also admit that I donāt have a clue about setting up such a connection via my own server. Maybe the promised and upcoming (more extensive) Thunkable docs on IAP could address these issues, perhaps even offer to set up the server connection automatically (via Thunkable servers)?
I must say that this situation is not that bad. If you recorded the subscription in your own database (Firebase for example) then you will continue giving premium access to the user for the length of the subscription whether the user cancelled or not.
The issue becomes more complicated if the subscription fee is refunded due to Store rules and regulations and you are not aware. In this case you have provided premium access for free.
Another more important situation is when the Store automatically renews the subscription, how would you know if you should extend the premium access or not???
Typically, you will have the following:
You will create a server side code (app) to inquire the Store using the Original Order ID and Transaction Receipt ID.
Every time the app starts, you will get these info from the blocks and pass them to your server app to get the required info from the Store. You would most probably use the Web API block in Thunkable to communicate with your server side app.
Your server side app will pass back the required info to your app to decide what to show and what to hide.
A good candidate for server side apps is GCP (Google Cloud Platform) which you can design your code on it. There are many other servers like Heroku which can server for the same. I made my code inside Firebase using the Firebase Functions which is a Node.js server but Google now recommends porting it to GCP.
Got it, thanks! But the real problem for me is that I havenāt never created such cloud functions, nor operated with Node.js. Well, of course one can always learn.
But, may I just ask to clarifyāhave you, indeed, built such a system for Thunkable subscriptions? Or are you talking just more generally about the possibilities for integration.
And if you have built such a system (for Thunkable subscriptions), could you perhaps offer some guidance as to how me or the others could set up similar systems of our own? Like some line of code for the cloud functions etc.
Of course, ultimately, this is something the Thunkable docs could/should address (when theyāre updated for IAP to be more comprehensive), but if you can provide anything at this point, @muneer , it would certainly help us all strugling with implementing the IAP.
As I have said in my last post YES. I was saving subscriptions/ one time payments in Firebase so I used Firebase Functions to inquire from the Play Store.
You will need to include the relevant libraries (SDK)
Provide your developer access token and then issue this command to get the detailed info
"https://androidpublisher.googleapis.com/androidpublisher/v3/applications/com.your-app-name/purchases/subscriptions/your-subscription-name/tokens/".[ Your Transaction Receipt ID];
You should get the result in JSON and you could decide to continue your necessary checking in the server side app or just pass the info to your Thunkable app to decide what to do.
Although, at the end of the day, it will still require a lot of figuring out for how to implement this all in practiceāalso for iOS. Not afraid of trying things out myself, but Iām very much hoping that the updated IAP docs would cover these issues and offer at least one concrete example, from start to finish (including, for instance, setting up the Firebase-side of things), for how to build such a subscription service for Android as well as iOS. It just doesnāt make sense that weāre all figuring these things out piecemeal and on our own.
If you are doing a subscription, isnāt that what this block is for? If user has an active sub it will return the info. If they donāt have an active sub it wonāt return any data? If user got a refund in any way that would affect what this block returns?
One thing to note that this block name is confusing. From experience, this block returns nothing for One Time Payment and only for Subscription.
The other thing, again, it gives the purchase done by the app and does not give enough details.
Another issue, this block will not reflect purchases that are in a state of on hold, blocked, cancelled, paused, renewed, expired which will lead you to the same issue we are discussing.
Server Side App
This will show you how to start a GCP to retrieve subscription info.
There was an issue with that block that occurred after our upgrade to expo 43. The error has since been corrected! Sorry for any downtime this caused any of you!
