I'm getting ready to include in-app purchasing for subscription features in my iOS app. Per what I've read, I need to use a non-renewable subscription type (not auto-renewable). Some customers trick the system and get a refund from Apple but they can still use their app. As a non-renewable subscription has to be handled by an external server (us) we will obviously log the subscription purchase, receipt, etc.
Is there a way in the receipt verification to determine if the subscription is still valid? I'm not sure if the non-renewable subscription type validation is simply testing whether a receipt is valid or if the subscription remains valid.
For example, you make a purchase, the receipt validates. If you cancel your purchase with Apple via an iTunes complaint and Apple grants you a refund, if I were to later verify that receipt again would it come back invalid? I'm wondering if we should build in a frequent validation routine that would catch any subscriptions that have been refunded. We have some terms that will go two years so it's important we verify these on a set schedule. We originally planned to use auto-renewable subscriptions where this scenario does exist as it's the way to determine if the subscription renewed, but now learning a subscription for synchronization will require a non-renewable subscription type.
See this question on refunds.
Apple doesn't provide you a way to determine if a transaction was refunded. Since refunds are officially not supported, they expect you to continue to deliver the goods to a refunded user.
Related
I was wondering if my approach regarding auto-renewable subscriptions is correct.
I have implemented an auto-renewable subscription in my app, it is the only IAP.
When the user launches the app, it performs receipt validation through Apple's servers. When I receive the response I check the expires_date_ms in latest_receipt_info to see if the user is subscribed or not. When I perform receipt validation I also add the exclude-old-transactions tag. I have also added a "Restore previous purchases" function to restore older receipts on the first app launch.
Is my approach correct or I am missing something? Also, do auto-renewable subscriptions auto-renew automatically or do I have to implement the feature by myself?
Thanks in advance for any help.
Regards.
Auto-renewable in-app subscriptions do renew automatically, you don't need to do anything for that. You just need to check if a subscriber has an active subscription when using your app. You can also activate the grace period in App Store Connect for your subscription, so your users will have access for additional 16 days if Apple could not renew the subscription. You can read more here https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/reducing_involuntary_subscriber_churn
here's my straightforward question:
is it allowed for my iOS application to force users to log into my custom account management system, so I can link them to my backend when they want to purchase a non-renewing subscription?
Here's the backstory:
I have a non-renewing subscription. For a good amount of users I can see that the Apple receipt does not contain information about this subscription; the in_app array is empty. This is correct according to the API:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt
For some users, I can still see the purchase in the receipt, but let's consider that a bug from Apple and follow their API documentation to the letter.
(More on why this is a bug here https://forums.developer.apple.com/thread/22345)
In order to restore the user's purchase, I'd need something to identify him with. I could create a unique token, store that on the iCloud keychain and use that across the devices to detect the purchase belongs to that Apple account, but since my application supports account creation, I'd rather just use that mechanism. Else I'm using two different methods of purchase detection side by side: iCloud keychain token or a user account.
Thing is, I'm not sure I am allowed to force users to make an account before making a purchase. Is this something Apple would reject the app submission for with a message like "Your users must be able to buy stuff without going through your lengthy account registration process" ?
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.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
So its your app's responsibility to check that user has valid subscription or its over and let them purchase it again !
For this you will ask user to first make account or login into app so by this way you can track their subscriptions.
I'm working on an iOS app that will use Apple's in-app purchasing framework to let the user create auto-renewing subscriptions.
I want my server to check periodically that none of the subscriptions have expired. Apple's Receipt Validation Programming Guide describes a verifyReceipt web service that appears to validate a single receipt.
However, if I want to bulk-verify my entire database every few days, is there a better way to do that than a storm of individual verifyReceipt calls?
You don't need to need to bulk-verify your entire database. A subscription is valid for a fixed duration. If the user cancels their subscription then this takes effect at the next renewal period, not immediately.
Apple customer service can refund a subscription if a user has a case (wrong product purchase is one example they give) but this would be a pretty low figure - and your app should also check for a valid subscription when it starts.
So you should only need to verify subscriptions that are known to be expiring "today".
To my knowledge there's no way to send multiple receipts in one bulk request to validate them in the iTunes servers... You have to send one by one. (Multiple requests)...
I don't know if how you are planing to solve this is the best approach. Apple has extended documentation on how to handle auto renewal subscriptions, most of the times you check the validity of the subscription in the app itself.
Check the in-app purchase documentation. It's a very good read if you plan to depend on in-app subscriptions for your business model:
https://developer.apple.com/library/ios/technotes/tn2259/_index.html
I'm trying to work out the best mechanism to handle the auto renewing part so that it handles the continuation of the subscription into the next period.
What the best way of handling this?
Should I have an NSTimer set to check if the current expires_date has been reached .. and then try send a purchase request?
Apple iOS in-app purchases provides the product "Auto-renewable subscription". This product will be renewed automatically by Apple.
When you use this type of product, your app has to verify if the auto-renewable subscription is still valid, since the user might have cancelled the subscription. When an user cancel a subscription, the subscription remains valid until the end of the subscription period.
To validate an auto-renewable subscription, you have to use the purchase receipt and the shared secret generated for your app in-app purchases in iTunes Connect. You have to post this two things to the App Store. This will return a JSON and you have to get from this data the "
subscription's latest purchase date". From that date you have to calculate the expiration date and validate or invalidate the subscription.
You can do all this validation after application launch and/or when the model is updated.
Additional information
You can find information about auto-renewable subscription in Apple documentation. Also, you can check about MKStoreKit, which is a framework that reduces the amount of code that you have to write for the use of StoreKit, and supports Auto-renewable subscriptions.
I am finding that the renewal of an expired auto-renewing subscription is never being delivered while the application is active and running, but rather when the application is woken up from background or on launch.
In other words if you are using the app, and the subscription expires, it won't be delivered to the app (assuming it is auto-renewing and valid etc) while the user continues to use the app.
This behaviour does not seem to be documented by Apple, can anyone else with experience of this confirm or otherwise?
Obviously one can detect that the sub has expired and then offer the user the chance to check their subscription status and restoreCompletedTransactions which will pull in the new subscription - but I'm just wondering if we're doing something wrong, or if this behaviour is normal.
Thanks.
Yes. That's what I experienced as well.
Before I continue, please see the following posts on why you might want to stay away from auto-renewing subscriptions:
Marco Arment's piece on The limited world of auto-renewable subscriptions, and
The Comments on this SO Question: Auto-renewing subscription – Differences to non-renewing subscription
When your app becomes active, that does seem to trigger the App Store to send any new auto-renewing subscription receipts to your app. But you shouldn't rely on that. And, you don't have to restoreCompletedTransactions to get the latest receipts.
You can see another one of my answers for more detail on this subject.
What you should be doing (based on Apple's documentation and some experimentation) is storing receipts on your server. Then when you want to check if a person's subscription has been auto-renewed, follow Apples procedure for verifying one of those receipts with iTunes. Apple will respond with info about that receipt as well as the latest receipt in that subscription. If it's different than the one you sent, then you know an auto-renewal has occured.