No, not via TestFlight. Just build and app and copy to iOS device with ‘Developer’ profile (not a wildcard profile). When developer profile is used the iap sandbox environment is used.
Ronald
Seems easier than I expected from all the documentation. Thanks … I assume I have to set up my consumable product types somewhere
Thanks all. Stepping out of conversation for a long while and just observation… leaving further discussion to the experienced,
Ronald, are you calling the finishTransiaction() API?
Yes, I do during purchase and restore
When I do a recover, in sanbox mode, I keep getting all transactions from the past.
Ronald
Rob,
Apple rejects my binary since I use this API. They claim I need to use production for recept verification. The give me this hint:
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead
Is this new corona SDK ready for production? When it does verify the receipt does it try production first en then sandbox, like apple suggests?
Ronald
Hi Ronald. You’re going to have to help me out a bit. What API are you using? Are you referring to the whole store.* API family?
How are you handling receipt validation?
Receipt validation is your responsibility. Our store.* API’s just return data to you.
Are you using the test plugin that I emailed you about? We’ve not gotten any feedback from you about it. If you’re using this plugin that we are asking you to help test, I can’t say if it’s production ready or not. It’s why we solicited feedback. If this is the case, please reply via the email that I sent.
Rob
The receipt verification step for auto renewing subscriptions is not, as far a I can see from any docs, included in the IAP plug in. You have to do it on your own to either the sandbox or production URL. Also, I’m not sure the error code they give back is actually accurate LOL. Better to listen for error 21007.
I am using the API you emailed about. I did give feedback, I do receive the info I asked for. In sanbox mode this plugin works for me.
Now I run into problems with apple review. They reject. My app hangs forever. And according to apple I need to use production app store for receipt validation. And if I am correct the plugin, you emailed about, does the receipt validation for me.
So what I want to know, does the new plugin use production store URL https://buy.itunes.apple.com/verifyReceipt first to validate the receipt? Or does the plugin always use https://sandbox.itunes.apple.com/verifyReceipt for receipt validation?
Apple suggest to always first try production url. And if it fails with an error telling you are in sanbox mode, then use the sanbox url.
Ronald
I didn’t see any email responses from you.
I’ll share this with Engineering.
Rob
Sorry for that. I only gave feedback in this topic. I did not realize email feedback was preferred.
Ronald
Ah I see that feedback now. the plugin isn’t public, which is why I emailed testers instead of inviting people here to just use it. Anyway, I’ve asked the engineer to look at this thread.
Rob
Having just gotten through the auto renew subscription process with apple, I can tell you that the receipt validation (has the subscription lapsed, is the user able to restore an active subscription on a new device) is the most pain in the behind element, and I think that EVERYONE is likely to run into the rejection you encountered the first time through because it’s just not clear in any documentation that you have to prepare for a sandbox account to submit with a Distribution profile. What Rob is saying in this thread, ronald14, is that validation is not included in the IAP plugin, either the currently released or the beta.
Hello. Thank you for your feedback! Thing is “store.receiptDecrypted()” does not do any network requests. It follows Apple’s documentationon how to verify receipts locally, without use of Apple’s servers. Can you provide what exact response of apple reviewers was?
Hi vlads,
Thanks for reaching out. The exact message of first reject was:
Guideline 2.1 - Performance - App Completeness
We found that your in-app purchase products exhibited one or more bugs when reviewed on iPad running iOS 12.1 on Wi-Fi.
Specifically, when we try to purchase the subscription the app keeps on loading indefinitely and doesn’t finalize the purchase.
Next Steps
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead.
Resources
You can learn more about how to test in-app purchase products in your development sandbox environment in App Store Connect Developer Help.
For more information on receipt validation, please see What url should I use to verify my receipt? in the In-App Purchase FAQ.
Learn how to generate a receipt validation code in App Store Connect Developer Help.
Please see attached screenshot for details.
I responded that this code was tested good and never hang in sanbox mode. I resubmitted the same binary again and asked them to test again. They did. The next reject was:
Guideline 2.1 - Performance - App Completeness
We still found that your in-app purchase products exhibited one or more bugs when reviewed on iPhone and iPad running iOS 12.1 on Wi-Fi.
Specifically, when we try to purchase the subscription the app keeps on loading indefinitely and doesn’t finalize the purchase. We have tried on several devices
Next Steps
When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code “Sandbox receipt used in production,” you should validate against the test environment instead.
Resources
You can learn more about how to test in-app purchase products in your development sandbox environment in App Store Connect Developer Help.
For more information on receipt validation, please see What url should I use to verify my receipt? in the In-App Purchase FAQ.
Learn how to generate a receipt validation code in App Store Connect Developer Help.
Please see attached screenshot for details.
They claimed to have tested with iPhone and iPad. The screenshot they showed me was the activity indicator.
I did load the same binary apple used, via testflight. When I tested the inApp purchase it did not hang, it just works.
It is good to know you decrypt receipts locally. Is it possible that local sandbox verification and production verification needs a different approach?
I am kind of clueless why it hangs during apple’s review process.
Ronald
This is tricky situation. I do not know what is going on, really. Also, I find it interesting that App hangs on activity indicator.
Do you invoke it? I’m not sure what the workflow of purchasing a subscription should be, I tested it only via testflight as well.
Not sure where it can fail. Also, I find it weird that it hangs.
I do invoke native.setActivityIndicator(true) when the ‘Buy’ button is pressed. But at the first storelistener event I remove the indicator, without checking the transaction state.
The app was approved with the public ‘store’ API. With that version I also activated the indicator.
Tomorrow I can test what happens if I do not invoke the indictor with none public store replacement API. I do not remember the reason any more why I did put it there, for the ‘store’ API
Earlier this day I submitted the app again with the public ‘store’ API. I wonder what happens.
Ronald
By the way, try not to use both stores, if you do. Calling store.init on built-in store may cause some confusion.
Thanks for heads up. I did not do that. I will not try that in the future. 
Ronald
vlads,
I just upgraded my iPhone from 12.0? to 12.1. And I have the same problem apple is having. I updated Corona to recent daily (2018.11.06/3428) no difference. Same problem.
When I start my app and go to ‘buy subscription’ I need to wait almost 60 seconds before I receive the password popup. If I use the public store API. I receive the password popup within seconds.
If I start my app, wait 40 seconds and then start the buy action. I only need to wait 20 seconds before password popup. If I start and wait 60 seconds, it is almost instant.
my store.init is called right after startup. Since this is about subscriptions I always need to check the listener for events. For testing purposes I moved the store.init to the inApp purchase screen. When I start the app, wait 60 seconds and go to inApp screen, the store.init is called. If I then press ‘buy’ I need to wait again 60 seconds.
My conclusion after calling store.init I need to wait 60 seconds before I can use the store.purchase function. On iOS 12.0? I never noticed the 60 second delay.
PS The public store API does not have this problem and is working correct on iOS 12.1
Ronald
This is most weird because purchase API is literally same code in plugin and in core… Btw, you can use “plugin.receipt*” APIs in combination with built-in APIs.
(just don’t mix & match store.purchase/init/finishTransaciton and plugin.purchase/init/finishTransaciton).
Receipt APIs do not rely on init at all.