The application I'm developing has multiple MP3's for purchase and download. I need to know if I have to create "In-App Purchase" items for each of the MP3 items. (Each MP3 item can be priced differently, but multiple MP3s can have the same price ). Please advise on this.
You can go ahead with consumable purchases with this case. You would need to create different priced products on itunes.
So lets say there are two price variants in your app. 10rs/song and 15rs/song.
So while displaying songs you can show appropriate itunes product with them. When user purchases a song, record the transaction on your server as well, that way you will be able to track how many songs are bought by one user. And you can give access to those mp3 on other device as well if user logs in with same user id.
Related
I am using In-app purchases in my app. After a user pays for a video, they can view it.
The problem is that I will have a huge list of videos on my server and price will vary for each video. So, every time when I post a video, do I need to add the video in iTunes Connect or is there an easier way?
A user can watch a video only a limited number of times (say 5 times) then the user needs to pay for the video again. How do I achieve this functionality? Use consumable and restore it after 5 times? Or, is there an approach for this?
Yes, you will have to create one product per consumable that you want to sell. After the user purchases the product, send the receipt to your backend and verify and store the purchase. Then notify your client and finish the transaction. You need to make sure you keep track of the consumables that your user purchased, this might be easier if you have a login system, otherwise, things get more complicated and you might need to create a restore and alias system with random user IDs. You can read more about how the system works here
Every time you start the app you would ask your server for the purchases that the specific user has made. That way you can programmatically figure out if the user can buy to watch the same video again and let it purchase another view.
It looks to me that what you are trying to achieve is not really scalable with the way the App Store IAPs are structured right now and I would really consider a subscription model rather than a consumable based app.
There's four types of In-App purchases and only Consumable fits your requirements.
You'd have to implement the logic to keep track of how many times a user can watch a given video and update this data whenever a user makes a purchase or watches a video. Ideally, you'd use a database (local or remote) to keep track of this data.
With this implementation, you would only need to register a new SKU when you want a new combination of price and number of views.
Here's an example of possible SKUs:
com.yourorganization.5dollars5views which lets a user view the selected video 5 times for $5
com.yourorganization.5dollars10views which lets a user view the selected video 10 times for $5
com.yourorganization.10dollars5views which lets a user view the selected video 5 times for $10
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.
Problem
I am working on app that has millions digital items . I want to implement InAppPurchases for this . So as this is digital content and only once unlock-able/Purchase-able.
What i have already done.
I tried to do this via consumable for same price tier but apple rejected my app and forcing to use **non-consumable.
How to handle the following:
1 - Do i need to create 30k in App Purchases at iTunes ???? (I read somewhere there is a limit of 10k)
2- Is there a way to reuse one in app purchase for type non-consumable.
I'd recommend to you to make user buy points, each point opens one item, and whenever user purchases an item, you record it to user's purchases list (for restore purposes).
Application is about selling Audio books.
Option 1 : Consumable In App Purchase
It Will have different product ids with common price.
e.g. Audio A and Audio B both have price $2 then both Audio A and Audio B will share common product id.
All user purchase will be managed from server
Option 2 : Non Consumable In App Purchase
Will have different product ids for each audio.
I am confuse because there could be 10k + Audios. Can we create dynamic Non Consumable item ?
Any ideas how to make this scalable?
For that amount of dynamic content you will probably have to implement some kind of custom "currency" which would be a consumable item.
You can either make it completely arbitrary in amount, or you could try to make a few different IAP products to correspond with audio books in different price ranges. So something like $0.99$ book purchase, $1.99 book purchase, etc.
Apple allows up to 1000 in app purchase products to be created. So you cannot create 10k+ products. Also finding the product amongst this will be a very complex task for the user. See if you can bundle books of same price into a single bundle and price them economically so that users tend to purchase. 10 books for 10$ is better than 20$.
You should definitely go with non-consumable option since audio books do not deplete in time.
You have to maintain your own server in between the app and the Apple in app purchase and you need to have a user account management to track what books the user has purchased. You can create a different SKU For each price and and associate the product id with the book on your server and track the purchases done by the user on your own. Since multiple books could map to the same in-app product id, your app should handle the restoring purchases explicitly and based on your app user login enable the audio books on different devices.
Basically the in app flow would be used just for payment purposes. Enabling and downloading of the audio books will have to be controlled between your app and the server.
I would use something like a 2-Dimensional int array. [x][y] whereas x is your individual product ID, and y is the count on how many items are sold. You can then always link your x to a certain price. This way you can easily keep track on how many audio files 'y' with product ID 'x' got bought.
Never give two different audio files with maybe equivalent price the same ID. An ID should always be unique since there are a lot of problems that might occur later:
Implementing the audio files in a seperate database
Audio file becomes cheaper/more expensive, then you´d have to use another ID anyway
I have a question regarding In App Purchases, If I have hundreds of videos in my application that are needed to be purchased like an auto-renewing subscriptions. For example, a user can buy a video for a duration of one month and then it would be renewed automatically.
But I don't want to create a separate in app purchase for all the videos, since the number of videos are liable to change dynamically. So I want a generic auto-renewing subscription for all of these in app purchases, but the problem here is if I make a generic auto-renewing subscription for all these videos and the user buy one of them then the user will have access to all the other videos which he did not buy.
Any ideas how to overcome this problem
I'm not sure how I would proceed in this case.
Using in-app purchase for unlocking a single video means you have a productId for that video OR for the unlocking of all the videos. In the latter case, it's something you don't want, as you said (seems reasonable). In the first case, you need to have a different productId for each one of the videos, unless you may not unlock more than one video at the same time. In this case, you could save the videoId somewhere in the cloud or on the device, so that you know which video you can and which video you can't watch.
If the scenario is instead: a user can unlock how many videos he wants, but for each video he has to buy a separate in-app purchase; then I'm not sure in-app purchases as they exist right now is the choice you may want.
Think about the case when a user wants to end an auto-renewing subscription. He will follow these instructions http://support.apple.com/kb/ht4098 and he should find one row for each of the videos he bought.
This means that on the Apple-side there has to be one productId for each one of the videos, so we're back again at the same point.
The only option I think is to implement your own purchasing system. Maybe if you explain your reasons to Apple during the review process, they won't reject the app. But it's quite risky I have to say.