I am implementing a digital magazine project for a client. Auto-renewable subscriptions for a period of 3/6/12 months have been included as a feature. My question is while using in-app purchase, is there any way for the server to map the user?? Anyway to identify a particular user is using it? I have done extensive research and know that apple doesn't allow the user's apple-id to be mapped?? Is there any other way to identify a particular user?
The problem arises for subscription. If an user has undertaken a subscription for let's say 3 months, then my app has to show DOWNLOAD button for all the 3 months instead of the regular BUY button. But when a new magazine is launched on to the storefront, how would the app know that this person is subscribed or not and convert the BUY to DOWNLOAD?
When a user buys a subscription, you should store the receipt on your server. This receipt, in a way, becomes your way to identify the user's account. Whenever you want to check the status of an account, send that receipt to iTunes for verification and it'll respond with the latest receipt for that subscription, along with the expiration date. Since you've made a note of which specific device that receipt came from, you can provide the proper UI to that user.
Now, if the user installs your app on a new device they can tap a Restore button that you've provided in your app. That button will call restoreCompletedTransactions which will send all the Auto-Renewing receipts for that user's Apple ID to the device.
Related
Im working on an app which will support subscribing to a premium version.
Whenever a user buys a subscription I can verify the receipt on my backend, persist important data and grant entitlement which is good.
However, when a user buys the subscription for the first time I rely on the Firebase User ID in order to query my DB.
When I receive App Store server notifications I query by the original_transaction_id.
Now comes the problem, I do not know whether a subscription can be bought initially outside of my app. (I only sell them in-app, but am not sure if apple provides a way to buy them outside of the app.).
If it is possible it would cause a problem.
Let's assume we are Netflix. The user created an account on our webpage and then downloaded the iOS app. Within the app he started a payed subscription by purchasing an auto-renewable iOS subscription.
The subscription is added to the user account on our webpage. Thus the user can access the paid content not only within the iOS App but also on our webpage from his SmartTV, etc.
The user can mange his account not only from within the iOS app but also directly on our webpage.
The iOS Subscription is not linked to the iOS app but the users Apple ID account. Deleting just the iOS app does not has any effect on the subscription at all. At the end of the subscription period the subscription would sill be auto-renewed and our server. Our server does not need an installed iOS to recognize the renewal (e.g. using Status Update Notifications or by polling the /verifyReceipt endpoint). Thus the user could still continue to access the payed content even if he does not use/install the iOS App any more. Is this correct?
But what happens if the users decides to delete his user account on our webpage and forgets to cancel the iOS subscription?
In assume the subscription would simple do the same as before and would auto-renew at the end of each subscription period. Since the user account on our server has been deleted the server does not recognize the renewal any more and the user simply pays for nothing. Is this correct?
Or is there any way the server can notify Apple to cancel the subscription?
Question 1: The iOS Subscription is not linked to the iOS app but the users Apple ID account. Deleting just the iOS app does not has any effect on the subscription at all. At the end of the subscription period the subscription would sill be auto-renewed and our server. Our server does not need an installed iOS to recognize the renewal (e.g. using Status Update Notifications or by polling the /verifyReceipt endpoint). Thus the user could still continue to access the payed content even if he does not use/install the iOS App any more. Is this correct?
Ans: Yeah You are right. When you had send receipt to server first time, then receipt will be verify with apple by verifyReceipt, after that your server validate this receipt time to time.
Question 2: But what happens if the users decides to delete his user account on our webpage and forgets to cancel the iOS subscription?
Ans: If user has deleted his user account on webpage then user account will be auto-renew at the end of each subscription period. There is only the way to manage i.e. if a user request for refund after deleting the account, then you can check form server(for deleting his account) and refund his money.
Question 3: In assume the subscription would simple do the same as before and would auto-renew at the end of each subscription period. Since the user account on our server has been deleted the server does not recognise the renewal any more and the user simply pays for nothing. Is this correct?
Ans: No this is not correct. Subscription will only be managed by Apple , not your server. Only your server can hit the request for verify subscription status time to time nothing than else.
Question 4: Or is there any way the server can notify Apple to cancel the subscription?
Ans: No, there is no way. Because of apple security. Server has not any authority to do anything in users account(Apple account). That is the reason apple will never approve your app with auto renew if you will not clearly see the below information to user before his purchasing(Subscription). Please refer attached screenshot.
There is no automatic API for this flow it seems within IAP ecosystem.
Here is what you can do.
Upon (before / after, depending upon how you want it) account deletion from within iOS app, you are obligated to route the user to the following page to remove his / her subscriptions, by visiting the following page:
https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions
Opening this URL launches iTunes or iTunes Store and displays the
Manage Subscription page.
If account deletion was initiated from web UI, you should show an instructional page for canceling subscriptions from all possible devices (iOS, Android, TV apps, Web). It is then user's responsibility to ensure he / she cancels it.
Since Apple is the marketplace, this is not different from you buying a grocery product from a supermarket. As it is mentioned on Apple docs pages, it is iOS user's responsibility to get in touch with Apple Customer Care for subscription cancellation.
As a service provider, you are obligated to demonstrate to the user how to do it.
We want to use auto-renewable subscriptions in our app (iOS/Android). But I don't understand what is the best way to sync these subscriptions between devices and platforms.
We are using user email for authentification but it seems that all subscriptions are linked to user's Apple account.
Does it mean that I can't sell subscription to some user if another user (from the same device) already bought one on this device because this device is already subscribed?
What is the best way to sync subscriptions between platforms? Should I write some server code to check subscription status for the current user? But, again, right now I don't have any information about user except his/her email. Of course, it is possible for me to put subscription status on our server but what to do with this case:
user A bought auto-renewable subscription on iPhone from the app;
user A cancelled this subscription via subscription management (app doesn't know anything about it yet)
user A logged-in on Android device, and he is subscribed because I don't have any information about him/her cancelling his subscription yet.
I understand that I am able to check his/her subscription status from my server, but his/her in this case means I am able to check his/her Apple account status, not his/her account in my app. So, for example, if I have two/three/million users on the same Apple device (first is a paying user, and the second cancelled his subscription) it means that I will always get the good receipt from Apple, right?
It's possible that my understanding of how it works is not very good, or, maybe, I can't see the good working pattern here, but I don't understand how to create convenient subscriptions that would work for iOS/Android both.
At the same time I know it's possible because of Wunderlist and dozen other apps with this functionality. Could someone please describe high-level logic behind that?
If your app offers auto-renewable subscriptions, you can receive server notifications from the App Store about key events by setting up an optional URL that links to your server.
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
I am working on an app which has our own user database and cross platforms subscription.
and my questions are:
pre-condition: in iOS, user did login with username and did auto-renew subscription.
1.if user deleted the app, will it cancel the auto-renew subscription for the app?
if user cancel the subscription from settings or from itunes, how do we know which user canceled the services?(I dont have game center id). I would like to inform my server that this user canceled subscription.
basically, how do we know a user did auto-renew or canceled the subscription without opening app. Is there any unique id in apple's receipt which we can get to validate the user id.
Thanks.
Got a rough solution. Basically, when user subscribe from application, you should also send receipt to your own server, and then from own server use receipt to request from apple server for the status. This is for cross platform subscription. It is unnecessary for single platform app.
Server notifications are now available.
How to enable them: https://developer.apple.com/documentation/storekit/in-app_purchase/enabling_status_update_notifications
How to set the server URL: https://help.apple.com/app-store-connect/#/dev0067a330b
Regarding your question, yes, you should keep base64 receipts on your server as well as original_transaction_id of each subscription to find this customer in your database, when you get cancellation notification webhook.
We have the same functionality implemented in our subscriptions revenue growing platform. Let me know if you have any questions.
I need to build an app for a system, which already has a subscription on its website. It looks like Apple doesn't allow to use any own subscriptions and forces to integrate any app with iOS in-app subscriptions.
Is it any way to integrate two subscription systems? The main problem is that users can manage iOS subscriptions via iTunes and I can't find whether it's possible to get information about this and to stop subscription in the existing system if it's stopped via iTunes.
So is it possible to get notifications about unsubscribed iTunes users?
Using third party subscriptions
First off, it is possible to support an existing subscription system in your app, but it must be in addition to the App Store subscriptions. Also you have to be very careful about the UI you use. You can't prompt users to bypass the App Store and purchase through your server, but you can offer existing subscribers the ability to sign in with credentials they may have previously obtained through your website.
That said, Apple can be fairly capricious in their rulings on what is and isn't allowed in the App Store. I have worked on apps that have done this sort of thing, but they have been for fairly well known magazine publications. There's no guarantee that they will allow it for everyone.
Detecting unsubscribed App Store subscriptions
As for using App Store subscriptions, when a user purchases a subscription in your app, they will receive a receipt in the SKPaymentTransaction object. This receipt should be posted to your backend server to make sure it is valid before you give the user access to anything. See the In-App Purchase Programming Guide for more details.
When you setup a subscription type, you specify how long that subscription lasts. So if you log the transaction date in the SKPaymentTransaction when you receive a receipt, you can determine exactly when that subscription should expire by adding the duration of the subscription to the transaction date.
If it's an auto-renewing subscription, you will receive a new receipt when the subscription is renewed. So once you have validated that with your backend server, you can update your expiry date based on the new transaction date. If you don't receive a new receipt before the first one expires, it's likely the user has cancelled their subscription.
On the backend, your server can also tell when a particular subscription will expire based on the response from the verification server. First there is the status code which will tell you whether the subscription has already expired, but there is also an expiry date returned in the decoded receipt which will tell you when it is expected to expire if it hasn't already.
For more details, see the Auto-Renewable Subscriptions documentation.
Testing auto-renewing subscriptions
It's worth noting that when you are testing auto-renewing subscriptions in the App Store sandbox environment, the length of the various subscription types is dramatically shortened to make it easier to test. For example a 1 week subscription lasts only 3 minutes in the sandbox environment. You can see the full list of times in the iTunes Connect Developer Guide.
So you want the people that have bought the service from the website to be able to use the app, exactly like if they had purchased it from in App Purchases and in App Purchases people to be able to join the service just like people that joined through the site? As far as I know, Apple doesn't allow you to pay through other services as you said, but let's say someone buys the service from the app. What should happen would be that the money will be transferred to the company. Then after the payment you should include some code doing what the site does after a new person has payed for the service, so create his account as a paid account. Then, the app should also have a login screen where the registered users (no matter where they registered from) will be able to login into the app and use the service. Now the problem is indeed that if the subscription is stopped through iTunes you would never know, though a way around this would be to make a check in the server of this company which should monitor the income coming from one account. Then if this user has stopped paying (or stopped the subscription) you would be able to stop the service from the app. And you should recheck the server for payment after the duration of the subscription has passed, let's say a weekly subscription should be checked every week. (Sorry I would do this a comment but I haven't got enough reputation for this)