not sure if this pass as a Stackoverflow question (close if not).
The problem we're facing at the moment is we have an app that we want to allow user to pay to unlock additional content space so they can create more content but be able to purchase multiple copies of that item without being charged twice unless they've exceeded what they've initially purchased.
So a concrete example is this:
Think of a item bag in World of Warcraft that lets user carry more items. (Our app isn't a game but it's the same concept). Users can buy many copies of the bag and at the same time, it doesn't matter if the user log into the app from their home computer or another computer, the bags are still tied to their account.
I'm aware that I have two options really:
Non-Cosumable In App Purchase
User buys the in app purchase item once but does not buy another copy. In other words, they can only ever have 1 copy of that item, not 10 or 20 copies (which our business logic requires in this case).
Consumable In App Purchase
Allows purchasing multiple copies of the item BUT they are non-transferable purchases. This would mean users would need to pay for the same item again even if they bought a new iPad, they can't transfer those "bags" to the new iPad or if they delete the app and reinstall the app, they would still need to pay for those items again.
Subscription based in app purchase doesn't exactly fit our model.
So is there a special type of non-consumable in app purchase but allows the user to buy multiple copies of that item/feature?
Additional Considerations
We do not have a third party server to track users and the number of copies of that item/feature they unlocked.
It also doesn't make sense to make a hundred copies of the in app purchase in iTunes Connect manually.
I think only making a consumable in app purchase is our only option. We're reluctant to force to user to have to pay for unlocking the same content twice but at the same time don't want users to be able to keep creating additional "bags" for free.
If user purchases a non-consumable purchase twice, I am sure Apple store has mechanism to prevent the purchase.
Instead, it would simply say: You have already purchased this product. It will be downloaded again. You will get all the delegates being called normally, and content delivery will happen as per what you have coded, but the customer will not be charged.
To avoid the payment flow, you can store the purchased item under itunes user's keychain, too.
Related
This is a Cocoa in-app purchase question.
I have a game where you can buy a set of 10 lives, and this is a consumable in-app purchase -- once the lives are used up, the user must buy more.
What happens if the user uses a subset of the lives, say, 5, and then deletes the app, reinstalls, and restores purchases? Apple will tell the user that they purchased a set of 10 lives, and my program will happily oblige and give them 5 extra lives.
Does my server need to keep track of this data? I haven't found any information in the in-app purchase documentation about how to proceed for this.
What happens if the user uses a subset of the lives, say, 5, and then deletes the app, reinstalls, and restores purchases?Apple will tell the user that they purchased a set of 10 lives, and my program will happily oblige and give them 5 extra lives.
No! the consumable products cannot be restored. Even if you provide a Restore IAP, consumable products cannot be restored back. So your concern that the user will get 5 extra lives is baseless, but yes you need to keep track of the lives that are used by the user if your app is syncing data with server.
Here is what Apple docs say,
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html#//apple_ref/doc/uid/TP40008267-CH2-SW2
Consumable products, by their nature, aren’t synced or restored. Users
understand that, for example, buying ten more bubbles on their iPhone
doesn’t also give them ten more bubbles on their iPad. All other types
of products are made available across all of the user’s devices.
They’re also restored so users can continue to access their purchased
content even after buying a new device. Store Kit handles the syncing
and restoring process for auto-renewable and free subscriptions and
for non-consumable products.
Products that expire or get used up—consumable products,
auto-renewable subscriptions, and non-renewing subscriptions—can be
purchased multiple times to get the consumable item again or extend
the subscription.
Can I create one in-app product for, say, some music, and then vary the exact track based on a database key?
So the user would buy a music product but the app keeps track of the exact data which comprises their instance?
As #Paulw11 said in his comment above, you can setup a consumable product ID that offers one or more "credits". Using the concept of credits is the only way you can dynamically allocate products to purchases without adding a product ID for each song in iTunes Connect.
Consumable products can be purchased multiple times, so allocate credit or direct the user to select the song once they buy the product. Be sure to call finishTransaction to "consume" the purchase, otherwise the transaction will remain in the queue and additional purchases will be blocked.
Be warned though, consumables are not restorable; if the user deletes and re-installs the app all their songs will be lost. One way to deal with this is to keep a server-side registry of songs a user has purchased, which means you will need user management and authentication etc.
Here's another stack question relates to yours.
I have used consumable virtual currency purchases in my game.
The user can use that currency to unlock different types of jetpacks.
Apple rejected the game saying it requires a restore purchase button.
But apple's documentation says that consumable products does not require restore.
Why is apple considering the unlocked jetpacks as non-consumable products?
Following is the message that i have received in iTunes connect.
From Apple
10.6 - Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are
worth it. Apple sets a high bar. If your user interface is complex or
less than very good, it may be rejected
10.6 Details Your app uses intermediary currency to purchase items that function as non-consumable products but does not include a
restore mechanism. Users restore transactions to maintain access to
content that they’ve already purchased. Next Steps Please modify
your app to include an optional user registration feature that allows
users to restore their purchases to all of their iOS devices. We
recommend indicating that account registration is necessary to restore
previously purchased In-App Purchase products, and providing a way for
users to register later if they wish to access this content in the
future.
Should i make a restore mechanism for the jetpacks ?
I am using Soomla and unity3d for iap.
In summary, what Apple are saying is that you must include some kind of user registration / account feature where you are storing the users items on your server.
When they sign in on a new device, they should still have everything they have bought in your game.
It seems that Apple considers these purchases as non-consumable products because they are non-consumable products, no matter how you try to handle them in your app. If you define them as consumables, that means a customer loses them when they uninstall and reinstall the app, buy a new phone and restore their old phone to the new one, use the app on several phones, and so on. In other words, Apple considers your use of a consumable purchase to be cheating.
Your customers would feel exactly the same. If your marketing people try to maximise the flow of money from customers to your company, they should consider methods that Apple and your customers don't consider to be cheating.
I am implementing ios app in which I want to add In-App purchase (IAP).
I want to use in-app purchase for below situation:
1) User will make registration and pay $10.
2) Now, my app will allow user to download songs. (For ex. 10 songs of $1. So user can download 10 songs.)
3) User can add more credit by again making purchase of $10. (So if user wants to pay 2 times then he/she will get $20 in his/her account. And he can download 20 songs of $1.)
4) While downloading song, my app will check whether user has enough balance or not, then only he can download data. (If there is no balance then it will ask to make payment of $10 first.)
I have make research for above situation and also looked into in-app purchase guidelines from Apple.
From that, I come across below:
1) If I will use subscription: But in that case, user will be charged after some duration (for ex. monthly payment, 3 month payment). Which I don't want. Because I want user to pay only if he wants to download data and not have balance. So I think, subscription is not ideal.
2) If I will user Consumable in-app purchase: Here, I can use it, so user can pay as many times as he want. And I need to track his balance from server side. So, from server APIs, I can check user's balance. But I think, it may conflict with Apple rules.
"Consumable items are the one exception to the requirement that your content be available on all the user’s devices. Consumable items are digital items that are used up or disappear after use and can never be reused. Examples of consumable items include virtual poker chips, in-game ammunition, or virtual supplies such as construction materials."
So, user can make payment from his iPhone device. And he can download songs from his iPad device as well. Means, purchase is sharable.
But,
Consumables are device-by-device items, so their purchase needs to be made with the understanding that they are tied to the specific device. Apple does not let you restore a purchased consumable. You should warn your users that consumables are not shareable, and make it easy for users to purchase smaller blocks of items.
So can someone helps what kind of in-app purchase is suitable for above and also according to Apple Rules regarding in-app purchase.
Thanks in advance.
User "Non-Renewing Subscription" should fit your requirement https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/CreatingInAppPurchaseProducts.htm
When a user of an iOS app purchases a non-consumable item, then installs that app on a new device, it is possible for them to again go through the standard purchasing logic for that item. The app store will ask them if they wish to spend $0.99 on the item, but if they click "Yes", it will inform that they already own that item, and ask if they wish to download it for free.
I would like to track new purchases in my analytics, and not have them conflated with re-purchased items that a user receives for free. Unfortunately, it seems that this behavior is indistinguishable from a genuinely new purchase, (to the client app). Apple seems to say as much: "Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions."
In discussing this issue, most posts (and Apple's documentation) say that I should offer a 'Restore Transactions' button to the users. I do offer this button, but it is always possible for users to circumvent this logic, and go through the traditional purchasing route. This is where my tracking will become inaccurate.
Do I have any options? Thanks!
I am pretty sure you don't have any options for tracking a new purchase versus downloading a previous purchase for free when a user does an in app purchase. I have looked into this for the same reason of analytics and I could not find a way to do it. IAP is set up to make sure that you honor purchases made by the same iTunes account on other devices.
If your users are required to have an account specific to your app to make a purchase you could use that to know if they already have made the purchase or not. But requiring an account for purchase can lower your conversion rate.