I made In-App purchase for consumable product in my ios app. purchase flow completely working fine. but i have some few doubts in my point, so let any one clears my doubts its very useful for me to fine tune my app better
after purchasing i can get receipt data, can i send this receipt data to server
during purchase if user internet disconnect, how i can get purchase information like its succeed, or its failed. i need this kind of information to be stored in back-end server
like wise i need to store all purchases to my back-end server. like user a purchased this item with time & date. user b attempt to purchase this item but poor network purchase not succeed
if i store these data its useful for me to analyze in-app purchases happened inside my ios application.
its look like a dashboard to find all these information. hope any one will help me to solve this.
thanks
Yes, you can send the receipt date to the server and you should to it to verify receipt instead of verify on local.
You subscribe the changes on payment queue, and when the device reconnected to the internet, you'll receive the payment events. Additional, there're product types you have to provide UI for users to restore purchased products.
It depends on your product requirements, for me, only successfully purchased receipts are stored (around ~1gb per day)
Related
I just run into a problem with in-app auto-renewable subscription. The app contains this kind of subscription and the app can be used by multiple users but the subscription is bind to the apple id is used on the device. So if a different user log in to the app than the system say he has a valid subscription. If I log the subscribed users on my backend server than if a user without subscription log into the app can not make a new subscription according to the Apple's response because the apple id used on the device. An other problem if a keep track of the subscriptions on my backend server if the user unsubscribe on the apple's webpage I can't notify the server about if.
What do I do wrong? What is the right workflow for this case?
I hope do you understand my dilemma.
Thanks!
Your use case is absolutely valid and that's exactly how the subscriptions In-App purchase work with any platform (Apple/Google).
In case of Subscriptions in-app purchase the content delivery is entirely the responsibility of the app provider and not the platform. You have no direct way of identifying if the app user has been switched to a different user as you can't access the current logged in user on iTunes account on the device.
You need to manage this use case on your own by keeping some data locally on the device and maintain user purchase history but still that wouldn't solve the purpose 100%. When user will go for purchase of the subscription it will show the service as already subscribed unless the iTunes user account is also switched on the device.
You can keep track of the unsubscribed state from the backend as when the subscription is successful you will get a receipt from iTunes which you can use to save in your DB. You need to run a backend job on the server side to validate the saved receipt to check the updated receipt which will give you details if the subscription has been expired or not.
I am developing a magazine app which has autorenewable subscription.I have implemented the purchase method and doin the validation using the receipt.My doubt are
1 . How to know whether the subscription has expired or not from the receipt
2 . How to restore the purchases or downloaded contents to another device .Currently my own server is providing the contents to download.So If I purchased some magazines in January and February, then if I try to restore the purchase in another device in march,how could I restore the downloaded contents or check with my server to download the previously downloaded contents.The receipt contains only product ID and nothing related or unique to user , to handle users in server so that the downloads and restore can be handled from the server.
Thanks.Looking forward for expert help.
Each user's device can obtain a receipt and either hand that receipt to your server or decode it and hand the results to your server. Your server will then respond to that device by downloading whatever it is entitled to receive. The receipt contains all of the purchases made under that account and the dates the purchases were made so you should be able to figure out the active time of the subscription. You could also use the 'expires_date' if the question is only whether the subscription is currently active.
If a device needs to prove that its subscription is valid it first tells the user that it needs to check on its subscription and then it executes either a restoreCompletedTransactions or a SKReceiptRefreshRequest.
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.
We are building a subscriptions based video on demand platform that lets our subscribed users to access films from a variety of devices including iOS, Web etc.
So no matter from where the user has subscribed, they should be able to access the content from any & all devices that we support.
Since I need to maintain user's state at a central system (so that all devices can query & allow/disallow access to paid-content).
I have read through multiple documentation re: iOS In-App Purchases & have determined we are a good fit for auto-renewable subscription category.
I have already integrated subscriptions via Roku & using that as a reference. For users who are subscribing through the Web, I have also integrated payment processors like Amazon Payments, Stripe & PayPal - the transactions for which are triggered by the Subscriptions Billing platform that I have already built.
My server (or an endpoint essentially) needs to be able to receive following bits of information preferably directly from iTunes and not from my app.
Notification when a user subscribes successfully to one of my products
Notification when iTunes sucessfully renews a subscription i.e. if user is subscribed to a monthly product then at start of next month, I need to have notification from iTunes that user has been successfully charged for upcoming month
Notification when iTunes successfully refunds a user for whatever reason
Notification when a user cancels a subcription directly from iTunes (not from the app). I know in this case it will mean that it stops the auto-renewal, but I still need to know that this has happened.
Notification when a user un-cancels the auto-renewal.
Does iTunes support any of these actions via Webhook or Push or IPN (instant payment notifications) etc? I havent come across it, if it does.
I know that there is something called as Validating Receipts but that seems to be not a good solution for me, since I need to know ASAP rom iTunes that one of the above flows has happened.
What, if any, are the workarounds to get this information? I am afraid that getting this info from my app is neither timely nor guaranteed to get it.
If you're expecting a direct feed from iTunes, you need to reevaluate your requirements. The in-app purchase ecosystem simply doesn't work that way. You may have the option to write your own subscription processing system (requires an outside payment processor) but whether Apple will approve it will depend on the exact nature of your content. From your description, you have mutually-exclusive requirements.
If the immovable requirement is that you use iTunes, you will need to validate receipts and forward those results to your server.
I need to build an app for a system, which already has a subscription on its website. It looks like Apple doesn't allow to use any own subscriptions and forces to integrate any app with iOS in-app subscriptions.
Is it any way to integrate two subscription systems? The main problem is that users can manage iOS subscriptions via iTunes and I can't find whether it's possible to get information about this and to stop subscription in the existing system if it's stopped via iTunes.
So is it possible to get notifications about unsubscribed iTunes users?
Using third party subscriptions
First off, it is possible to support an existing subscription system in your app, but it must be in addition to the App Store subscriptions. Also you have to be very careful about the UI you use. You can't prompt users to bypass the App Store and purchase through your server, but you can offer existing subscribers the ability to sign in with credentials they may have previously obtained through your website.
That said, Apple can be fairly capricious in their rulings on what is and isn't allowed in the App Store. I have worked on apps that have done this sort of thing, but they have been for fairly well known magazine publications. There's no guarantee that they will allow it for everyone.
Detecting unsubscribed App Store subscriptions
As for using App Store subscriptions, when a user purchases a subscription in your app, they will receive a receipt in the SKPaymentTransaction object. This receipt should be posted to your backend server to make sure it is valid before you give the user access to anything. See the In-App Purchase Programming Guide for more details.
When you setup a subscription type, you specify how long that subscription lasts. So if you log the transaction date in the SKPaymentTransaction when you receive a receipt, you can determine exactly when that subscription should expire by adding the duration of the subscription to the transaction date.
If it's an auto-renewing subscription, you will receive a new receipt when the subscription is renewed. So once you have validated that with your backend server, you can update your expiry date based on the new transaction date. If you don't receive a new receipt before the first one expires, it's likely the user has cancelled their subscription.
On the backend, your server can also tell when a particular subscription will expire based on the response from the verification server. First there is the status code which will tell you whether the subscription has already expired, but there is also an expiry date returned in the decoded receipt which will tell you when it is expected to expire if it hasn't already.
For more details, see the Auto-Renewable Subscriptions documentation.
Testing auto-renewing subscriptions
It's worth noting that when you are testing auto-renewing subscriptions in the App Store sandbox environment, the length of the various subscription types is dramatically shortened to make it easier to test. For example a 1 week subscription lasts only 3 minutes in the sandbox environment. You can see the full list of times in the iTunes Connect Developer Guide.
So you want the people that have bought the service from the website to be able to use the app, exactly like if they had purchased it from in App Purchases and in App Purchases people to be able to join the service just like people that joined through the site? As far as I know, Apple doesn't allow you to pay through other services as you said, but let's say someone buys the service from the app. What should happen would be that the money will be transferred to the company. Then after the payment you should include some code doing what the site does after a new person has payed for the service, so create his account as a paid account. Then, the app should also have a login screen where the registered users (no matter where they registered from) will be able to login into the app and use the service. Now the problem is indeed that if the subscription is stopped through iTunes you would never know, though a way around this would be to make a check in the server of this company which should monitor the income coming from one account. Then if this user has stopped paying (or stopped the subscription) you would be able to stop the service from the app. And you should recheck the server for payment after the duration of the subscription has passed, let's say a weekly subscription should be checked every week. (Sorry I would do this a comment but I haven't got enough reputation for this)