Background
I have an application that supports in-app purchase with Apple subscription (in particular auto-renewable plans).
Using the WWDC 2016 slides material, in the Manage Subscription page, (inside iTunes & App Store -> View my Apple ID), we have this:
in which the user is allowed to change the current subscription plan (and also to cancel it). So far, so good.
Case scenario
I would like to simulate the scenario of a user changing account (or cancelling the current subscription) from the Manage Subscriptions page.
My issue (and possible solutions)
Thus, I am now facing the issue of testing the reported scenario.
It seems to conflict with Sandbox Account for testing purposes. In particular: if I try to login with the sandbox Apple ID into the iTunes Store & App Store page, I of course receive the message: iTunes Account creation not allowed (as reported in this question).
The most straight-forward solution seems the one reported in this thread (shortly: let the subscription plan auto-renew for 5 times with 5 minutes period, after which we should receive the 21006 error). Anyway, I am not sure that it could be applied to this case, since it seems only including the cancel my subscription case.
Another thread comes directly from the apple forum (this thread) but: (1) something is strange, i.e. the iTunes account creation not allowed error seems not to appear when logging into iTunes with sandbox accounts - while it happens to me systematically) and (2) even after logging in, the subscriptions are reported not to be shown.
I expect that everything works using a real Apple ID, but this is something I don't really want to do.
Conclusion (?) and question
So, finally :), my question. Is there a way to test the reported case scenario (or an equivalent one) without using a real apple ID, thus without triggering a real transaction? I don't really want to believe that the current sandbox testing mechanism does not include it.
Thanks in avance to all!
An iTunesConnect Sandbox test user account can test auto-renewing subscriptions but that account cannot login to iTunes and utilize the Manage Subscriptions.
Only Option
The only option I have seen being utilized is to essentially get your app fully approved for the app store (do not auto-release). Once approved, use a promo code to download and live test the Manage Subscription scenarios. If it all checks out, release the app. (I cant seem to find the link for this but will add it here if I come across it.)
Other Notes Testing Auto-Renewing Subscriptions
Duration times are shortened when test your auto-renewable subscriptions. Additionally, test subscriptions only auto-renew a maximum of six times.
Reference Link
~Emphasis is mine
1 week = 3 minutes
1 month = 5 minutes
2 months = 10 minutes
3 months = 15 minutes
6 months = 30 minutes
1 year = 1 hour
This thread has a response posted from an Apple Developer in regards to this situation. Link
Related
We are experiencing a very weird behavior when testing In-App-Purchases via TestFlight/Sandbox. The tooling used for the implementation in React Native is: Expo In App purchases
We have configured multiple renewable subscriptions as our offered products.
After a successful subscription purchase, almost all testers are experiencing a very rare interaction with the purchase modal, even happening when the app is in the background.
We are steadily trying to find what could be wrong with our implementation, but the fact that the modal is appearing randomly presenting the confirm purchase dialog multiple times, and with a random plan, we are a bit lost on the cause.
Especially because with the app in background mode, app code should not be executing/running since we don’t have background mode capabilities set up for that to work.
Is this by chance a wrong/known behavior of the Sandbox environment?
In any case, any clue or idea to re-orientate the efforts in that direction is very valuable at this point.
EDIT 1:
The modal appearing is the following one:
You can get this behavior if you test auto renewable subscriptions in a test environment (such as when launched from Xcode).
In order to make it easier to test the nature of auto renewable subscriptions, the renewal time has been shortened when in a test environment, so that 5 minutes in real time represents 1 month in subscription time, 1 hour in real time represents one year in subscription time and so on...
When in test mode, a subscription is renewed up to six times by default and then it will be allowed to expire. Since iOS 14, you can change some of these test parameters.
The reason you get these calls to your app in both foreground and in the background, is most likely because StoreKit tries to simulate calls that your app would normally receive whenever a subscription is renewed.
In a test environment, this often prompts the user to enter their account credentials, in order for iOS to be able to sync the subscription status with AppStore; so this behavior with password dialogs popping up every now and then, is not something your real users will normally experience from the actual release.
If you test a lot of different auto renewable subscriptions on one account, these password dialogs that pop up can be a real hassle, but they will eventually stop appearing once all your test subscriptions has expired.
You can read all about testing auto renewable subscriptions here:
https://help.apple.com/app-store-connect/#/dev7e89e149d
I work for a game developing company which releases at least one game a month. For our true fans we want to start providing a subscription to our games, so they can play all our games (on any platform) without constantly having to buy them.
The idea for iOS is to use the in-app auto-renewable subscription. This results into a receipt which we store in our backend. The backend can validate this receipt and provide the apps with information about the subscription of the user.
This system will solve a lot of problems: You can take the subscription in 1 game, and play all the games as well, on any device you like.
But now we come to the problem: After a month the receipt is not valid anymore, and we need to check in the iTunes store to see if the user still has a valid subscription.
My first idea was to use the "latest_receipt_info" field, to get the latest receipt and validate this. But according the documentation this feature should only be used for iOS 6 receipts:
"Only returned for iOS 6 style transaction receipts for auto-renewable
subscriptions."
source:
https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-
Even though I can actually still use this field with my brandnew iOS 10 receipt, I don't think it's smart to use it since it's deprecated.
(another source telling you shouldn't use it anymore: https://forums.developer.apple.com/message/156580#156580)
The advised solution of apple is to implement a SKPaymentTransactionObserver in the app. This will retrieve the latest receipt when it's available, and send this to the backend. Even though this is far from ideal, this could work... however:
This means the app has to be active to retrieve the latest receipt. And in our case it's very well possible a user takes a subscription in app1, and after a couple of days downloads app2, 3 and 4, but never uses app1 again. So in this case the latest receipt will never be fetched (because only the observer of app1 can access the receipt)
To fix this problem we should be able to fetch the receipts from this subscription from any app in our subscription group. But according the documentation on the apple site (https://developer.apple.com/app-store/subscriptions/ ) you can only access a subscription from 1 app, and you have to do the multiple app thing yourself:
You can offer auto-renewable
subscriptions to access multiple apps in your portfolio. Each app must
be approved to use auto-renewable in-app purchases and must be
published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent
auto-renewable in-app purchases in each app offered in the multi-app
subscription so that users can subscribe from any app. To avoid users
paying multiple times for the same offering, you are responsible for
verifying that they are subscribers in one of the apps before showing
any subscription options. To do this, consider maintaining an account
management system in which users create an account with your business
to sign in to each app.
So is there any way to do what we want, without forcing the user to go back to the app he used to purchase the subscription every month?
On the last WWDC we went to StoreKit labs and personally asked StoreKit evangelist about this. We were told that the 'latest_receipt_info' field return by iTunes validateReceipt endpoint is exactly what we are suppose to use in order to check if the subscription was renewed or not.
This is not going to be deprecated in the near future but they do have plans for adding some server-to-server communication that solve few of the problems we ran into:
Your server will be able to get notification from Apple regarding any subscription renewal, cancellation, downgrades etc.
In the latest_receipt_info returned by the validateReceipt endpoint few fields will be added, providing information like whether the subscription will be renewed after current one is expired, whether there was a problem charging the user's credit card etc.
Sources:
WWDC 2017 Session 303 - What's new in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit
due to the fact that Apple requires at least one auto-renewable subscription or one free subscription for a newsstand app, we changed all monthly subscriptions of our news app to auto-renewable ones while adding newsstand functionality.
When I try to buy one of these subscriptions on device #1 (e.g. my iPad) everything works fine. When I try to buy the same subscription on device #2 (e.g. my iPhone), I get a message from the Store Kit telling me that I am already a subscriber of this certain issue (which is ok as well) but afterwards the process is finished without having bought anything.
Checking the log shows, that the SKPaymentTransactionObserver delegate method paymentQueue:updatedTransactions: first gets a transaction for that product in the state 'SKPaymentTransactionStatePurchasing' (ok so far) followed by transaction in the state 'SKPaymentTransactionStateFailed'. Having a closer look on the transaction error code and message of the last transaction, the transaction error description says "Cannot connect to iTunes Store'. A second purchase of another product (bought the first time on the second device) works perfectly. Both purchases are done against the sandbox, does anybody has a hint how to address this problem.
Thanks for your help in advance
Michael
It shouldn't be possible to to purchase the same auto-renewing subscription on multiple devices, instead you should implement restore functionality, and restore on the second device. It's worth noting that the sandbox uses time compression for testing, so a 1 month subscription, will actually auto-renew every 5 minutes or so, and will only renew 5 times in a day. it's possible the original subscription has expired by the time you try to repurchase for the second time.
Often the sandbox error messages are not useful, the "Couldn't connect to iTunes" is not relevant.
I would suggest reading the whole of this page very carefully, as there are a lot of important details it's easy to miss. The bit about restoring purchases is here:
https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/MakingaPurchase/MakingaPurchase.html#//apple_ref/doc/uid/TP40008267-CH3-SW1
Best of luck
I am facing a strange behavior with In-App-Purchase in iOS while testing with sandbox. Few things I observed, Please make your comments where I am wrong.
I know sandbox has small time interval for subscriptions like 30 minutes for 6 month subscription. I am using subscription model, when I am trying to purchase same item multiple time, it allows. Is that OK ? As per my understanding, it should allow only once to purchase and in subsequent call, it should say "Already purchased".
When I am restoring my previous purchase. Storekit is calling updateTransations with large number of previous transactions. Don't know why it is returning these large amount like 100, 200 ,245, 360, 650 seems like Random in every restore.
Please make your comments. Thanks in advance.
Regards,
OP
Dear All,
As I did not get reply on this thread. We have done testing an make the app live, app is working fine. Here are my comments that might be helpful to others.
When testing with sandbox, since time interval is not same as live app. You get 5 minutes for 3 month subscription and so on, so once your subscription expire your subscription will be renewed. If you will make one more payment request if subscription is live, you will get popup for already purchased.
Apple sends a large number of transactions, we need to add condition by our own, so that we will identify the current transaction and will process that only, rest will be ignored.
Hope this will help you all.
Thanks,
Om
I've got auto-renewing subscriptions working in my app, and I have three terms users can pick from:
1 month
3 months
1 year
After they're purchased one subscription, which is set to auto-renew, is there a way to set a different tier for their auto-renew choice the next time their sub expires? For example, they're on a 1 year subscription right now, but they want to go monthly after it expires.
I know this can be done in Settings -> Store -> Apple ID -> Subscriptions, but that's kind of a pain to get to. And we can't even send them directly to the settings since Apple removed those preference URLs in 5.1.
So is there an API to do this?
Thanks.
If I understand your question the answer is yes. You can offer a new duration to a user before the auto-renewal of their next term. If they buy that new term, it will go into affect and be charged at the end of the current term. If they don't then they'll remain on their existing plan (or the subscription will end if they've turned off Auto in Settings).
ARS = Auto Renewing Subscriptions
NRS = Non Renewing Subscriptions
Side Note: If you haven't already submitted and you're not a magazine or newspaper your app may be rejected for using ARS. They may insist you use NRS. This isn't well-documented by Apple but it happened to me and to Marco Arment of Instapaper among others.
As a developer you can't control whether a user's ARS will auto renew or stop at the end of a term. Only the user can do that through the Settings app. The developer also can't see whether the user has turned off auto or not (you just have to wait and see if it renews). And as a developer you can't manually switch a user to a different plan. But you can offer them different durations for purchase that will go into affect at the end of their current term.
Yes, directing a user to the Settings app is frustrating and it's the only way for them to manage their ARS. The only thing you can do in the app is offer new time-intervals for purchase.
Manually-renewing subscriptions give you more power, as a developer.