vlads,
I can confirm if I use built-in API for init and purchase and use the plugin to for receiptDecrypted() I get the wanted receipt and all in seconds. This is great.
Is there a way to get the plugin working in iOS 12.1? So eventually this plugin can replace the built-in one? I don’t mind doing some extra testing.
Ronald
I’m eagerly following this topic. Subscriptions are becoming a huge factor in app monetization with Google and Apple pushing it, and I feel Corona isn’t focusing enough on it. I understand it’s technically possible with the current store plug-ins, but it’s quite difficult to implement with little in the way of guidance, documentation, best practices, etc.
Hopefully with the release of this updated plugin we can get a better guide and documentation on how to successfully implement basic subscriptions on Apple/Google.
Ronald,
Awhile ago, I tried to get IAP Subscriptions to work, I also ran into a dead end.
I hope Rob can clarify if Subscriptions are supported by Corona and if not, if they ever will be. I believe Apple is trying to get developers to steer in this direction.
Nail
I’ll ask
Thank you Rob,
I really hope a solution can made to get missing fields.
Ronald
I’ve been putting together iOS IAP subscription for a client, the subscription receipt is coming through fine, and the validation URL provides all relevant info on subscription status when passed the receipt. Kind of messy and multi stepped, but definitely possible from within Corona.
Thank you. I will try this validation URL method.
Ronald
I used this very awesome script created by Corona user Satheesh to pass up the receipt and return the validation info: https://github.com/SatheeshJM/Auto-Renewable-In-App-Purchase-Validation-using-Corona-SDK/blob/master/validate.lua
Hey Kevin have you used that script lately? Looks to not have been updated in about 7 years… just wanted to make sure it works before attempting to use it.
Using it now 
We have created a new IAP plugin for Apple OS’s (iOS, tvOS, macOS) that should be a drop-in for store.* but it adds some new API’s to help with receipt management which could help with subscriptions.
Reply here if you want to test and I’ll email you instructions.
Thanks
Rob
I’d be happy to test it out!
Thank you Rob,
I would like to test this. Can you send me the instructions?
Ronald
Emails sent.
I am interested to see what is involved here. Can this be tested via just the Corona simulator ?
@IBMHurskley1964, I’m not finding the email you’re using for the forums in our developer database. I need an email address that you’re logged into Corona with. Please email me at devrel AT coronalabs DOT com with your logged in email.
Rob
Maybe new change not updated yet… Will email you . thanks
I’ll test it also.
Looks like I have the links now and all emails working. I am now realising I am missing some basic knowledge on how I would test this. I assume this would be via Apple ‘TestFlight’. Any pointers would be appreciated as testing here thus far is fairly straight forward without any access to Store prior to publishing… UPDATE…
I have found what I need I think here… https://developer.apple.com/library/archive/technotes/tn2259/_index.html
I just implemented this new iap api. I can now easily see the required ‘expires_date’ of my subscription.
I have one note!
When I buy a subscription and request the receipt, with store.receiptDecrypted(). I see in the recept’s field ‘in_app’ the complete history of all the subscriptions i bought in the past. In my case I see 60 entries (in the sanbox environment). The last entry is the one I need. I kind of expected just 1 entry in ‘in_app’ field.
But when I do a restore, I get all 60 transaction in restore state. All these 60 transaction again have 60 entries in the ‘in_app’ field, if I request the receipt. This seems a bit too much to me. But good usable. I just need the last entry in ‘in_app’ from the last transaction.
is this intended behavior?
I kind of remember from many years ago on x-code. I also saw much redundant data when working with receipts and restores. But I am not sure anymore.