I have set up and tested In-App purchases successfully in sandbox environment. But I have a problem:
In actual In-App purchases, I can turn off auto-renewing subscriptings on an iOS device by following this link http://support.apple.com/kb/HT4098?viewlocale=en_US&locale=en_US
I wonder how I can do the same thing in sandbox environment. I thought we have to sign in App Store to turn off auto-renewing subscriptings, but Test User Account can not sign in App Store. So I think we can not turn off auto-renewing subscriptings in sandbox environment.
If so, I also need a simple explanation why we can not.
Thanks for reading and any help or direction will be appreciated.
Yes. That was my experience as well: that test users can't access the settings page to manage subscriptions in their phone. I think Apple just didn't bother programming this knowing that sandbox subscriptions will just cancel after five repetitions anyway. That automatic cancellation is probably your way to test the scenario where a user cancelled through the App Store.
Related
IAP (Subscriptions) can be purchased from the App Store through IAP Promotions or Offer Codes. In the case where the app is not installed yet, I was wondering how to activate the purchase afterwards.
If the subscription was activated through the App Store or an Offer Code was redeemed in the App Store, is it added to the receipt automatically? I guess so, otherwise I would have to restore the purchase, which I think is wrong.
Since I can not test this use cases from a sandbox account, would be very nice to know about the behaviour in advance. Thanks!
Is it possible to hack iOS in-app purchase if someone know the product identifier with a jailbroken device ?
It seems that someone is getting my app in-app purchase items for free. I accdiently put all my in-app purchase identifiers in plist and bundled it. So its possible for a hacker to take ipa, extract it and see the plist contents.
My question is, is it really possible to hack in-app purchase flow with a jailbroken device ?
Another interesting fact is that I have the in-app purchase delegate onPurchaseSuccess() function defined in one of my classes. I am getting the URL request for this on the server side but there is no in-app purchase or sales in iTunes. Also, I have Google analytics logged inside this function which also failed to log anything in the analytics admin portal. Analytics for other events are properly logged. How could it be possible for a hacker to fire a URL request for the in-app purchase from this function and stop Google analytics tracking feature? I have no idea what's happening.
If you check for in app purchases in your app, then a jailbroken app can obviously do whatever it likes, including making purchases. If your in app purchases just unlock some functionality that is present in your app, a jailbroken app can be hacked to use that functionality.
If you send the receipt to your server, and your server checks the receipt with Apple, and the purchase then enables functionality on the server, then it can't be hacked without hacking your server.
Putting the purchase keys into a plist doesn't make much difference, because at some point your app needs the purchase keys, and at that point it can be hacked on a jailbroken phone.
I am implementing auto-renewable subscriptions in iOS and want to be able to test the scenario where the user cancels the subscription but I am unable to do so because when I try to manage subscriptions with the sandbox account the app store wants me to associate a payment method with the sandbox account but in my experience once I do that the sandbox account is no longer valid.
Is it even possible to test cancellations or do I just blindly code for cancellations? I have search high and low and have not found anyone who has been able to manage subscriptions in a sandboxed environment.
I realized today that I was thinking about this all wrong and I can see why its not as necessary to be able to manage subscriptions. I was thinking that the 'Cancellation Date' field would reflect when a user cancel's (or really just opts out of auto-renewing) their subscription. But I was mistaken this field is only for the times when a user contacts Apple Support and requests to cancel early and receive some sort of a refund, and this is not something that is managed directly by a user.
Have you tried using a TestFlight build? You can do sandbox IAP testing via TestFlight with a "normal" iTunes account that has a payment method. I would assume that means you could try out canceling the subscription.
In the server side, I'm doing something like:
if(tryIsRealAccount or tryIsSandBoxAccount)
{buy...}
It's a MUST when my app is reviewing by Apple. But should I close sandBox-trying after review?
It may be a silly question, but I really wanna make sure. Thank you!
There isn't any reason to close testing the sandbox - you'll only need to turn it on again next time you submit an app for review (because Apple's reviewers use the sandbox).
Other developers won't be able to use sandbox users to purchase items in your production apps. I just tested it in a production app with my test user credentials, and it doesn't work without payment information:
I have an app in which, content is uploaded on weekly basis and hence using Auto-renewing subscriptions is the best option. Once the user subscribes for a weekly subscription, he is charged on weekly basis until he opts out.
I researched on how to unsubscribe and I read there is no api call or no other way to implement this from the app. The user has to manually turn it off from iTunes & App Store. Is that true ?
Question: I am testing with a sandbox account so is there a way to Manage subscriptions i.e stop subscription to that particular app? I want to turn off the weekly subscription and then try again to turn it on from app. I could not turn it off from device. So is it because I am using sandbox account?
Please reply! Thanks in advance!