Subscription-based Apps

[Vinny Howard]

Hi all
I'm looking at developing an app that uses a subscription model, but I can't find any documentation on how to go about it. The Apple docs seem to leave it at "you are responsible for tracking subscriptions and renewal billing". Does anyone have any more information on this, or has anyone seen any proper documentation on how to go about it?

[Nathan]

I'm interested in this kind of model too. Likewise haven't found any good documentation.

[Vinny Coyne]

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire).

If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date.

So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.

Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Howard]

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date.

So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.

Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Coyne]

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB.

On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.

Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Howard]

So is it possible to determine a unique user id from the receipt? I didn't think we were allowed to access their email addresses etc. Or do you mean that the user will need to give us a user id in the settings of the app? In that case, couldn't the same user id be used on multiple devices who haven't ponied up the cash? Excuse all the quesions, I haven't done an In-App purchase yet so I'm not sure what user details are in it.

Vinny Coyne said:

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB. On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.
Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Coyne]

No problem, they're all valid concerns.

What I meant is that the user would provide a user ID or email as part of a registration process within the app.

As far as I know, it's not possible to extract any user data from transaction receipts.

To avoid multiple users running under the one username/email, you could tie the purchase down to the device's unique ID (UDID). This would eliminate the need for a user ID, but would tie that purchase to the device. So, the same user would have to re-purchase the subscription for multiple iPhone OS devices.

Vinny.

Vinny Howard said:

So is it possible to determine a unique user id from the receipt? I didn't think we were allowed to access their email addresses etc. Or do you mean that the user will need to give us a user id in the settings of the app? In that case, couldn't the same user id be used on multiple devices who haven't ponied up the cash? Excuse all the quesions, I haven't done an In-App purchase yet so I'm not sure what user details are in it.

Vinny Coyne said:

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB. On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.
Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Howard]

From what I remember, Apple expect you to allow subscriptions to be used on all devices - pity they don't give us a hand! Thanks for the help, if I find anything that will be of use to others I'll keep this thread up to date. I was wondering why there weren't many subscription based apps, I know now.

Vinny Coyne said:

No problem, they're all valid concerns. What I meant is that the user would provide a user ID or email as part of a registration process within the app.

As far as I know, it's not possible to extract any user data from transaction receipts.

To avoid multiple users running under the one username/email, you could tie the purchase down to the device's unique ID (UDID). This would eliminate the need for a user ID, but would tie that purchase to the device. So, the same user would have to re-purchase the subscription for multiple iPhone OS devices.

Vinny.

Vinny Howard said:

So is it possible to determine a unique user id from the receipt? I didn't think we were allowed to access their email addresses etc. Or do you mean that the user will need to give us a user id in the settings of the app? In that case, couldn't the same user id be used on multiple devices who haven't ponied up the cash? Excuse all the quesions, I haven't done an In-App purchase yet so I'm not sure what user details are in it.

Vinny Coyne said:

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB. On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.
Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Howard]

From what I remember, Apple expect you to allow subscriptions to be used on all devices - pity they don't give us a hand! Thanks for the help, if I find anything that will be of use to others I'll keep this thread up to date. I was wondering why there weren't many subscription based apps, I know now.

Vinny Coyne said:

No problem, they're all valid concerns. What I meant is that the user would provide a user ID or email as part of a registration process within the app.

As far as I know, it's not possible to extract any user data from transaction receipts.

To avoid multiple users running under the one username/email, you could tie the purchase down to the device's unique ID (UDID). This would eliminate the need for a user ID, but would tie that purchase to the device. So, the same user would have to re-purchase the subscription for multiple iPhone OS devices.

Vinny.

Vinny Howard said:

So is it possible to determine a unique user id from the receipt? I didn't think we were allowed to access their email addresses etc. Or do you mean that the user will need to give us a user id in the settings of the app? In that case, couldn't the same user id be used on multiple devices who haven't ponied up the cash? Excuse all the quesions, I haven't done an In-App purchase yet so I'm not sure what user details are in it.

Vinny Coyne said:

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB. On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.
Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Coyne]

No probs. I actually implemented subscriptions into EirText Pro for the Push messaging feature. The method I'm using is registering the user's username, not the device ID, so I guess that fits in with Apple's requirements.

Vinny Howard said:

From what I remember, Apple expect you to allow subscriptions to be used on all devices - pity they don't give us a hand! Thanks for the help, if I find anything that will be of use to others I'll keep this thread up to date. I was wondering why there weren't many subscription based apps, I know now.

Vinny Coyne said:

No problem, they're all valid concerns. What I meant is that the user would provide a user ID or email as part of a registration process within the app.

As far as I know, it's not possible to extract any user data from transaction receipts.

To avoid multiple users running under the one username/email, you could tie the purchase down to the device's unique ID (UDID). This would eliminate the need for a user ID, but would tie that purchase to the device. So, the same user would have to re-purchase the subscription for multiple iPhone OS devices.

Vinny.

Vinny Howard said:

So is it possible to determine a unique user id from the receipt? I didn't think we were allowed to access their email addresses etc. Or do you mean that the user will need to give us a user id in the settings of the app? In that case, couldn't the same user id be used on multiple devices who haven't ponied up the cash? Excuse all the quesions, I haven't done an In-App purchase yet so I'm not sure what user details are in it.

Vinny Coyne said:

Yes and no. You only need to validate receipts at time of purchase - validate server-side and if valid, then store the purchase date & some unique user ID (e.g. email address, username) in your DB. On app startup, simply query your server's DB for the user ID and compare dates to see if the subscription period has expired.

You can use HTTPS / SSL if you'd like to keep everything encrypted.

I agree, it'd be nice to have an Apple-blessed solution, but they seem to shy away from the server side of iPhone dev (see Push Notifications).

Vinny Howard said:

So does that mean validating App Store receipts on startup, via the App Store, as well as a call to your own server, which would need to have stored the receipt ID and expiration date on initial purchase? I take it this call would need to be encrypted so packet sniffers aren't hanging out of it, and then use of a session key for the lifetime of the app. instance. Slightly over-complicated, I wish they'd build this stuff in...

Vinny Coyne said:

What Apple mean by that is that it is up to the developer to maintain a list of users who have purchased a subscription and the date at which that subscription was purchased (or will expire). If you don't do this, and a user re-purchases the in-app subscription item, they will be charged again as a subscription renewal from that date. So, for example, if I purchased an annual subscription, and a week later accidentally hit the "Renew" button, I'd be charged for the subscription again from that date.
Ideally, your app should go online to check the user's subscription status - if out of date or non-existant, then let them renew/purchase.

Hope that helps.

Vinny.

[Vinny Howard]

Yeah, lucky that you had your user id 'baked-in' for you! Might look at using something similar.