User Profile

If we were to implement that model, if user subscribes to movie D, then lets it lapse and purchases it again, we'd let him choose a new movie. We'd treat the auto-renewable subscriptions as "slots" that user could fill with whichever movie they want.What is really missing for us is the piece of the receipt that we could use to associate a subscription to a particular movie. What would that be, the transaction identifier or the original transaction identifier? How can we match on our server a particular subscription to a piece of our content?Are there any downsides to using these identifiers to do this kind of association on our end?

Thanks for the reply, PBK!We've changed our mind and we're thinking auto-renewable subscriptions now. Is there any way we could avoid having thousands of product ids so that we could have a product that is a "Subscribe to one movie for a month" and that we internally, on our side, associate with a particular product?

Hi JoeRadTMUS, KMT and PBKI'm currently dealing with a very similar issue and I think we'll go for the non-renewing subscriptions route. The only issue I see is that if I have a non-renewing subscription "A" that can be used for multiple "movies". How would identify each of the subscription individually? I'm thinking for example that I want to know when user cancels the subscription to a certain movie. How would I know which one it is?Any tips on that?Fran