In an effort to ensure all apps are running as expected, please take note of. these updates to the IAP blocks. Specifically regarding how the purchaseObject information is passed in the Green block in the improvements below. If you do not align your project with the indicated change and push an update after today [June 8 2022] your IAP workflows will not execute as expected.
Bug Fixes
“then do” section of blocks is not firing
– fixed
Improvements
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
What do you mean that Android purchases and subscriptions are automatically acknowledged? Do we no longer need to include the blocks for acknowledging Android purchases and subscriptions?
You don’t need to acknowledge android purchases anymore! You should always be prepared to verify that a purchase is still valid for ongoing purposes. For example, during a subscription, you may want to verify that it’s still valid once a week or bi-monthly. You don’t have to do this but it’s recommended.
I manage all of my purchases on Xano now, so I do a simple API call to the backend, it does it’s magic, then returns a list of valid non-consumable purchases, remaining consumables, and valid subscriptions.
That’s good news! Just to be clear before I delete the wrong blocks, do I remove #1 and #2 in the image below from your old documentation examples? And only the group of blocks in #3 is really needed now?
doing so allows you to quickly query what a users current/active purchase information. as well as provide them and yourself with purchase histories. makes restoring purchases a breeze! this way you only query your table and restore the purchases.
then you can use the endpoint found. here to regularly check for voided/refunded purchases and update the users entry in your users table if/when needed.
you can check a subscription. directly using the endpoint found here but purchases cannot be checked in the same fashion. you must query each purchase individually for the user. having a table will all their purchases allows you to query the table for the users purchases and then loop over those purchases to verify they are still active.
This is good info, Jared. Thank you for sharing this method. I am being stretched out of my longtime comfort zone inside Realtime db. What are you using in the screenshots above? Is that airtable?
BUT you could accomplish the same in firebase