I'm implementing Auto-Renewal In app Purchase.I have a few questions Please clarify.
Really appreciate your help.
1.user1 make purchase a plan which is 30 days plan with device1 with his iTunes account and User 2 makes purchase another plan which is 60 days plan with device 2 with his iTunes account, what happens if user1 logged into device2 but device2 still have user2 iTunes account.if i restore purchase or receipt validation in device 2 i'll get User 2 purchase as auto-renewals will work with iTunes Account.
how we can make sure that user1 should get 30 days plan only not 60 days plan.
Thanks in Advance
You can pass your user's login name with the purchase and restore requests to allow Apple to improve fraud detection, but that will not actually prevent the purchase or restoration (whether fraudulent or just not what you intended).
(And thus with hindsight not an answer but leaving this here for reference - see comments.)
For example restoreCompletedTransactions(withApplicationUsername:)
See this SO answer for more details.
And this Apple Developer forum conversation for why it will not actually prevent purchase/restore by the 'wrong' user.
Related
Apple rejected my app with an :
Guideline 2.1 - Information Needed
We have started the review of your app, but we are not able to continue because we need an expired demo account to fully assess the subscription feature.
Next Steps
To help us proceed with the review of your app, please provide us with a link to a demo account in the App Review Information section of App Store Connect and reply to this message in Resolution Center.
I really don’t understand what kind of demo account they want from me. There are no any login screens in the application. Active subscription needed to access pdf share function.
Should I give them a test sandbox account with which we tested the subscriptions or something else?
TL;DR
You have your premium feature (features that can be accessed only with your subscription) available for non subscripted users, so they are asking you for expired account to check what happens if they don't have subscription.
Long story
We had subscription which was giving access to training videos for our users inside app. Someday we realized that we want to make this feature free and did it through our backend without releasing the app. So, the next review we've got the same reject:
Guideline 2.1 - Information Needed
We have started the review of your app, but we are not able to
continue because we need an expired demo account to fully assess the
subscription feature.
Next Steps
To help us proceed with the review of your app, please provide us with
a link to a demo account in the App Review Information section of App
Store Connect and reply to this message in Resolution Center.
After struggling around we've revealed that the problem is that Apple App Review team couldn't test the case where a user DOESN'T have subscription and CAN'T access our premium online training videos. I guess they get confused and asked as to share with them an expired demo account, so they can test this case.
At the end of the day, we've removed our subscription properly from App Store Connect and got our app passed through review. Therefore, I think you have your premium feature (features that can be accessed only with your subscription) available for non subscripted users, so they are asking you for an expired account to check what happens if they don't have subscription.
We have a app with a auto renewable IAP for which we offer a initial trial period to the user and charge once the trial period has expired. Our app maintains user account management(user login) and all features (including the IAP) are accessible only when the user is logged in.
There are two scenarios to consider:
Case 1: A new user(app user) opts to purchase the subscription for trial period on a device where she's logged in with her apple id. She later(post expiry of the trial period) installs the app on another device and signs up with a different app account but uses the same Apple Id. Since Apple Ids are opaque to the app, the app has no way to know that this user has already purchased trial, so the app UI presents them an option to start with a trial period. Since the Apple Id used is same, the user will be charged.
Although, this scenario is rare and can be justified on the pretext that the same Apple Id is used so the user is supposed to be charged, but it is fallacious on part of the app to suggest that trial period is available for the new app user(different login id)
Also, the user might not be intentionally doing it to avail a second trial period, but might have forgotten about the previous purchase and may use an alternate email next time they sign up.
How do you prevent the user to be charged if they have already used up the trial for the same Apple ID, or if there's a way to know if the current user(Apple ID user) has already made this purchase in the past, so that you do not show them trial option anymore. Would restore purchases help in that regard?
Case 2: The same app user may intentionally change the apple id on the new/same device to avail multiple trials. While your app will detect the user has already purchased the trial, you may choose to let the user not show the subscription purchasing UI but if you do the purchase workflow on part of Apple would still consider it to be trial period(new apple id) and not remit you the payment for the same.
How do you circumvent these conditions or if there's a flaw in my understanding where these situations would not occur at all.
For case 1: maybe the following may work, but not sure:
Whenever there's a new login to the app, the app should either refresh receipt or ask to restore transactions to the user(this can be frustrating for actual first time users) and the receipt validation should be performed to check if the user had previous purchase and if the transaction id is linked to some previous user. This is basically a kind of self managed restore. But still in this case, the new user will not be able to get the trial period, you can just prompt that the current apple id is already used for trial.
Please suggest if my understanding is correct.
In apple's document, it says developer can use the applicationusername to Detecting Irregular Activity，but i don't know how to use it.The document just says hash a userId,but how can i detect the irrgular activity? Does the apple's server have a server API to notify me ?
Here the link:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/RequestPayment.html#//apple_ref/doc/uid/TP40008267-CH4-SW6
Let's day your app uses an account system so each user has an identifier (email, username etc) which we refer as appId here and the app store login as appleId
Scenario:
Say user purchased a subscription with a trial period (txn123) with appId usr123 having appleId appl123
Later she unsubscribed the subscription.
After few months she changed the AppleID for some reason.
Again she wants to purchase the subscription.
She will login into the app using same appId, usr123.
As she already has used trial with that appId, your app will recognise her, and will show buy button to her.
When she will click on the Buy button, Apple UI will show that she is eligible for Trial, and will be charged after 7 days.
If you had passed the applicationUserName field in the payment(payment object) in the both the transaction user makes, apple will recognise that and may take a remedial action (like actually charging the user instead of offering a second trial period).
At this point I am not sure, how Apple is going to inform your app/ecosystem about this irregular activity. I have not tested this scenario myself as yet, will update the answer once I have done so.
Several things may happen:
Apple declines the second purchase because it detects the irregular activity of the same user purchasing the trial period again. But how would Apple know if the user is intentionally trying to make the purchase now after trial has expired. Anyways, apple can say that this user seems to be associated with some other apple id also which has made a purchase in the past, thus not allowing the transaction with the pair.
Apple may actually charge the user, since they are trying to buy after a trial but in this case Apple will be offering a Apple Id user without a trial period in their name.
Apple may allow the transaction with trial period offering and may resolve this through other/offline channel.
My app got rejected because of restore button on non-renewing in app purchase. Do i have to remove restore button ? If i have to do so then how user will restore his purchases.Please help.
Non-renewing subscriptions are consumable. Therefore they cannot be restored. A restore button therefore makes no sense. You also need some kind of authentication/login system for the user. (See below for detailed explanations.)
Sources:
consumable vs. non-consumable in app purchases
non-renewing subscriptions
Update from WWDC2017: In Session #303 App Store Engineer Pete Hare explains at 3:00 that a non-renewing-subscription can be seen as "a consumable product with an expiry date on it"
There has been some debates in the comments wether non-renewing subscriptions are consumable or not, so I want to say something about it. "Consumable" means that you can consume them multiple times. Like "30 minutes of talking" in a voice-over-IP telephony application. On the other hand, there are non-consumables that you can buy only once. Like when you unlock all levels in a game app. You buy it once, and when you reset the device and redownload the app, you should be able to restore the purchase, so that you don't have to pay twice to unlock all levels. Furthermore, if you don't tap the restore-button in this case but just buy the "unlock all levels" package again, it works, but you will not be charged by apple a second time. That's why it is called non-consumable. It's some kind of metapher. An apple is "consumable". Once it is consumed, it is gone. A chair is non-consumable. You have it as long as you don't destroy it or give it away.
So, it makes sense to regard a non-renewing subscription as non-consumable. If you buy it a second time, you shouldn't pay twice, you should just use the old subscription you already have. If you reset the device, you should be able to restore the subscription once you re-download the app. The restoration is just not done by Apple but by the app itself.
I still regard non-renewing subscriptions as consumable though. I use a simple definition of consumable vs. non-consumable: An in-app-purchase is consumable, when, from the point of view of the StoreKit API, it can be purchased multiple times in the same week by the same user. All consumable IAP-items cannot be restored through the StoreKit. All non-consumable IAP-items can be restored through the StoreKit.
So, the developer is himself responsible for restoring the in-app-purchase of a non-renewing subscription, right? No, sorry. How would the app restore the in-app-purchase of a non-renewing subscription? Suppose I have an iPod and I subscribe to 1 month of listening to the Foo-radio. Now I want to also listen to the Foo-Radio on my iPad. Soo, I install the Foo-App on my iPad and tap the "restore" button. Well... what is the "restore" button supposed to do? How can it know if I already have purchased a "Foo"-subscription or not, and how long it will still be valid? Answer: it can not. This approach does not work.
In order for a non-renewing subscription to work, you have to login the user first, to tie the subscription to some online account. Username/Password, Open-ID, Login via Gmail, Facebook, etc. all would work. Then, when the user purchases an n-r subscription you have to store the fact that he subscribed on some server and link it to his account on the server. You also have to prevent the user from buying the n-r subscription when he is not already logged in. Let's continue with my iPod/iPad-example above. I download the app on my iPad, I login with Facebook, and voila, I can use the "Foo"-subscription now. There is no need for a "restore" button, because the app should check at login-time which subscriptions the user has.
There will be some additional problems to deal with. (1) For example, nothing prevents the user from logging in into 200 devices. Here the problem is not a user with 200 devices, but a university with 1000 students where 180 students share the same account. (2) If the server crashes, some people will probably lose their subscriptions. Problem (1) can potentially lead to decreased income. Problem (2) can lead to angry and unhappy customers.
From Apple: "Non-renewable subscriptions. Subscriptions that don’t involve delivering episodic content. Examples include access to a database of historic photos or a collection of flight maps. It’s your app’s responsibility to make the subscription available on all of the user’s devices and to let users restore the purchase. This product type is often used when your users already have an account on your server that you can use to identify them when restoring content. Expiration and the duration of the subscription are also left to your app (or your server) to implement and enforce." [Italics and bold added] https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
Apple Reviewer's current-similar response about Non-Renewing Subscriptions "Your app offers Non-Renewing Subscriptions and this purchasability type must have its own restoring function - if you have removed it please re-implement it. Furthermore, your app must also offer a function, such as account creation, such that purchases can be tracked across all of a user's devices. Please implement a login feature as well as a restore mechanism prior to resubmitting your revised binary for review."
I want to implement In app Purchase and i am new to this:
I have to give free subscription for three days, after that i will sale day pass like $1 for one day. and after completion of that 1 day user will buy the next day pass.
so i studied a lot and found that i have to create non renewable in app purchase. (please suggest if i am wrong)
I have created an app where users can sign up.
Is it possible to provide the subscription according to my app users not according to Apple ID (itunes purchase ID).
For example my app users are:
UserA
userB
userC
and i am purchasing with testuserA (itunes or apple Id).
so here can i purchase three time for these three users.
please suggest i am having fear of app rejection.
Thanks in Advance !!