We have "try for free" button in our app. I'd like to figure out how to know that trial is available.
I'm a little bit doubt about following text from documentation:
New and resubscribing customers are eligible to pay one discounted price or free trial per subscription group.
What is "resubscribing"? Can customers who has subscription in the past have trial again?
Is it possible to use StoreKit to figure out that trial is available now?
Is it correct to check introductoryPrice property of the SKProduct: https://developer.apple.com/documentation/storekit/skproduct/2936878-introductoryprice?
I also had an idea to ask backend for all the subscription history for current user and show "try for free" if user didn't have trial yet. But as I said I'm not sure about that "resubscribing".
The correct way to check for trial eligibility is to validate the receipt file as outlined by Apple below. Since most would consider this a non-critical validation, there isn't much harm in doing it client-side instead of off a server to save a network call. The worst harm a fake receipt could do is change the text of your button.
Determine Eligibility
To determine if a user is eligible for an introductory price, check
their receipt: Validate the receipt as described in Validating
Receipts With the App Store. In the receipt, check the values of the
Subscription Trial Period and the Subscription Introductory Price
Period for all in-app purchase transactions. If either of these fields
are true for a given subscription, the user is not eligible for an
introductory price on that subscription product or any other products
within the same subscription group. You typically check the user's
eligibility from your server. It's best to determine eligibility
early—for example, on the first launch of the app, if possible.
Based on the receipt, you will find that new and returning customers
are eligible for introductory price or free trial discounts as
follows: New subscribers are always eligible. Lapsed subscribers who
renew are eligible if they haven't previously received an introductory
price for the given product (or any product within the same
subscription group).
To answer your specific questions:
Can customers who has subscription in the past have trial again?
No. This is enforced by Apple for any products in the same subscription group. For example if user starts a trial for "Monthly Product", cancels, then later buys "Yearly Product" they won't be eligible for a free trial.
Is it possible to use StoreKit to figure out that trial is available
now? Is it correct to check introductoryPrice property of the
SKProduct?
No. The SKProduct will always show the same introductory price.
Related
I am working on shifting my existing iOS 10+ app to offer auto-renewing subscriptions.
While "normal" subscriptions (no introductory offer) work fine both within my app and on my server (receipt validation and user account handling) I am having a hard time to understand how a free trial period can be offered.
Setting up the free trial period in App Store Connect is no problem, but I do not understand how to implement it in my app and on my server.
Problem 1 : Understanding eligibility
From the Apple docs:
You can make introductory offers to customers who haven’t previously
received an introductory offer for the given product, or for any
products in the same subscription group (...)
Before offering introductory price, you must first determine if the
user is eligible to receive it (...)
To determine if a user is eligible for an introductory offer, check their receipt...
Assume I have setup a subscription with a 7 day free trial. A user purchases this subscriptions, uses the free trial and continues the paid subscriptions for a while before the subscription is canceled. Some time later the wants to continue the subscriptions
What happens if the user purchases the same subscription product again?
Will fail because he has already used the free trial? ("... who haven’t previously received an introductory offer...")
Will it start with another free trial period? (== Store does not check the eligibility at all)
Will it start with no free trial but directly with a payed period
In other words:
Is checking the eligibility only necessary to show the right UI (= grant offer yes/no is checked by store) or to make sure the user does not benefits from the same offer (= grant offer yes/no is checked by app)?
Problem 2 : How to check eligibility?
As described in the apple docs the best way to check the eligibility is to validate the app receipt and to check whether an introductory offer has been received or not. This should be done as early as possible, at app start at best.
Fine, but as far as I know the receipt is not guaranteed to be available. If no receipt can be found the user has to first provide his app store credentials to download the receipt...
It would be quite annoying if the first thing the app does on the the first start would be to ask the user to login to the store.
Is this really the intended implementation?
Problem 3 : How to handle eligibility?
Assume that I have successfully check whether the user is eligible to receive an offer or not: How to provide the offer?
Do I have to setup two different subscription products in App Store Connect (one with free trial and one without) to let the user purchase the one or the other?
Or the eligibility check only necessary to display the correct UI ("Purchase now with free trial" vs "Purchase now") while I can use the same product in both cases?
Problem 1 : Understanding eligibility
He will be charged for the subscription immediately. Free-trial can be availed only once
Problem 3 : How to handle eligibility?
Do I have to setup two different subscription products in App Store Connect (one with free trial and one without) to let the user
purchase the one or the other?
No. You only need to setup one product and add Introductory offer (free trial or intro offer)
Or the eligibility check only necessary to display the correct UI ("Purchase now with free trial" vs "Purchase now") while I can use the same product in both cases?
It is only for showing correct CTA and messaging. At the end of the day, Store(Apple) is the one who is taking the decision if user will get free-trial or not
To check eligibility of the user you need to pass the receipt to your server. Your server can then query Apple for the decoded receipt (/verifyReceipt endpoint). In decoded receipt, check all the txn in latest_renewal_info list. if you find is_in_free_trial field to be true for any product in same subscription group then you can safely assume that user has used free trial before and show right messaging to the user.
Also, user can get free trial only once per subscription group even if all the products under that have free trial enabled.
I agree that Apple would have provided eligibility in the app itself while querying the product. But trust me none of the App stores provide this information including Google.
As far as login is concerned, the receipt is always present at a sandbox location and can be retrieved from there. (Also, do consider that user anyway can't buy the subscription if he is not logged in)
Summing up my R&D free trial via introductory price only meant to be free for specific time after customer bought subscription.
I want that feature to be initially free for a month and then user buy the subscription.
How can I achieve this ?Is it achievable via Introductory price?
Yes It is achievable by introductory price. You can choose free trial
duration for a month inside introductory price's.
With Free trial, New subscribers access content for free for a
specified duration(say month). Their subscription begins immediately but theywon’t be billed until the free trial period is over.
Check it out for more details : docs
If you are asking that, if user can get free month trial subscription without going for IAP subscription purchase. You need to set logic for that by your own, that after user has installed your app, he/she should be able to use services for a month and after a month all those services should get blocked. and it will be again enabled only after user purchase subscription.
I am developing an app which requires auto renew subscription monthly and I want to maintain that on per user basis who logged into my app. is it possible anyhow with in app purchase. Also how can we handle cancelation of subscriptions ?
I want to maintain all this on my own server.
In the StoreKit documentation, it mentioned in Cancellation section:
A subscription is paid for in full when it’s purchased and can be
refunded only by contacting Apple customer service. For example, if
the user accidentally buys the wrong product, customer support can
cancel the subscription and issue a refund. It’s not possible for
customers to change their mind in the middle of a subscription period
and decide they don’t want to pay for the rest of the subscription.
To check whether a purchase has been canceled, look for the
Cancellation Date field in the receipt. If the field has a date in it,
regardless of the subscription’s expiration date, the purchase has
been canceled—treat a canceled receipt the same as if no purchase had
ever been made.
Depending on the type of product, you may be able to check only the
currently active subscription, or you may need to check all past
subscriptions. For example, a magazine app would need to check all
past subscriptions to determine which issues the user had access to.
Bear in mind that users can cancel the subscription anytime without opening your App. Therefore, you have to check the status of subscription every time the user logs into your App.
Following iTunes Connect Developer Guide, when I create In-App purchase of type "Auto-renewable subscription" for my application, I can offer a free trial and set it duration: http://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/13_ManagingIn-AppPurchases/ManagingIn-AppPurchases.html#//apple_ref/doc/uid/TP40011225-CH4-SW9
Reading this post: https://stackoverflow.com/a/17088975/2555979 , I assume, that if we try to verify the receipt, which was send to the user after he subscribed first time (ever) and got a free trial subscription, we can differentiate, is this user at trial subscription, or has he purchased it already, only by checking difference between expires_date and purchase_date, if durations of purchased and trial subscriptions are different, or by checking the original_transaction_id or original_purchase_date (if current transaction is not first, the subscription was renewed -> it's not trial already). If I'm wrong, please, let me know, because that's how I see the process in theory, not the practice (can't test that at the moment).
Anyway, the main question:
At some day, user installs my app and subscribes. He automatically gets some time of free trial subscription. He enjoys my app, everything is great, and he decides to be subscribed in future and automatically pay me every time when subscription ends. He doesn't even need to care about that, OK. Thanks to auto-renewable subscription mechanism.
After some time, he decides to stop auto-renew process. When last subscription expires, he don't pay me -> he is not subscribed from that moment. Okay.
But if, after some time, he decides to subscribe to my app again --- how about trial again? Who decides that? Is it in my responsibility to check, had he trial subscription or not? If yes, even if I know, that he had trial subscription already, how do I force him to pay from the first day of subscription, not after another trial period?
If he's using the same Apple ID, and you are selling the same subscription product, he will not get any more trial. Trials on subscription can only happen once regardless if they've stopped and resumed their subscriptions.
I know Apple's documentation has been very sparse on Newsstand. I have also experienced the same pain. I don't have any Apple documentations to back my answer up, but from my experience this is what happens. Customers will only receive a one time trial for every unique renewable product.
I've been reading the various threads on in-app purchases auto-renewal subscriptions, and I think I've pieced together most of the information I need, but there are a few missing pieces. I'm hoping someone can help me.
The situation:
I have various subscription packages the user can subscribe to (e.g., package A for £1 a month, package B for £2 a month, etc.). I store the user's subscription information in my database. When the user logs in, I check which package he's on and if it's expired or not. My website, android and iOS all use the same database, hence this approach seems to make sense.
Subscribing users via in-app purchase seems straight forward enough. I check paymentQueue and once the payment is cleared, I can update my database.
My questions:
1) My understanding is the user can use iTunes to manage their subscription. Say, they go in to iTunes and cancel their subscription, how can I be notified so I can update my database? Do I need a daemon that checks expired subscriptions to see if the user renewed?
2) If the user wants to upgrade their subscription from Package A to Package B, how do I handle the pricing? Say on Jan 1st, they buy Package A, I charge them £1.00 and set the expiry date to Jan. 31st. On Jan. 15th, they want to upgrade to package B via in-app purchase. Ideally, I would charge them £2 for Package B minus £0.50 of credit they have for Package A and set the new expiry date to feb 14th. However, Apple forces me to associate each package with a tier price. How can I handle this? I don't want the user to wait until the end of the month to put them on a higher tier package...if they upgraded mid-month, it means they want the new content package B will deliver to them immediately.
Any help appreciated!
Thanks!
1) Yes you'll have to reverify your receipt check out the Receipt Validation Programming Guide in the documentation. They mention some important keys:
status - 0 if receipt is valid, or an error code
receipt - JSON response of the receipt
latest_receipt (auto-renewable only) - base 64 encoded receipt for the most recent renewal
latest_receipt_info - JSON version of latest_receipt
With this information, when a purchase is made, send the receipt to your backend for validation, the backend will keep the receipt in the DB and verify with status = 0 that it's a valid receipt. From there, every x days you can validate that receipt with a chron job, daemon, etc. and reverify. The response back each time will have latest_receipt_info that you now need to save to your DB so you have an up-to-date receipt for the next check in x days. This way you will always have the latest receipt. There is no instant notification for telling when a user cancels a subscription, but with this you'll know every x days if they have the subscription still.
2) Pricing like this unfortunately can't be handled. It was not intended for a user to "upgrade" with subscriptions - each subscription is access to it's own exclusive content as of this writing. However, if a customer emails in and complains about it, you could ask for their user name and figure out in your DB if this user has indeed upgraded mid-month and reimburse them appropriately. Very old-school and not feasible for a big user base, but hopefully you won't have that many and can keep them happy.
EDITED
For the second question, Apple's auto-renewable subscription system does not technically offer upgradeable plans between different products.
Every subscription is a stand alone product and it's up to the user to turn on/off subscriptions manually using the Subscription Manager in the iTunes Store.
However if package A and package B offer the exact same content only different duration than what ajay_nasa said is correct, you can create an single auto-subscription product with different duration options. If the user is on 1 month subscription and then the user tries to change to 2-months subscription they will get the following error message asking them go to the App Store's subscriptions manager
So basically the ONLY place the user can actually change the subscription's length is in the App Store. Whether Apple decide to pro-rate the amount left on the old subscription or just append it to the current one is really up to Apple. You need to make sure the user have access to the subscription as long as it's active by reading the Original Purchase Date and Subscription Expiration Date field from each receipt entry and determining the start and end dates of the subscription.
Answering question 1, you can verify subscription receipts in the same way as other IAP, but you'll need to check it periodically to see if the subscription has expired (the verification will tell you if it's expired).
There is more info on the Apple docs here:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html
Actually, Apple's auto-renewable subscription system does offer upgradeable plans.
To achieve this we simply should add duration in existing Auto-Renewable Subscription. Every Auto-Renewable Subscription could be family of Subscriptions so whenever developer wants to achieve upgradation in subscription he should add duration in existing Auto-Renewable Subscription with different productID.
Whenever, user upgrade his plan in between the month then his upgrade plan will be automatically works from next month.
Answering to your question #1
Recently Apple launched a feature to enable server notification whenever the subscription is renewed. However, the subscription should be in-app.
See the links given below for your reference:
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
&
https://itunespartner.apple.com/en/apps/news/45333106?sc_cid=ITC-AP-ENREC
We Need to Check Cancellation-Date provided in Receipt.