I’m developing IOS app which do calls to the server. I want to allow users to use web services from ios app only after subscription was made, no login required
How to identify whether IOS REST caller have active subscription, without “login with apple” ? I saw several apps is able to do “premium” calls to server right after subscription was made.
You could do it this way:
An account ID is automatically created when the app is started for the first time. This happens unnoticeably in the background.
The account ID is sent with every API request. The server then only checks whether this account ID has a premium status.
If the user buys the premium status, update the account ID on the server side.
This is just a short description without any advice on security and best practices. Please implement this solution only if you know what you are doing. By the way, this approach is also used by ivpn.net.
Related
Some time ago, I developed and published an iOS App in which I offer subscriptions that I validate on server side.
On server side I correctly register the access privileges of a user according to the subscription that server receive from the App (Apple Store). First server validating the receipt from the App with the Apple Store and check everything is correct.
Before presenting the list of subscriptions in the App the user must register and log in and then choose a subscription. The user's email is sent to the server along with their purchase receipt. We need user email to identify the user in our database and assign the subscription.
We now need to add to the App processing OFFER CODES that a user may have redeemed at the Apple Store, outside of the App.
Apple advises to create the SKPaymentTransactionObserver at the beginning of the App startup to receive these possible subscriptions from outside the App.
But if my App needs the user to be registered and logged in, that event could arrive from the payment queue (PaymentQueue) but since the user is not logged in, the purchase cannot be assigned.
I've been searching for a long time and I'm disoriented among so much information.
Could someone who knows something guide me on the right path on how to implement these situations?
Any minimal clue that helps me continue will be very valid, someone who has already faced this, I would greatly appreciate it.
Im working on an app which will support subscribing to a premium version.
Whenever a user buys a subscription I can verify the receipt on my backend, persist important data and grant entitlement which is good.
However, when a user buys the subscription for the first time I rely on the Firebase User ID in order to query my DB.
When I receive App Store server notifications I query by the original_transaction_id.
Now comes the problem, I do not know whether a subscription can be bought initially outside of my app. (I only sell them in-app, but am not sure if apple provides a way to buy them outside of the app.).
If it is possible it would cause a problem.
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.
We run a SAAS Web app and are going to be launching our app in Apple’s app store (up to now we’ve had a mobile Web app).
We want to offer the ability to purchase a subscription in app due to the ease of use for our customers. No problem, we know how to do that.
The question we have is whether there is an easy way to keep our web app's db updated with the user’s current subscription status so if they access our Web app we know whether their subscription is valid.
Ideally it would be great if Apple offered a web hook option where they would post an update to a url on our server. From what I've read this isn't an option.
We can always post the data to our server from the iPhone app when the user logs in, but if the user doesn’t log in on the iPhone for a while the subscription status recorded on our server will be out of date.
How are other people handling this? Are we missing something?
Update:
The closest I've found is this thread: https://forums.developer.apple.com/message/70707#70707
The app gets a receipt the first time it buys a subscription or
restores a subscription. The app can send that original receipt to
anyone's server. Anyone's server can then use that orignal receipt to
verify the current subscrition anytime it wants. You can't do that
with a non-renewing subscription but with a non-renewing subscription
the user must purchase the extension from the iOS device each time
period.
Followed up with this:
https://hetzel.net/2011-04-01/server-side-auto-renewable-subscription-receipt-verification/
And from Apple it sounds like they definitely do not make any provisions on their end for synchronization:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have
both an iOS and OS X version have separate products with separate
product identifiers on each platform. You could let users who have a
subscription in an iOS app access the content from an OS X app (or
vice versa), but implementing that functionality is your
responsibility. You would need some system for identifying users and
keeping track of what content they’ve subscribed to, similar to what
you would implement for an app that uses non-renewable subscriptions.
Late to the party, but I think this is a relevant reply to this question:
https://stackoverflow.com/a/47537279/543423
Hopefully this is helpful to someone :)
I'm building an iOS app, which provides a service which our website already provides. It's a subscription based service, where all features are enabled when you're subscribed. To get people to sign up for regular payments on the app, it seems like I'll have to go through Apple's in app purchasing API, with auto-renewing subscriptions. That's fine, but the problem is the service users will purchase through the app must also be available on the site. But reading through walkthroughs and the developer guide, it looks like the only way to process transactions is through the app itself, which then can be set up to pass the info to the server. But then I'm imagining this scenario:
User purchases a subscription on the iOS app, goes back and forth between using the site and the iOS app. On the day the user is to be charged, and the days after, they're using just the website, for whatever reason. The server doesn't know they've been billed though, and so features are disabled. In order for the server to find out the user has been billed by Apple, the user has to open the app on their iphone or ipad and sync it with both Apple and my server.
Is there any way for my server to ping Apple directly and get information about the purchases made for my app for a given user? I haven't been able to find anything; the two suggested layouts, with or without server, both use the iOS app as the sole communicator with Apple, aside from having the server verify that information is valid. If it's not possible for the server to get this information first hand, what other possible solution could there be?
Try to not use Apple's built in payment system, and risk getting rejected (with the app duplicating a service that's been available for years online, do we no longer have to use their in app purchasing system anyway?)
If a user is paying through Apple, have the server give them a generous buffer between expected payment dates and when features are disabled (makes the problem happen less frequently but doesn't solve it)
When their account seems expired to the server but it doesn't expect that, email the user a message saying they have to open the app or else their account will not be credited for time purchased (seems like a strange and not really great thing to have to ask a user to do in order to use the service)
This is about all I've been able to think up so far. Anyone have any advice on these solutions, or know of others, or know who I could talk to to try and figure this out?
Yes, you can check on the status of a user's account from your server. There are a few caveats:
First and foremost, Auto-Renewing Subscriptions are reserved for periodicals such as magazines and newspapers. If your app doesn't resemble those, Apple may reject it (as they did mine) and request that you use Non-Renewing Subscriptions (read: Manually-Renewing Subscriptions).
Second: This scenario would require you to store all receipts that you receive on the app, on your server.
Finally: I don't know how your username/password system works, but the user would have to login with the same credentials on your app as they do on your website.
Here's how you check the status of a user's account: Store at least one receipt per user on your server. When you want to check the status, follow Apple's procedure for Verifying App Store Receipts. Send them that one receipt and they'll respond with the latest receipt and the expiration date. Now you'll know, at any given moment, if a person's account is current or not.