MobileIAP.Transaction got deprecated from r350 causing issues

[UpToSix]

MobileIAP.Transaction - got deprecated from r350 causing issues

For consummable purchase, 'on purchase success', we use to get the MobileIAP.transaction to store in our remote server. But from r350, this was no more available. So, the upgrade stopped working as we are no more getting the MobileIAP.transaction.

Strange thing is how a stable build deprecates such important feature? Further, the compilation also does not provide an error that MobileIAP.transaction is not supported. Thsi causes huge issues for app developers like us and then to our customers.

Attach a .c3p

Steps to reproduce

1. Laund C3 with build stable C3 R344
2. Open a new project
3. Use object "JSON" and "Mobile IAP"
4. Go to event sheet
5. Add event "On any purchase success" --> Action : Json Parse - MobileIAP.Transaction >> You wil be able to do this

Observed result

But if you go to build C3 R350, this is no more supported. But the build created with C3 R344 willl open in C3 R350 with out issues, and also complie and export without issues.

Expected result

I expect that the MobileIAP.Transaction expression is still available with latest releases.

More details

Affected browsers/platforms:

First affected release:

System details

View details

PASTE HERE

[AshleyScirra]

For reference this appears to have already been discussed in this comment. If all you need is the transaction ID, then we will resolve this by adding a new expression to retrieve that; as noted in the comments we most likely won't bring back an expression that returns a block of raw JSON data, as it's difficult to support long term.

[UpToSix]

Thanks so much! Kindly bring this for "Purchase success ( consummable and non-consummable)" and "Restore success(for non consummable)", so that we get the transaction ID, for both android and iOS.

Thanks and Best regards, @.***

On Tue, Oct 3, 2023 at 6:53 PM Ashley (Scirra) @.***> wrote:

For reference this appears to have already been discussed in this comment https://www.construct.net/en/comments/63223. If all you need is the transaction ID, then we will resolve this by adding a new expression to retrieve that; as noted in the comments we most likely won't bring back an expression that returns a block of raw JSON data, as it's difficult to support long term.

— Reply to this email directly, view it on GitHub https://github.com/Scirra/Construct-bugs/issues/7436#issuecomment-1744971174, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASXC5EYP5WMHDGMGZPKDJLDX5QGULAVCNFSM6AAAAAA5PTOST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUHE3TCMJXGQ . You are receiving this because you authored the thread.Message ID: @.***>

[UpToSix]

Hi Sir,

May I know when you will fix this issue? Also, I wanted to bring to your notice that if you are not giving the entire transaction receipt JSON to the app back on purchase or restore success, it will be very difficult to do validations for consumable purchase. I'll survive with the ID for now, but just wanted to let you know the importance of the transaction ID.

Thanks and Best regards, @.***

On Tue, Oct 3, 2023 at 6:57 PM Dev Up To Six @.***> wrote:

Thanks so much! Kindly bring this for "Purchase success ( consummable and non-consummable)" and "Restore success(for non consummable)", so that we get the transaction ID, for both android and iOS.

Thanks and Best regards, @.***

On Tue, Oct 3, 2023 at 6:53 PM Ashley (Scirra) @.***> wrote:

For reference this appears to have already been discussed in this comment https://www.construct.net/en/comments/63223. If all you need is the transaction ID, then we will resolve this by adding a new expression to retrieve that; as noted in the comments we most likely won't bring back an expression that returns a block of raw JSON data, as it's difficult to support long term.

— Reply to this email directly, view it on GitHub https://github.com/Scirra/Construct-bugs/issues/7436#issuecomment-1744971174, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASXC5EYP5WMHDGMGZPKDJLDX5QGULAVCNFSM6AAAAAA5PTOST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBUHE3TCMJXGQ . You are receiving this because you authored the thread.Message ID: @.***>

[AshleyScirra]

As per the bug report guidelines, please allow at least a few weeks for issues to be reviewed. We are a small team and there is always a significant number of issues incoming too.

[AshleyScirra]

@UpToSix - I have looked in to this, but it seems to me that you are using the transaction ID to verify transactions on a server. In that case - why not use the 'Validator URL' property? That is designed for this purpose: you can get it to send your server all the JSON data of the transaction, which includes the transaction ID, specifically for your server to validate, and then the IAP plugin automatically also uses that to verify transactions. If you're trying to build your own separate service that reads the transaction ID from the IAP plugin and then send it to your own server for validation, why not use the built-in way? That's already possible and does not need any new features to be added to the IAP plugin.

[UpToSix]

Hi Sir,

1. We are a small company.
2. Apple and Android has many GDPR complication and we do not collect any user ID. The transaction ID acts as an unique ID
3. This seems to be an incompatible change.

If you can give us the transaction ID please, that will help.

Best regards, Sumanta

Thanks and Best regards, @.***

On Mon, Oct 16, 2023 at 7:37 PM Ashley (Scirra) @.***> wrote:

@UpToSix https://github.com/UpToSix - I have looked in to this, but it seems to me that you are using the transaction ID to verify transactions on a server. In that case - why not use the 'Validator URL' property? That is designed for this purpose: you can get it to send your server all the JSON data of the transaction, which includes the transaction ID, specifically for your server to validate, and then the IAP plugin automatically also uses that to verify transactions. If you're trying to build your own separate service that reads the transaction ID from the IAP plugin and then send it to your own server for validation, why not use the built-in way? That's already possible and does not need any new features to be added to the IAP plugin.

— Reply to this email directly, view it on GitHub https://github.com/Scirra/Construct-bugs/issues/7436#issuecomment-1764562083, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASXC5E765ARVMXUOQ2SUPGDX7U5SPAVCNFSM6AAAAAA5PTOST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUGU3DEMBYGM . You are receiving this because you were mentioned.Message ID: @.***>

[AshleyScirra]

I don't think GDPR has anything to do with it - if you were previously using the 'Transaction' expression to send JSON data to a server for validation, that's exactly what the built-in validator feature does for you. So I suspect there was in fact a built-in feature that covers this all along.

Nevertheless I have added an 'On transaction finished' trigger and 'TransactionID' expression (which is set in that trigger) for the next beta.

[UpToSix]

Thank you so much. We just take this transaction ID to generate an unique ID for the user. Thanks and Best regards, @.***

On Mon, Oct 16, 2023 at 10:08 PM Ashley (Scirra) @.***> wrote:

I don't think GDPR has anything to do with it - if you were previously using the 'Transaction' expression to send JSON data to a server for validation, that's exactly what the built-in validator feature does for you. So I suspect there was in fact a built-in feature that covers this all along.

Nevertheless I have added an 'On transaction finished' trigger and 'TransactionID' expression (which is set in that trigger) for the next beta.

— Reply to this email directly, view it on GitHub https://github.com/Scirra/Construct-bugs/issues/7436#issuecomment-1764866046, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASXC5EZQIUUP5QDDED7KJ6TX7VPIDAVCNFSM6AAAAAA5PTOST6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUHA3DMMBUGY . You are receiving this because you were mentioned.Message ID: @.***>