I've been looking for a solution for hours, but I haven't found it yet.
I have a freemium app, where you can buy 3 month plans via iOS IAP, or via Stripe.
When a customer buys via stripe and their card fails, or when they cancel the subscription, my app receives a webhook and I can mark that customer as delinquent. This way I can report that customer as lost, and take actions to reengage with them.
However, with iOS I don't seem to have this possibility. One solution for this would be to keep a marker in my database for the start_date and renewal_date of that subscription, and mark them as lost only when they've failed a payment.
That'd be quite inconvenient, and I was wondering if there's a better way to validate with iTunes connect whether a user cancelled.
Related
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
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.
Our app that is in development will have the following 2 IAPs set up:
$12.99/mo as an auto-renewable subscription.
$9.99/mo as an auto-renewable subscription (if you've entered an invite code).
Obviously if the user enters the invite code BEFORE subscribing, we can ping the Apple servers with the lower-price IAP.
But our issue is: We're (planning on) allowing users to enter the invite code whenever they want, including AFTER they're already a paying subscriber. That way we can offer the discount for any future months they're a subscriber within our app.
Has anyone done this? Is this possible? Etc...
Update 8/30/2015:
Unless someone provides us with the knowledge / ability to do otherwise, we've come to the conclusion that it's NOT possible. We even reached out to Apple and they said there's no API for such thing on their end.
That being said, we're going with the following approach:
If a user subscribes BEFORE an invite code is entered, they're charged the higher of the 2 prices.
If a user enters a code while ALREADY subscribed, they must unsubscribe, then re-subscribe to obtain the lower price point.
If a user subscribes AFTER an invite code is entered, they're charged the lower of the 2 prices.
UPDATE 9/23/2016
there's something called Subscription Groups in iTunes Connect that Apple recently introduced with Auto-Renew subscriptions. A user is only allowed to subscribe to 1 of the subscriptions within a group at a time. Thereby allowing a user to shift between "tiers". This is a possible solution to those coming across this question in the future.
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)
I am building an app that offers a 30-day subscription to premium services in the app.
I am familiar with in-app purchases (consumables) and have everything setup up for that. However, I haven't found any good tutorial or explanation of what the proper procedure for validating auto-renewable subscriptions.
Can anyone point me in the right direction?
What I would like to do is have the subscription setup like this:
User purchases in-app subscription and is verified
Subscription End-Date (30 days from purchase) is added to network database with user's account info
How to detect when the subscription is renewed so I can update the network database
UPDATE
So I have figured out the original purchasing and receipt verification, so all good on that. Then getting expired date by getting the value of 'expires_date' from the receipt data.
What I need to accomplish now is the best way to check for ALL completed transactions on app load (including any auto-renewed subscriptions) so I can unlock premium services. Using 'restoreCompletedTransactions' allows me to receive old receipt data, but it forces the user to enter a password, and I would like to avoid this. What are the alternatives?
a user purchases a product and you save the receipt. keep track of a timestamp so you know how long the subscription is valid for. on each launch you validate the receipt. you will always get the latest receipt so you know whether the product was renewed. using the timestamp you can make sure the user doesnt get access after their subscription has cancelled.