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
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
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.
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).
I have implemented In-App Purchases in various apps before wherein we can set a price based on a specific Tier for a Product.
Now in this case, the price of the product depends on the number of people. For example, a video will Cost $ 0.99 for >20 students, for >50 students it will be $1.99 ,etc.
So, I thought of making different products for each such case.
Eg:
Product1. VideoForUpto20Students for $0.99. (Video course 1)
Product2. VideoForUpto50Students for $1.99. (Video course 1)
So if I implement it in this way then if the number of students increase, then I will have to create more product Identifiers for a same Product.
Again, I have a number of Video Courses approx. 40 ! That means, the total number of product identifiers for 40 Video Courses having 4 different prices will (40 * 4) = 160 product identifiers.
So, do I need to create different product identifiers for the same product to set multiple prices or is there any other alternative ?
Please help! Thanks in advance!
You will have to create different identifiers for every In-App Purchase unfortunately.
From the accepted answer here In-app purchase custom price:
As noted by other poster, you cannot have variable in-app purchases.
You have to select one of the provided price tiers.
While you aren't exactly making it so the price is changing a lot (since your idea isn't a delivery service), if it is going to change at all you are going to need to create multiple identifiers.