I'm working on the app with monthly auto-renewable subscriptions. Right now I'm planning to check/validate the receipt every time on startup, but it seems that this approach is perceived as a bad practice, and some people are implementing the complex logic to calculate when user's subscription will expire to check the subscription receipt only one time per month.
Why?
If this will destroy the user experience (or, there is a chance for such turn of events), then how?
Related
I have created my first app and I am almost ready to submit it to the Appstore. I have spent the entirety of the last few months of quarantine focusing on this app so I am implementing a subscription in app purchase in order to repay my efforts while simultaneously adding value to my customers. There is great probability that this app will succeed.
I would like to offer 1 month, 6 months, and 12 month subscriptions. I have looked into auto-renewing subscriptions but when it comes to checking the subscription status of a user I have quickly noticed how complicated everything is with Apple's encrypted receipts.
I would like to offer subscriptions but it seem that I will be unable to offer auto-renewing subscriptions as I have absolutely no clue how to decrypt and parse Apple's receipts and resources online seem feeble.
Would it be best/easiest to have my subscriptions as non-renewable or even consumables? This way I could track my users subscription status on my own backend without the added layer of complexity that comes with parsing encrypted data from Apple.
From a business perspective, notifying a user that their subscription is ending is certainly not as effective as auto-renewing it. Will there be a noticeable difference in revenue if I set my subscriptions to consumables or non-renewing?
I thank the community ahead of time for its insights.
In your case, if you don't want to waste your time on handling auto-renewable subscriptions, you can use subscriptions backend as a service like ours or competitor's: Apphud or RevenueCat. We do exactly what you need. Hope that helps, thanks.
Auto renewable subscriptions would be the best option for you in terms of revenue. Although customers are notified by the apple itself for renewal deduction so you just need a backend services which will be keep on tracking on extending the user subscriptions through the initial receipt stored in your databases.
You need to use meta data from the receipt under key "latest_receipt" to get the latest update in the subscription.
Below is the link for reference.
https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store#//apple_ref/doc/uid/TP40010573-CH104-SW1
In order to be able to better estimate the revenue income of our app, we implemented a Database function that reliably (we tested it in Sandbox mode) increases a subscription counter for the subscription that was made by one once a subscription has been made.
This function is only triggered once an in-app purchase has been successful (i.e. when we receive the feedback from StoreKit to enable the Premium functions). Now, we have found enormous discrepancies between the data we observed and the data App Store Connect gives us.
For the past two days, upon confirmation of purchase via StoreKit, our app has 13 times enabled premium functions on a monthly subscription basis, and 14 times on a yearly subscription basis.
However, App Store Connect tells us we had one yearly subscription and 5 monthlies.
Furthermore, for the one premium subscription that generated sales of $5.60, Apple has added proceeds of $3.73 - but that's more than 30% commission. That's almost 35%.
The sales that Apple has not accounted for amount to more than $70.
Can anybody explain to me what's going on, why Apple is not showing us subscriptions that definitely happened and takes more commission than agreed?
My bet is that you are not aggregating the prices correctly on your database side. It is extremely complicated thing to do, despite superficially seeming simple.
The second guess is that ItunesConnect revenue is delayed by day or three (they were experiencing delays).
If you want to see know the revenue calculation is done correctly, I recommend hooking yourself to RevenueCat (quite simple process), and to double check numbers.
Regarding the price, don’t forget their is also sales tax/VAT that is deducted too. Eg. Any sales made in the UK will have 20% vat removed, then Apple takes 30% and you get the rest.
I am looking for some advice on how to go about checking the current status of a users auto renewable subscription.
At the minute I am using the following setup.
User registers and subscribes to the product.
The receipt is posted to my server.
Each night the server pulls all the users where the expiry date is in the past and then using the receipt check to see if the product has been renewed.
Now I think I have an issue with the above setup, it works ok for a small number of people but lets say I have a few thousand. I noticed that calling the Apple servers takes time and so I can't really run the above setup reliably.
I am thinking should I check the receipt locally every time the user opens the app and then post the latest info to my server each time and keep it updated that way? The only issue I have here is that if a user doesn't open for a while then I cant validate their status and my database isn't up to date.
Any advice on the proper approach to take would be great thanks.
This is a real problem.
At Elevate we would do exactly what you described, checking everyone's receipt every night. This was fine until the time it took to check all of our receipts exceeded 24 hours. At this point we implemented some smart pacing: Each time we checked a receipt and it wasn't subscribed and the user hadn't logged in, we would extend the date where we would check it.
This isn't bullet proof but is a decent balance of accuracy and efficiency.
I thought this was such a crappy problem I started a company to solve it. We do all the nasty receipt checking so you can just ask if a user is active or not.
I have been reading a lot about auto-renewable subscriptions but so far I could not get a satisfactory answer to my questions.
Imagine a user subscribed to my app for 1 month and the very first view of the app has some content that only visible with subscription. Now imagine it's the first day of second's month subscription (after auto-renewed). If I don't query the expiry date from apple server, user can't see subscription items, because the expiry date of first month already passed and we need to get the new expiry date.
My questions are:
1- Is there a way to get the end date of the subscription offline and without disturbing the user (with password prompt etc.)? How user will get subscription content if it is the first day of auto-renewed subscription (second month and so on) and if user don't have internet? Will he see locked content if he has no internet? If so this is sounds weird to me.
2- If it is not possible to get expiry date of auto-renewed subscription offline, what is the best approach to get expiry date of auto-renewed subscription without asking or prompting something to user? Because we want to show the very first page of the app with subscription content smoothly. What comes to my mind is to make user wait during launching and check expiry date from server.
I am sure many developers are still concerned with those issues.
It's been a long time since the last time that I integrated an auto renewable subscription and it harder than I expected, but I can give you some general hints and some more specific for your question.
Starting from your question.
Not exactly, you can get the last updated receipt by asking getting the receipt from the receiptURL, here is where I've found a really gray area. I never had a chance to understand exactly when a receipt is updated automatically, probably this happen right after Apple charged you (of course this update needs a connection). This doesn't seems to happen when you have restored a purchase on another device.
Yes there are, when you have a chance to validate the receipt you can store the expire date somewhere (maybe in a secure way) and only before one or two days after that day try to validate it again. If you want you can apply also a grace period after.
Other tips:
you MUST create a way to restore the purchase or your app will be rejected
on sandbox at the first launch the receipt will not exist, but in production an app will always have a receipt, maybe without subscription info, but there is. Thus if you want to simulate some use case in sandbox environment is better if you restore the purchase right after the launch of the application.
restore purchase always requires username and pwd and refresh receipt seems too
Maybe some of this info are a little bit outdated, I made the integration with iOS7 and never had a chance to update it.
I'm creating an app that will unlock features to users for a limited time. Premium features let's call them. They can buy a subscription for a month, 6 months or a year. These subscriptions would be non-renewing. After a lot of searching the web and finding very different "solutions", I turn to StackOverflow for what the best should be.
When a subscription is bought, the end date is stored locally on the device until synced via iCloud, because Apple wants you to have this subscription on all your devices. The app checks iCloud to see if the current subscription is still available, shows a nice countdown for the users with days left. But I'm currently encountering a problem. When the user has paid for a month, and changes the date of the device to a year earlier (or something else), it can use the subscription for a year. The countdown now doesn't show 23 days left, but 389.
How can I avoid this?
Should I check a certain server to check for the real time and date?
What if a user only uses the app in airplane mode?
Thx in advance!
You could check standard web-based time-servers to do this. Since I have my own server (as part my in-app purchase mechanisms), I just ask my server for the current time, at the server. I do this every time the app launches, and every time I make a server-call (usually when in-app purchases are done). I then store the time locally (either in the KeyChain or NSUserDefaults, can't remember which!), and use it (and the device time, which ever is later in time) to compute purchase expiries.
Of course, this assumes that the user has a network connection when they launch the app. You can only do so much though!
Actually what happening is after successful completion of your InAppPurchase apple will provide you a Transaction Reciept...this transaction reciept is stored in locally . When you want to check the subscription is in active or expired you need to request the storekit with this transaction reciept then the store kit will give you the status .. if the status is 0 then it is in active state . if the status is 21006 then your transaction is Expired. If you want to continue the subscription in antoher device then you need to Restore the transactions there .. after completion of the restoration you will get all the product ids and the transaction reciepts.. you need to store the transaction reciepts there and you need to pass this for the storekit whether it is in active or expired state .. sorry for my poor english..