Some of you noticed over the weekend the ‘then do’ section of. these blocks not firing. While working on improvements to the Android purchase experience, some unintended effects took place. Namely, the “then do” block isn’t firing.
With that, please do not push updates for projects with IAP until we have resolved the issue. This will break your IAP flow and purchases will likely be reverted for Android apps, potentially iOS too.
We are actively working on this, and hopefully will have more info by the end of today/tomorrow.
ok, thanks for creating the thread, I’ll be on the lookout for the update, I don’t know if it will help you, but we managed to identify this in the first days of June.
true/false socket on the one-time purchase block for android purchases
green purchase block previously returned a list like this
"originalOrderId": "",
"acknowledged": false,
"productId": "consumeable",
"transactionReceipt": "LongString", (iOS only)//this is the value you pass to your verification call
"transactionID": "shortString", (
"purchaseState": 1,
"orderId": "2000000003481980", //this is a value you can use to store transaction data, for example in the realtime database
"originalPurchaseTime": 0,
"purchaseTime": 1646316547000 //this should not be used to calculate a date at which a subscription expires. you should do that through the verification calls.
}]
now the block return only a single item like this
{
"originalOrderId": "",
"acknowledged": false,
"productId": "consumeable",
"transactionReceipt": "LongString", (iOS only)//this is the value you pass to your verification call
"transactionID": "shortString", (
"purchaseState": 1,
"orderId": "2000000003481980", //this is a value you can use to store transaction data, for example in the realtime database
"originalPurchaseTime": 0,
"purchaseTime": 1646316547000 //this should not be used to calculate a date at which a subscription expires. you should do that through the verification calls.
}
a subtle but breaking change. you need to update your logic such that you don’t request an item from a list but just use the purchaseObject passed by the block
Nice, I guess that only affects the logic change to those who have in-app purchases on android and those who have the logic for purchases on IOS remains unchanged.
I have confirmed this is working on Android and my internal build. I have it in review for production release. Thank you for the swift fix Thunkable team and @jared for his support.
@jared In the past two weeks has there been any changes to IAP purchase and restore blocks or server code that would cause my blocks or xano from not working properly?
AFAIK, there has been no changes to the underlying code that support in app purchases at all.
If you are experiencing issues, would you mind starting a new thread to keep things less confusing and so others can keep up-to-date as this thread has already been marked resolved.
Can you please outline what issues you’re experiencing and reproducible steps I can take on my end to experience this issue. I published towards the end of last week and did not experience any issues with iap.