views:

118

answers:

3

I'm developing an app in which the user could subscribe for a feature to use for a specified period. The subscription period gets verified on our own server and after this time the user needs to buy a new subscription.

Now I am confused about the alert from Apple: After the "Do you want to buy one ..."-alert there comes another one with the note that the user already had paid for the subscription and if he wants to renew!

Does this REALLY leads to a new payment?

Thanks!

A: 

You can test all the in-app-purchase (IAP) stuff in a sandbox that doesn't result in actual payments.

Also, how your app handles the various transaction determines when the "Do you want to buy..." dialog appears.

Obviously, once the user purchases a subscription, you should save that (read: NSUserDefaults), and not put up the "Do you want to buy" alert if they're all paid up.

If this doesn't answer your question, perhaps ask something more specific. In particular, it is your execution of IAP-related code that triggers the "Do you want to buy?" alert; so you have to do/not-do that based on your knowledge of the user's subscription payment.

Olie
+1  A: 

You are required by Apple to present your own purchase UI, either something AppStore-like or an alert. After the user confirms the purchase to you, your app submits the SKPayment, which will cause the SDK to verify the user's store identity and the amount they're paying (which I believe is the second dialog that you are referring to).

Any time a user gives you money through iTunes, there will be an iTunes dialog somewhere. Apple doesn't want developers to skip that step and get free money from unsuspecting users. The solution is to design around it: you know the dialog is coming, so don't give the user a redundant dialog first. Many apps use info pages with "buy" buttons to get around that - instead of two purchase dialogs back to back, they'll see one purchase-info page, press a button, then get the Apple SDK purchase dialog.

If you want a subscription service, then you need to set the item up in iTunes Connect as a subscription, not a consumable or non-consumable item. Once you create an IAP item you cannot change its type, so choose correctly at creation time. Subscriptions aren't handled like consumables even though they are basically just time-based consumables. Apple enforces the different wording to communicate to the user that one expires at a certain date, the other expires after some non-time resource is used up.

You will need to track the subscription purchase on your own servers (to check receipts and eliminate piracy), and your apps should prompt for a renewal at the right time. As far as the app store is concerned, renewing a subscription is purchasing the subscription all over again, so, yes, you'll see the SDK throw up some dialogs at the user asking them to verify their purchase. There's currently no "auto-renewing subscription" option, either. These reasons are why many developers offer multi-month subscriptions.

AndrewS
A: 

I got exactly the same question ! I implemented inApp purchases with a subscription and when the user buys it in sand box and lets say waits 5 minutes for it to expire and trys to buy it again the system says "Product already purchased. Do you want to renew it ?".

How can I tell the apple server that the subscription has expired ?? And that the user NEEDS(!) to BUY(!) it again in order to use certain features in the app ?

Alexander Frey