I was told to create a unique identifier for each course. But I have thousands of courses and creating a non-consumable for each unique course(apple id, google id, revenuecat ids, entitlements & offerings) is not optimal. How about I create pre-defined prices like ios: tier1, tier2
These are my consumable products: tier1, tier2, tier3 ...
Each course has one of the predefined tier price. After selling the course with tier1 consumable, I’ll add the course id to user’s inventory in my rest service. That way, after the course is sold in one platform, it can be reached by all the platforms because I get my inventory from my rest service.
Is this a feasible solution? Will there be any problem in that approach, especially by Apple?
Best answer by codyView original
Yes, that is a feasible solution- since you may have thousands of courses, the best way to handle this would be to use a tier based consumable system, and track which course the user is buying at the time of purchase, and store it in your own database/API. I’d recommend using webhooks to get updates about a purchase paired with an app user ID so you can reconcile your database with transaction data.
Additionally, you could attach those tier products to generic ‘tier1’, ‘tier2’, etc. entitlements, so you could provide different content to users based on if they have ever purchased a tier. For example, if you want to offer exclusive courses to customers who have previously purchased a course, you could check those entitlements and offer a different set of products. This is just a cool way to still leverage the entitlements system in RevenueCat, even if you aren’t using it for individual products!
...track which course the user is buying at the time of purchase, and store it in your own database/API. I’d recommend using webhooks to get updates about a purchase paired with an app user ID so you can reconcile your database with transaction data.
How u know which course was bough on the server side? You only know who bought and which tier, but not the entity_id?!