verify subscription externally?

Maybe store the subscription expiration information on your server and have only the iPad able to renew the subscription? That's a little clumsy, but if you want to really do it the "right" way, you'll need to do all of that payment stuff yourself because Apple doesn't support anything outside of its OSs/devices.

You will want to read the documentation on autorenwable subscriptions. The way you pose the question is a bit backwards.

Each device needs to get their subscription updated each renewal period otherwise they lose access rights to your website. Actually, your website will require that any device running the app have a valid subscription before granting access to the website. So the question becomes, how does each device prove to your website that its subscription has renewed? Each device can ask for a renewal notice by submitting a restoreCompletedTransactions to StoreKit. Then it (and the device that made the original purchase) will receive a call to updatedTransactions shortly before each expiration date. That call will contain a transaction object indicating a successful renewal. If you wish you can grab the receipt at that point and send it from the device to your server as 'proof' that the device got renewed. Unfortunately this great procedure doesn't always work. So before you reject a device that attempts to access your website, you tell that device to refresh its receipt (an alternative to the restoreCompletedTransactions - call to updatedTransactions) and send its refreshed receipt to your server. The refreshed receipt will contain all the renewals that that user (the iTunes Account that the device is logged into) has received. This second method can be used as an alternative to the restoreCompletedTransactions.

My problem is, I (and my users) would like for billing to be handled by one user and provide for multiple user's subscriptions. This is a business app for small businesses where one user (typically the business owner) will manage accounts and billing for all the users in the company. Based upon my reading, I don't think we qualify for 11.14 because I want to enable signup _in_ the app to make it easier for my users.

Our payment model is: $39 monthly provides for base company subscription with 2 user logins. Each additional login to that particular company's account is $7.

So I'm trying to figure out how to accomplish this with IAP. I originally submitted the app and was rejected and went back and forth on appeals and finally jsut removed all references (as per 11.14) to our website from the app. I'm now trying to integrate IAP and am struggling with the best way to move forward.

You want it to be autorenewable so that's a bit tough. An autorenewable is specific to a itunes account and each itunes account can really only purchase one subscription, not multiples.

If it were non-renewing subscription then all you would need to do is sell multiple non-renewing subscriptions to a central device - you could even create a package of "5 non-renewing subscriptions". When a central device user bought one of those subscriptions they would get one (or 5) valid password(s) that can be used from any device to log into your server. Once that password is used from that device it cannot be used from any other device. The device that used that password could change it to a different password that would be aligned with the original password - your server would keep track of that alignment. Each month the central user (or anyone else) could renew each of those original passwords by paying another fee. The central user would push the original password to your server after re-upping its subscription for the next month. Your server would keep track of the extended subscription associated with the original password and its assopciated password.

This way the business owner could tell me that I can use the app with the password "gdtysoanag". I would change that to "UserName:Peter Password: mySecretPassword". The next month the business owner would buy an extension (IAP from Apple) and apply that (on your server) to the password "gdtysoanag" . Your server would extend the subscription of "Username:Peter password:mySecretPassword" and my account would be good for another month.

Doing the same thing with autorenewables is harder because you can't purchase the subscription multiple times.

I was considering creating two different subscriptions.

A base level for the company.

Then, I would define multiple types of subscriptions, 1 for each number of users a company might want.

Looks like I need to define multiple types of subscriptions, all including the base level.

Example:

base2users for $39.

base3users for $39+$7=46

base4users for $39+(2 * $7) = 53

etc

Then when they wanted to add a user, I would just "cancel" their existing subscription and sign them up for the new one.

Does this sound plausible?

I really appreciate your help and feedback navigating this stuff.

-j

You would sell the following IAP products:

1) a "Base plus 2 users for X months" for $39. These would be good for, say 3 months (i.e. X=3). It could be purchased again to extend the subscription period. Each purchase would come with 2 new passwords.

(if the user had a current "Base plus 2 users" that was good for at least 1 month from now they would also be able to purchase:

2) an "additional user for 1 month" for $7 (they could purchase this repeatedly - each purchase would provide a new password)

3) an "additional 5 users for 1 month" for $25 (what a bargain!) (they could purchase this repeatedly - each purchase would provide 5 new passwords)

The user would then be given passwords for each purchase (or 2 or 5 passwords) that they could use to log into your server for that amount of time. Again, the password would be good from only the first device that used it to log into the server.

The "base" device would get a list of purchased Passwords. Perhaps a neat list into which they could add their own name (e.g. "Subscription with original password XFVBGTHS has been assigned to: [you fill in 'Bob Smith's iPhone5']"

The base could then take any newly purchased password and instead of handing it to a new user, push it directly to your server in conjunction with an existing user and then extend an existing user's subscription - for example "credit the new password BBGYHFTY to the current user under XFVBGTHS". Then Bob Smith would get an extra 1 month without doing anything himself.