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)
Related
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.
I am wondering whether to implement in-app purchase refunds (in case a user refunds). None of the in-app purchase tutorials seem to show how to do it, so I am wondering if that is for a particular reason.
By the way, the in-app purchase is a non-consumable (PRO version).
A big problem I can see with refunds for example, is that you shouldn't remove the PRO features if they don't have connection, but then someone can just use no connection with the app to never get PRO revoke.
My question is: Is there a seamless way to integrate refunds for non-consumables, and do many other apps handle refunds or not?
Thanks.
I believe the only way for a user to get a refund is to request it from Apple. If granted, the onus is on you to determine this condition. You will have to check receipts actively.
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-RECEIPT-HOW_DO_I_USE_THE_CANCELLATION_DATE_FIELD_
This states:
The Cancellation Date (cancellation_date) field is designed for use
with auto-renewable subscription, non-consumable and non-renewing
subscription products. This field is set when a customer contacts
Apple customer support for a refund and the transaction is canceled.
Depending on if your app has a backend or not will dictate a strategy to handle this. If you have a backend, a good method is to periodically check for receipt status (at some time interval of your liking). Note that if you have a large user base, you probably want to divide up the user pool piecewise to do this type of check.
If you don't have this as your option, then you need to make your app make this check.
Or ... you accept that this will happen. I've done work for a company that had a large subscription base and they never ran that check for cancellation/refund (I let them know about that weakness in the system).
Situation:
- User makes an IAP and is awarded some content, we store the users device id to ensure they can access this content whenever they want.
- User decided they do not like the content, so they call Apple and get a refund.
- User can still access the content, even though they have been refunded for their IAP
Problem:
We don't want the user to be able to access this content anymore. This could become a loophole that they would take advantage of. (unlock content, then get refunded and keep their access to said content)
Question:
Is there any way for us to check if a user has been refunded for an IAP with either their transactionId, transactionReceipt, or any other information we may have?
For Reference, I've read the StoreKitGuide, it did not mention this case.
No. There is no way to revoke access to content if they have been refunded. I believe this is by design. It is the same with App Store refunds; if someone buys an app and then asks Apple for a refund, Apple does not stop the user from continuing to use the app.
No. you cannot stop user to access. Apple does not stop user to use that feature after refund
Below a recent answer from the overbearing Apple!!!
At April 11
Hello Joe,
Thanks for your quick reply at first.
I think there were some misunderstandings. We understand that you must protect the user information. And we do not require any user info. We do not require any user's information---- iTunes account, User Name, email address and other information about himself/herself.
We require only one data----- transaction id (named "transactionIdentify" in your code), for example "1000000033409668" (this transaction id is a record at March 13).
A user buys a product from IAP, you will generate a "transaction id" and send it to us. This transaction id is stored in our database then. Now he/she gets refunds from you, so please send the transaction id to us. Let us know which one in the game canceled the IAP.
When a refund occurs, we think you should provide the transaction id to us. With these data, we could make a more fair service for all players. If you do not do it, more and more players will use your refund mechanism to get game items without real payment. You and we will lose money then. We think it is very important.
Regards,
Baibo
At April 12
Hello Baibo,
Thank you for following up with me regarding the refund transaction data.
We will not be able to provide you with the refund transaction data you have requested as it is not a feature or benefit provided to you per the contracts you have agreed to.
To view your paid applications contract and review your membership benefits, please access the contracts, tax and banking module within iTunes Connect:
http://itunesconnect.apple.com
If you are not happy with large refunds, you may want to consider adjusting the price of your in-app purchases as we will not be able to provide you with the refund transaction data in the future.
According to an answer one of my users received from Apple, refunding an app means they will no longer receive updates to the app, but doesn't remove the app from the device. IAP appears to work the same.
I am wondering if there is not a way by using restoreCompletedTransactions to check for the iAP purchase, but this would pop up a request for the user's iTunes password, so its use is limited.
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.
From the StoreKit guide:
If the user attempts to purchase a nonconsumable product or a renewable subscription they have already purchased, your application receives a regular transaction for that item, not a restore transaction. However, the user is not charged again for that product. Your application should treat these transactions identically to those of the original transaction.
This presents a huge problem in an app I am working on. We have licensed a large body of content from a publisher for sale through in-app purchase. They require that every time we sell a piece of this content (i.e. user pays us), our server calls an API on their servers to report the transaction. This is for accounting purposes and ultimately used to determine how much we pay them at the end of the month, per our agreement with them.
I have read several suggestions on SO and elsewhere about calling restoreCompletedTransactions rather frequently and maintaining a local understanding, on the device, of what the user has already purchased so they cannot be allowed to purchase it again. This to me seems like something that should be able to be implemented on the server side. However, the receipts that we are getting back from the Apple servers are exactly the same for a buy and a re-buy, as promised by the StoreKit guide.
If payment callbacks from StoreKit cannot be trusted as a valid accounting mechanism in this kind of situation ("you got paid" vs. "you didn't get paid"), what other real-time insights into transaction traffic are available? I don't think the publisher we are working with is going to be happy if we tell them we have to wait 45 days after the end of the month to get the REAL paid dollar amount out of iTunes Connect.
I have recently looked into the same problem. In my case, I wanted to implement accurate revenue tracking using Mobile App Tracking to track revenue generated from different customer acquisition campaigns.
Fortunately enough, there is a way to do it. It should be noted that SKPaymentTransactionStatePurchased vs. SKPaymentTransactionStateRestored solely depends on the initating action, e.g. whether you initiated a restore or a (re-)purchase, so that doesn't work.
What does work instead is checking for SKPaymentTransaction.originalTransaction which will be != nil for restores and re-purchases. The latter is unfortunately undefined behavior (docs). I'd consider a null check fair enough though.
Another option is to validate the transaction-receipt of transactions with SKPaymentTransactionStatePurchased and check that the original_transaction_id property in the returned, validated receipt matches the transaction_id.
The bad news is: In the current iOS version (4.3.x) there's no way to distinguish between a buy and a re-buy of non-consumable products.
To ease the situation I would recommend two things:
First
After a successful purchase, store the product identifier of the purchased product in the NSUserDefaults on the device. You can then hide the already purchased products from the user and thus handle a re-buy situation.
The NSUserDefaults are backed up by iTunes when the user synchronizes his device. So your stored purchase information is not lost when the user gets a new device.
Second
Store the receipt data together with the device ID on your server. Analyze the receipt's product identifier and the device ID.
If you receive another receipt with the same product identifier and device ID combination, then assume a re-buy. At least this would allow you to cover most of the re-buy cases.
Assuming that an ordinary iPhone user switches his device every 1-2 years, you will at least cover most of the re-buy cases and maybe apple will fix this in the future.
I have one solution,
Configure the product as consumable.
this will solve the problem - (They require that every time we sell a piece of this content (i.e. user pays us)).
Next you need to implement a logic in product buy option. It is in a way that once the user purchase a product the buy option need to remove otherwise the user may happendly go purchase and lost is cash once again for same product in same device.
you can use NSUserdefaults for this purpose.
thanks,