Hello,
I have a working subscription system with revenuecat for a jazz education app. I wanted to be able sell individual lessons. I heard from many customer that they would want individual lesson purchases that is unlocked for life. I have 42 lessons in the app now and I plan to add more. It will be around 150-180 lessons total. So, What is the best practice here? Do I need to create 150 SKUs ?
I have 6 categories and that number will be 10 categories soon.
Every lesson in each category will have the same price. However, I will need to track who bought which lesson? So could I somehow have 10 categorical prices to simplify things down and still track 150 lessons with it? Thanks..
Solved
Pricing setup question for A La Cartes sales
+7Best answer by matt-heaney
Hey
Matt from RevenueCat here. Thanks for the question!
Working with a large number of in-app purchases does bring some extra work, but it’s very achievable. There are a few options to explore here.
As you mentioned, setting up a large number of individual IAP items is one option and, for most apps, is likely the quickest and safest approach. However, it does require setting up each item individually. Each item would be a non-consumable, meaning the user can purchase the lesson once and keep it forever. When they restore purchases, the lesson is unlocked again. This approach makes it easy to see individual sales figures, and linking lesson IDs to product IDs can help reduce complexity in your code.
Alternatively, this could be handled with a single in-app purchase, or one in-app purchase per category price in your case. This approach requires a backend database and a system to track which lessons are available to each user. With this route, the user makes a purchase and you log that lesson as available to them in your database. This would be a consumable in-app purchase, as the item represents the ability to unlock a lesson rather than the lesson itself. When the purchase is successful, the user redeems their ability to unlock a lesson for the specific lesson they’re buying.
On your backend, you can enable webhooks and listen for purchase events. These webhook payloads include the app_user_id, which you can use to identify the user. When a webhook is received, you can verify the purchase using the transaction details and, if needed, fetch the purchase information using the GET /subscribers/{app_user_id} endpoint to confirm the purchase appears in the user’s non-subscription purchase history. Once verified, you can mark that lesson as permanently available for that user in your database.
While this approach removes the need to manage a large number of items, it does introduce more complexity, and you’ll need additional logic to track which lessons have been purchased.
I hope this helps. If you have any additional questions, please let me know. I’m always delighted to help!
Hey
Matt from RevenueCat here. Thanks for the question!
Working with a large number of in-app purchases does bring some extra work, but it’s very achievable. There are a few options to explore here.
As you mentioned, setting up a large number of individual IAP items is one option and, for most apps, is likely the quickest and safest approach. However, it does require setting up each item individually. Each item would be a non-consumable, meaning the user can purchase the lesson once and keep it forever. When they restore purchases, the lesson is unlocked again. This approach makes it easy to see individual sales figures, and linking lesson IDs to product IDs can help reduce complexity in your code.
Alternatively, this could be handled with a single in-app purchase, or one in-app purchase per category price in your case. This approach requires a backend database and a system to track which lessons are available to each user. With this route, the user makes a purchase and you log that lesson as available to them in your database. This would be a consumable in-app purchase, as the item represents the ability to unlock a lesson rather than the lesson itself. When the purchase is successful, the user redeems their ability to unlock a lesson for the specific lesson they’re buying.
On your backend, you can enable webhooks and listen for purchase events. These webhook payloads include the app_user_id, which you can use to identify the user. When a webhook is received, you can verify the purchase using the transaction details and, if needed, fetch the purchase information using the GET /subscribers/{app_user_id} endpoint to confirm the purchase appears in the user’s non-subscription purchase history. Once verified, you can mark that lesson as permanently available for that user in your database.
While this approach removes the need to manage a large number of items, it does introduce more complexity, and you’ll need additional logic to track which lessons have been purchased.
I hope this helps. If you have any additional questions, please let me know. I’m always delighted to help!
+7Thanks a lot for the detailed answer. Now I need to make decision as to complicate things on the Apple Store and Google Play Store side or the app’s backend.
Keeping records of who bought which lesson seems like a must for me for other reasons as well.
So it looks like it is easier for me to manage 8-9 categories at the digital stores and keep detailed records in our database is easier.
So, I guess I have to think about paywalls as well. In this case I might need to make my own paywalls since the mechanism will be a bit more complex. Thanks a lot. I have a much clearer picture.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.