I am developing an in app purchase app (auto renewal) and purchase/cancellation should effect on all platform (Android, iOS, Web).
My question is what is best way to keep track the latest status of the purchase. I know there is a way called server to server notification using web hook, but I am thinking can we store the receipt data to server and validate this receipt time to time with iTunes apis?
Does receipt data change over the updates on subscription or it is same even after changing the device?
All I want to validate it at server side, because there is a possibility that user can uninstall the app or not using it.
You can validate the receipts at server end. There are two options.
Enabling server to server notifications.
Store all receipts in your databases and verify it with server for latest update.
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
Initial receipt meta data does not change over the time. You can save initial receipt metadata in your database and use it for further updates like - renewal, cancellation, upgrade or downgrade, refund etc.
Yes, you can, moreover server-to-server validation & observing is most preferable way recommended by Apple. They provided JSON API and accepts your server end-point to post any changes directly to server.
For details read Choosing a Receipt Validation Technique and related in topic.
The common start point is In-App Purchase
Related
I have created an app which has auto-renewable subscriptions.
The following is the logic that I use to know if the user has an active subscription.
Whenever paymentQueue(_:updatedTransactions:) of SKPaymentQueue is called, I try to perform receipt validation using following steps
I check if the local receipt is present. If it is not present I use SKReceiptRefreshRequest to refresh the receipt.
I send the receipt information to verifyReceipt endpoint of the App Store server.
The server returns response which contains information about the subscription expiration date.
I store the expiration date in the app and present the appropriate UI based on whether the user has an active subscription or not.
The App Store review has rejected my app multiple times because the SKReceiptRefreshRequest errors out. I am unable to reproduce the error faced by the App Store review board.
While searching the internet to solve the problem, I got to know the following facts about the local receipt-
The local receipt is always present in the production mode. The local receipt may not present if the app is installed using Testflight or during testing. (link)
The App Store server will return the latest subscription information even it it sent an old local receipt (link)
From the above 2 pieces of information, I deduce that there is no need to ever call SKReceiptRefreshRequest in production because the App Store server will provide the latest details even if the local receipt is old and the local receipt is always present in production.
In order to get my app through the App Store review, I have decided to remove the SKReceiptRefreshRequest as it gives errors in the Testflight builds and is not required in the production.
Can anyone confirm if I am correct to do this?
Your logic has multiple flaws:
1) paymentQueue(_:updatedTransactions:) is called in the background and (as far as I know) updates already the local receipt. Also an app downloaded from the App Store always contains the receipt. So there is no need to call SKReceiptRefreshRequest in that method.
2) SKReceiptRefreshRequest requires the users to input his password to allow the receipt refresh. Since you triggered the method within paymentQueue(_:updatedTransactions:), which was called in the background, I reckon this is the problem why the refresh request failed and Apple rejected your app. Nevertheless this method has its reason for being: in production you need it to allow users to restore purchases after reinstalling the app or on other devices and for debug and TestFlight builds you need it to get the latest receipt.
3) You shouldn't send the receipt from your app to Apple's endpoint
Warning
Do not call the App Store server verifyReceipt endpoint from your app. You can't build a trusted connection between a user’s device and the App Store directly, because you don’t control either end of that connection, which makes it susceptible to a man-in-the-middle attack.
Source
How to proceed?
I would recommend to do the following things:
1) Do not trigger SKReceiptRefreshRequest in paymentQueue(_:updatedTransactions:)
2) If not already done provide a "restore purchases" button in your app (which calls SKReceiptRefreshRequest)
3) Implement local or server-to-server receipt validation
I have used the following way to generate the receipt and send the generated receipt to server for verification:
https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store
I have followed some tutorials on implementing In-App purchases and subscriptions for iOS (especially Ray Wenderlich) but I have doubts on how to integrate our iOS app with our website so that if someone subscribes to the app they can access the content on the web as well.
Our website and app offer access to videos. All subscribers have access to all videos. Our web works with PHP and MySQL. When someone subscribes on the web, a record for their account is created in our MySQL database and they are flagged as subscribers so that they can access the content.
We want to implement in-app subscription in our app, but we need for a record to be created in our database when the subscription takes place.
The question is, should we do this upon receipt validation (we'll be doing this in PHP)? Also, is there a way to know when a user unsubscribes through iOS so that the database can be updated accordingly?
Our closest example of how we would like it to work is Gaia.
Should we do this upon receipt validation?
Yes, you should wait until you validate the receipt to mark the subscription as active for the user.
Is there a way to know when a user unsubscribes through iOS so that
the database can be updated accordingly?
The correct way to implement this is to store the entire IAP receipt on your server and periodically refresh it with Apple to get the current subscription status. Just because somebody started a subscription doesn't mean it will still be active the next time you check it (e.g. they may have turned off auto-renew or been issued a refund).
This blog posts explains some of the nuances in further detail: iOS Subscriptions Are Hard
Is there a way to know when a user unsubscribes through iOS so that
the database can be updated accordingly?
Use status update notification.
A statusUpdateNotification is a server-to-server notification service
for auto-renewable subscriptions. A notification specifies the status
of a subscription at the time the notification is sent.
As status update notification is not a reliable service, Apple recommend to use this in combination of other method such as polling the verifyreceipt end point. creating a scheduler in server will be best option along with notification.
I am developing a iOS app that uses In App Purchase, and I am not sure I have a good understanding of SKReceiptRefreshRequest. Is it for use only in the testing environment, or can I use it in the final app version on the store? Many features in IAP rely on having an updated receipt, but one problem is that, in the testing environment, firing a SKReceiptRefreshRequest causes the app to present a request for Apple ID credentials. If SKReceiptRefreshRequest is for use on the final app version too, will it trigger a credentials request also on the user devices?
You shouldn't be calling SKReceiptRefreshRequest to keep the receipt up to date. As you've seen, any time you access the receipt it could trigger a credentials request. This is because receipts are linked to the iTunes Account on the device.
If you need information from the receipt frequently, what you should be doing is storing it on a server and keeping it up-to-date there. You can use Apple's /verifyReceipt endpoint to update the receipt on your server so there's no need to get the user credentials from the device.
We have got a problem with auto renewable subscription.
First, I would like to tell you my case from the beginning to understand my problem totally.
So, I have an app that contains auto renewable subscription. I managed to buy a product from my app, but I would like to validate the receipt from my server. If I understand it well, then I should send the receipt data to my server that will send the receipt data to Apple and verify that receipt.
First question is that, do I know it right that verification means that we send a request to https://sandbox.itunes.apple.com/verifyReceipt ?
Secondly, what happens if I cannot send the receipt data for the server? I mean, in this case should I save the receipt data locally and try to send it again in a different time (my app can be used after registration so I have to send the user id with receipt data to my server)?
Furthermore, there is a subscription status URL for auto renewable subscription in iTunes connect. We set up an URL for this but we do not get any notification from Apple's server. We configured the server as explained in Apple's documentation (protocols, etc.) but we still don't get any notification. Do you have any suggestion why is it?
Do I know it well, that the notifications should be sent automatically if any status update change happens? If not then what should I do in my app or on my server? (e.g. how to detect if user cancels a subscription?)
Do I have to implement both logic for the best user experience?
To validate the receipt you can send it on apple servers, "can" because you can validate the receipt also in app. In this case is not fully safe, because someone can attack you app and tamper your validation code.
Apple has 2 different kind of servers test and production, when you are debugging you send receipt to the test servers, that also means that auto renewable subscription have shorter time, if I remember well a month in test is 5 minutes.
This is documented very well in apple documentation.
A receipt is always present in your app even if it's free. It's up to you how to manage those kind of situation, in my opinion a receipt should aways be valid from the beginning until the server responds in a different way.
The third question is not clear. There is a system to refresh a subscription but this should be done with user permission as far as I know, the subscription itself seems to be already updated automatically from time to time by the purchase mechanism.
You must implement all the logic to manage a subscription, cancellation, revocation etc.
I'm creating a service which allows users to register on any number of devices (web, Android, Roku, iOS, Apple TV), and then purchase a monthly subscription to watch video content. The subscription provides access to the entire catalog. I have my own subscription management API running on a server which I'd like to leverage as the source of truth so users can purchase a subscription on their iPad, login to the app on Roku, and continue watching where they left off.
Basically, Netflix.
Here are my options as far as I can tell:
Auto-renewing subscriptions: this is what Netflix uses today, but Apple doesn't provide an API or any set of webhooks around their payment platform, so I don't know how this option could work. My back-end service will have no idea when Apple automatically renews the subscription each month or if a user cancels their subscriptions.
Non-renewing subscriptions: users purchase the subscription inside
the app though IAP. Once purchase is complete, the app sync’s the
subscription to my back-end system. The app interfaces with my
back-end any time an entitlement check is required. When a user’s
subscription is about to expire, the app must present purchase
workflow again.
Import iTunes reports: won't work because it's not realtime (pull, not push) and doesn't tell me anything about cancelled subscriptions. I can only generate reports of new subscribers.
Receipt validation & push receipts to my service: won't work because it depends on the user actually using my app. Users could theoretically subscribe in my app, switch to Roku, and never open it again.
Skip IAP altogether and require users to subscribe via web.
Am I missing something? I'm really curious how Netflix is pulling this off.
For the initial subscription purchase:
User initiates a purchase on the iDevice
Device contacts Apple, Apple issues a receipt and sends it back to the device
The device sends the receipt to my server
The server validates that the receipt is legit through Apple's receipt validation API
Once the receipt is validated, the server stores it in my DB
The server responds to the app saying it's all good
To keep the server in sync with the iTunes subscription:
Setup a cron job to retrieve expiring receipts from the DB on a daily basis or something
Validate each receipt with Apple
Apple will respond with an updated version of the receipt that contains details regarding whether or not the subscription was canceled/renewed/etc.
Server replaces the original receipt with this updated version in the DB
Now if someone logs into their account on a Roku or some other device, the subscription can be honored because my DB is the source of truth.
I know this is old, but Apple recently introduced Status Update Notifactions which accomplishes what the OP asked for via webhooks:
Configure Apple to send notifications to your specified endpoint. (Apple's small guide)
Handle the JSON object that's sent via HTTP POST from the App Store and validate latest receipt.
Update/save data to your database.
Respond with a 200 status code to report a success.
You'll be able to handle the following notification types: INITIAL_BUY, CANCEL, RENEWAL, INTERACTIVE_RENEWAL, DID_CHANGE_RENEWAL_PREFERENCE
The documentation in the link above explains implementation and types in more detail.